On Sun, Feb 2, 2014 at 3:54 AM, Dave Crocker <dhc@xxxxxxxxxxxx> wrote:
On 2/2/2014 12:48 AM, Patrik Fältström wrote:You think that's a system that can and will be convenient and used by the mass market???
On 2014-02-02 00:34, Dave Crocker wrote:
1. It has demonstrated unacceptable usability for average users.
At last my view and experience is that latest Enigmail and MacGPG is
making it usable.
The key exchange is hard, but works really well in Enigmail+Thunderbird,
as key management is directly from mail read/compose window. Not in a
separate application.
So why isn't it already?
I address that in my video. Sorry, its not in text yet, but the argument is not really part of the technical specifications.
The part that you don't state by name but imply is 'what is the business model'. We are talking about a multi-million dollar change to the email infrastructure. That is only justified if we can show a multi-billion dollar return on the investment.
I think that there is such a return. If my bank, my doctor, my brokerage can send mail and be assured that the transport is confidential end to end, they can use email in more ways. SSL made Web commerce possible and added roughly five trillion dollars to global GDP according to one estimate. Email security can make Internet commerce better and simpler and sustain that growth. Even if the additional benefits from making the other Internet killer application secure are 1% of the Web benefits, that is a lot of potential.
I see S/MIME and PGP as being 95% right respectively. The problem is that Internet applications don't take off if they are 'pretty good' back in 1992 they had to be extremely good. And now they have to be exceptionally good.
Most of us have a box full of smartphones we bought before the iPhone came out. The Palm Treo, HP iPaq and the Rim pager. They were all functional but none of them had the real web, they were all walled gardens. Remember that before the iphone the industry was flushing a billion dollars a year down the WAP toilet in the confused belief that what cell phone users really wanted was a dumbed down version of the Web with more adverts.
That missing 5% is critical. Specifically any new security scheme has to be frictionless:
* Key Management: Has to make starting a key set simple and intuitive. The user cannot be required to perform annual maintenance to replace expired certificates. Everything has to be completely automatic.
* Multiple devices: It must be really easy to read the encrypted mail on the many devices real users use today. I have eight machines that I regularly read email on. Making it possible to read mail on a new device has to be a one or two clicks affair.
* Transparent: Sending mail securely has to take no more effort that insecure mail. That means that the mail client (or a proxy) has to decide whether to send mail in cleartext or encrypted. Which in turn means that there has to be a mechanism for specifying security policy.
S/MIME already supports an enveloping mode that protects the headers and metadata. It just isn't fully supported by the deployed base. So there has to be a way for a receiver to tell the sender what they support. Which is why we can't use the PGP or S/MIME infrastructure just as is, we need to add a little policy glue.
Take a look at the message that John posted, opening this thread. That some systems use multipart/signed is fine, but it's not what's most common for PGP.
End-to-end email has stalled in part because of the S/MIME vs PGP standards war. PGP has ended up with all the mindshare, S/MIME has the deployed base. When I was at VeriSign I had some long discussions with Jon Callas about what might we do to fix things and come to a common platform. The division was particularly silly when PGP had one of the best S/MIME platforms in the market. That effort was overtaken by events and DKIM. The industry didn't have bandwidth for two email crypto efforts at once. When I left VeriSign I lobbied PGP inc to start a CA precisely to see if we could start to heal the rift. Not that it helped. Symantec now own both companies and that hasn't helped either.
If people want to move forward on this, something that would be very helpful is for the naysayers to put all their objections into an Internet Draft. Then those of us looking to solve the problem can go through and see what we have solved and what is left to do.
I wrote a set of IDs as design documents before starting work on the code:
I now have code that is incomplete but shows proof of concept:
There are two phases to the code:
Phase One is a scheme that employs a direct trust model and requires no trusted third parties or infrastructure beyond the existing email infrastructure and access to a Web Server to publish the Phingerprint Blocks. This scheme uses the 'strong email address' which is essentially a PGP fingerprint prepended to a mail address.
Phase Two allows people who have not met directly to exchange secure mail. This scheme allows people to use their normal email address without any visible cryptogunk. It necessarily relies on some form of infrastructure but does not force a peer-to-peer or hierarchical model.
Right now the proxy can generate and manage keys, accept outbound mail, encrypt it and forward it to the actual outbound mail server. I hope to get the code to the point where it can make the decision to encrypt or not and pull keys from a web server before London.
Website: http://hallambaker.com/