On 29 Aug 2014 09:37 -0400, from [email protected] (Phillip Hallam-Baker): > On Fri, Aug 29, 2014 at 5:11 AM, Michael Kjörling <[email protected]> wrote: >> On 28 Aug 2014 19:23 -0400, from [email protected] (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 protected] >>> >>> 3) ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA?al...@example.com >> >> 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 protected] 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) _______________________________________________ Endymail mailing list [email protected] https://www.ietf.org/mailman/listinfo/endymail
