Subject: Re: [Endymail] Hashes of key as addresses

From: Michael Kjörling <[email-masked]>
Date: Thu, 4 Sep 2014 13:29:55 +0000

On 29 Aug 2014 09:37 -0400, from [email-masked] (Phillip Hallam-Baker):
> On Fri, Aug 29, 2014 at 5:11 AM, Michael Kjörling <[email-masked]> wrote:
>> On 28 Aug 2014 19:23 -0400, from [email-masked] (Phillip Hallam-Baker):
>>> Using hashes of keys as addresses is very powerful. There are
>>> basically three types of address in such schemes:
>>> 
>>> 1) traditional human readable
>>> 
>>> 2) hash of key
>>> 
>>> 3) Traditional human readable + hash of key.
>>> 
>>> 
>>> So in PPE we use all three in different situations:
>>> 
>>> 1) ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA
>>> 
>>> 2) [email-masked]
>>> 
>>> 3) ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA?[email-masked]
>> 
>> Does this scheme not imply that everyone who wants to validate an
>> address, or know to where to pass a message given an address, needs to
>> either (a) query some form of central repository where all address
>> (hash)es are registered, or (b) have a local cache of all valid
>> address (hash)es?
> 
> No, it implies some mechanism for resolving the hashes. But that does
> not need to be centralized.

Fair enough, but how would you resolve such a hash without
connectivity?

We know that traffic analysis is being done on a massive scale, and
have good reason to believe that encrypted traffic is routinely and
specifically targeted for storage for possible later analysis.

As it stands, with SMTP, assuming transport security (_proper_
STARTTLS, for example), it seems about the most someone listening in
can figure out is that someone is sending e-mail to a particular
domain (say, by matching DNS MX RR lookups with subsequent SMTP TCP
connections). This leaks a small amount of metadata, but that can be
mitigated by sharing SMTP hosting and email address domains with
others. I would argue that any replacement (the purpose of which is
end-to-end security) should not leak _more_ metadata to any reasonable
attacker, ideally including an active attacker able to do network
packet injection.

> One way that works very well is to use QR codes in an in-person
> meeting. Web of Trust never worked the way PhilZ wanted. But we didn't
> carry supercomputers with cameras (aka smartphones) then.

Far from everyone does, even today. [1] Should the protocol be
designed to essentially require such?

> There does not need to be a central repository. There does not even
> need to be global connectivity.

Then how would you propose to validate a hash, or given a hash, send a
message to it, without some sort of connectivity to some sort of hash
repository?

[1] Thu, 4 Sep 2014 13:18:56 +0000, http://mailarchive.ietf.org/arch/msg/endymail/qIjDw--NOtG0JFbqHJHvbHKVPeM

-- 
Michael Kjörling • https://michael.kjorling.se • [email-masked]
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 04 Sep 2014 14:58:11 +0100

Hiya,

In the hope of heading off a rathole discussion (about who
has what devices with what capabilities)...

> designed to essentially require such?

We're nowhere near the point where what's "required" is being
discussed really. I doubt PHB meant that QR codes ought be the
one and only way of doing anything. And even if he did, (which
I know he doesn't:-) that wouldn't matter so much now, and its
ok to regard 'em just an example of what might work in some
cases.

That kind of "what to make mandatory to implement" discussion
would be needed later for sure, but we're not there yet.

Cheers,
S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 4 Sep 2014 11:10:16 -0400

> Fair enough, but how would you resolve such a hash without

How does the email get sent at all without connectivity?

Now clearly there are circumstances in which a client has a
compromised email only connection. But these are actually pretty rare
these days and I don't see a problem with saying that we can't do end
to end directly in that situation.

In my current implementation the email can be composed offline as
normal. The S/MIME enhancement takes place in an outbound SMTP proxy
as the mail is being sent.

> specifically targeted for storage for possible later analysis.

Which is why we need STARTTLS even in an endymail world.

> designed to essentially require such?

Well it is working right now without any QR code implemtnation.

> message to it, without some sort of connectivity to some sort of hash

The repository does not need to be unified or global. Right now the
so-called 'repository' consists of posting files to a web site of the
email address holder's choice.

I do object when people insert pejorative terms like 'global
repository' into a scheme.

I think it very likely that a global repository will emerge naturally
because it is convenient to do and I expect 95% of keys to end up in
it. But I do not expect it to ever be complete.

---

From: Steffen Nurpmeso <[email-masked]>
Date: Fri, 05 Sep 2014 20:27:12 +0200

|As it stands, with SMTP, assuming transport security (_proper_
 |STARTTLS, for example)

I don't know how many messages are sent over SMTP each day, but it
would be interesting to know how much energy all those useless
roundtrip packets consume which are necessary to get upgrade
a SMTP session via STARTTLS, and how many percent of those
connections could also instantiate a non-existent SMTPS instead,
not requiring these upgrades.
Imagine all those billion indic kids treadle the dynamos to
produce the necessary electricity; granted it improves the
quality of their organs, too, so win-win here.

And in my world there was no support for DNSSEC, but omnipresent
support for TLS over TCP.  It would take a day to extend the
resolver, with fewest additional code, based on external
crypto / ssl/tls libraries which get used trillion times each day.
And with a caching resolver and/or a local DNS cache that
additional cost on the DNS side would be balanced out by the
savings of the much more often occurring SMTPS connections.
Oh well, it is much too late for this nagging, of course.
And there are really some domains which use DNSSEC today; my bank
does not however, and unfortunately ;-))  But of course their
website is protected via https, after so much phishing, ..say.
I wonder wether that sorts out the problem.

--steffen

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 5 Sep 2014 23:09:50 +0200

> not requiring these upgrades.

Practically zero and who cares.

TLS negotiation doesn't grow more expensive if you send a few bytes of 
cleartext before the client hello.

Arnt

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 5 Sep 2014 21:25:37 +0000

> not requiring these upgrades.

SMTP is not that latency sensitive.  Because SMTP starts in cleartext,
servers can and do refuse to STARTTLS with clients they are going
to reject due to poor IP reputation.

There are other advantages.  For example, the server learns the
client's EHLO name before TLS, allowing it to base TLS policy (like
requests for the client certificate) on the the client's EHLO name.
And of course clients that fail to interoperably negotiate TLS can
fall back to cleartext.

All told, STARTTLS is a good fit for SMTP, which unlike HTTP is
not nearly as sensitive to latency.

-- 
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 5 Sep 2014 17:59:12 -0400

> not nearly as sensitive to latency.

Very good points and points that designers of DNS privacy approaches
would do to bear in mind. Any protocol that has a server performing a
public key transaction without any form of authentication on the
request is going to end up being killed by DoS.

So the trick is to pull the authentication out of the DNS query loop
so it can be amortized.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 5 Sep 2014 22:10:12 +0000

> request is going to end up being killed by DoS.

Postfix can also rate limit run-away clients that rapidly create
uncached sessions, rather than reuse established sessions.  This
behaviour can be "stress-dependent", when the service process limit
has recently been reached.  While not widely deployed by default,
such counter-measures are good to have up one's sleeve.

> So the trick is to pull the authentication out of the DNS query loop

Similiar ammortization ideas in DJB's MinimaLT, suggestions for
short-term re-use of ECDH exponents with 25519, ...  Also in much
more mundane process-reuse in Postfix, where each service handles
100 or so requests by default before exiting, ammortizing start-up
cost.

-- 
	Viktor.