[Cryptography] Dark Mail Alliance specs?

[Jerry Leichter]

On Nov 23, 2013, at 7:30 AM, Ralf Senderek wrote:
>> But of course you're right about actual current usage, encrypted email is an
>> epic fail on that measure regardless of format/protocol.
> Yes, but it's about time we do something about that. Do we *exactly know why* it is such a failure?
It's hard to be definitive in answering this kind of question; in essence, you learn the answer by finding a way to actually get people using.  I'll hazard the guess, though, that it's a combination of two factors:

- On the "pull" side, people haven't felt there was a need.  Before the recent NSA brouhaha, when was the last time you heard of anyone actually having their email intercepted?  Note the question carefully:  It's not whether people *have* had their unencrypted email intercepted; it's whether such interceptions have gotten "airplay".  There are tons and tons of stories about people attacked in various ways by malware in attachments and stuff.  There are many stories about email accounts being taken over by identity thieves.  There are related stories in which people's passwords are stolen, and then all their mail is stolen (e.g., Stratfor).  There are even stories about people getting into trouble when they let someone - friend, lover - have access to their email, and that person turned against them.  But I can't recall a single story of interception "on the wire", or even of interception by access to a disk where the email was stored.  It's certainly happened, but it's probably been rare, as there it's usually just as easy to mount a stronger attack view malware or password breaking.

Note, by the way, that with the limited exception of my first example, encryption wouldn't help *at all*.  They all involve cases where the attacker is able to gain access to mail as the legitimate user, so will have ability to read that mail.  In the first example, you might argue that people know not to open attachments from strangers, but are fooled by email apparently from friends.  With authenticated senders, you wouldn't be able to fool the recipient.  Unfortunately, many of these attacks are actually the result of a prior break-in to the friend's account - so the message will arrive fully authenticated.

- On the "push" side, the *system* aspects have simply not been properly implemented.  Many mail systems implement S/MIME - but how do you get keys?  There simply is no good way to get them.  Where you get email addresses out of Exchange or some LDAP service you could just as easily get the related key - but I have yet to see an organization implement that.  (I haven't checked, but I'd guess both have the *capability* to do this; it's just that no one has bothered to enable it.)

Since there's been no "pull", there's been little to encourage development of the "push" side.  So the capability to exchange encrypted emails sits there virtually unused.

There's a third recent factor, of course:  Increasingly, people read their email through Web interfaces.  There's simply no way to make that secure in current browsers.  Sure, you can download some Javascript to decrypt your mail, but there's no good reason to trust it!

My suggestion is that there are two fundamental problems that need to be attacked:

1.  The key lookup/distribution problem.  It has to be easy and straightforward to get keys in the common use cases.  In fact, it needs to be so easy and straightforward as to be invisible to most users most of the time. It's easy to get caught up in difficult edge cases that can't be handled easily.  This is a case where "the best is the enemy of the good".  Cover as much as you can cleanly today; worry about the hard cases tomorrow.  (Many people will never run into a need for a solution to a hard case, and those that do may be willing and able to do more work.)

2.  The Web mail problem.  I can see only one solution to this:  Get S/MIME implemented in browsers.  HTML/5 already contains tons of interfaces (way too many, I'd say, but that ship sailed a *long* time ago) to implement various things that simply need to be present *everywhere*, generally for performance reasons.  (After all, Javascript *is* Turing-complete.)  While S/MIME or some other secure mail protocol *could* be implemented in Javascript, it would have to be downloaded each time - and there's no way to guarantee security.  If S/MIME were built in, you would have exactly as much reason to trust it as you would to trust the S/MIME in your conventional MUA.

Getting this done will take some time:  Getting stuff in HTML5 is a big standards circus, and then you have to wait for implementations to reach critical mass in the field.  But the sooner we start, the faster it will happen.

Note that it *might* be possible to get this in through a side door:  For better or worse, HTML5 will likely have a place to stick DRM implementations. Perhaps an S/MIME "DRM plugin" would be feasible....

                                                        -- Jerry