On 01/01/14 06:03, Phillip Hallam-Baker wrote: > On Mon, Dec 30, 2013 at 3:44 PM, Dave Crocker <d...@dcrocker.net> wrote: > >> On 12/30/2013 12:38 PM, Paul Lambert wrote: >> >>> Another approach, however, is to start from scratch and to define an >>>>> entirely new email system, which uses cryptographic addresses instead of >>>>> human-readable identifiers. I guess that's the approach you are >>>>> suggesting. Is this correct? >>>> >>> Yes - we should start from scratch (versus direct >>> augmentation of S/MIME/PKI or PGP). >> >> Starting from scratch to build a new email system is not likely to >> succeed, any more than the various, earlier efforts to do that succeeded, >> back when the installed base was a few orders of magnitude smaller and >> adoption of a new system relatively easier. >> >> And then there is the small matter of wondering how viable the human >> factors of cryptographic email addresses will prove to be... > > That can't be done in the current mail system but it is easy to do if there > is a policy layer. Any mechanism that can be used to tell the sending mail > client that S/MIME or PGP format mail is preferred can in principle be used > to say that the mail should be sent over some JSON-B based REST scheme that > provides a superset of SMTP and JABBER capabilities.
(I'm new to IETF lists so I beg some leeway with my comments whilst I get a grip on the netiquette of posting) It would seem to me the main stumbling block for mass adoption of PGP on SMTP and OTR on IM has been the multiplicity of additional software layers. The typical day to day users I encounter understandably find it hard to understand why they should need multiple additional applications to provide these services and they're just way too busy with the kids/education/work balance to spend time learning both, let alone other tools. The people I believe to be typical end users don't want to have to mess around with different encryption systems (nor do I believe should they need to) to the extent that even installing a 'no-click' solution is too much.[1] A policy layer, to my mind at least, could go a very long way in reducing this all too human overhead. I suspect XMPP/XEP may provide some ideas with regards to areas of crossover between SMTP and IM. As I've seen it, a Group Chat is somewhat analogous to a mail list, an IM sent in 'offline' mode is somewhat analogous to SMTP and XMPP Federation is somewhat analogous to SMTP relaying. Certainly, I recall a time when a certain major webmail provider had XMPP chats turn up in their webmail view[2]. Pete. [1] <mini rant>It was a long fight to get users to look for the 'lock' icon in their web browser. Now, I'm finding I have to get them to check whether PFS is enabled, how about cipher size and type etc. as well as trying to get what I'd call critical business infrastructure (ISPs, banks, certain Govt depts) to fix their web servers so that people not using outdated/broken ciphers can talk to them. The other day I went to report some breakage to my ISP but couldn't because... their webserver was using what I consider broken ciphers. I thus tried reporting this in less than 140 characters using to me what was an obvious string [cipher overlap] and the response was basically 'CANNOTREPRODUCE: I submitted the forms successfully, try a different browser'. I get the feeling that each type of encryption/security we make available for typical users increases difficulty of uptake exponentially and would probably have a go at proving this mathematically if it weren't 2014/01/01 08:15 where I am at the moment</rant> [2] If memory serves correctly, this was removed recently when they federated their new Social platform with their Chat platform and disabled external XMPP federation. _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass
