[rmoriz]

In my opinion, mail crypto needs to become mainstream usable. E.g. even trivial contents should be encrypted by default and this should be usable by default. Currently, S/MIME does a better job than PGP.

While the CA-model seems to be broken in most X.509 use cases, like TLS/SSL, where a duplicate certifcate can be used to do a man-in-the-middle-attack, this does not really affect S/MIME, especially after both parties started a "conversion". People that need to communicate "really" secure, should therefore be able to ignore all "CA-Trust" and white-list certificates on a per user basis (e.g. like PGP).

Ordinary communication still can by default fall-back to the existing CA-model to keep it usable (but not secure).

Some steps:

1. We need more love by the MUA-vendors, who mostly support S/MIME but it's still a PITA to use. Google e.g. still does not support S/MIME on android, see https://code.google.com/p/android/issues/detail?id=34374

2. We need CAs that are usable. StartSSL is nice and free, but it's not easy to use. Lower the entry barrier for getting and renewing/recreation of certificates

3. (most important) Make it easy to manage local CA-trust. On each new system, the user should be able to select a "trust no CA/whitelist only" approach and then be responsible for trusting other parties. No vendor (Microsoft, Apple, Google, Mozilla) should silently distribute and trust new CAs without users consent.

[XorNot]

I don't understand why we don't just apply the OTR model to email.

OTR's big latency is the initial handshake. After that, you can persist the session. But email is intrinsically a high latency medium anyway! We can afford 1 or 2 days delay to setup an initial encrypted connection. In fact, we can display a big "not encrypted!" message to users, while still letting them exchange email, until we've done the handshake and socialist millionaire protocol (or verified keys by some other means) setup.

I am willing to bet like 70-80% of people who send email to each other physically have their email clients online at the time they do it, even if they take a lot longer to answer - especially with the number of smartphones out there. So we can setup an OTR session after 1 message the vast majority of the time, and then reuse the same session as much as possible.

[beagle3]

The "global CA" model is bust. How it was ever considered usable is beyond me, but we now have more than a decade of experience seeing just how bad it is. It is utterly, fundamentally broken and easily subverted by state actors.

For now, the only reasonably usable secure key exchange method seems to be what WhisperSystems are doing on their phone app (safe against MITM if the parties know each other, and very hard to MITM even if not - especially not automatically).

[aianus]

What's wrong with blockchain based solutions like namecoin?

[beagle3]

If I understand correctly, namecoin is a distributed DNS replacement. Is there a way it addresses impersonation (e.g. MITM?), if so, can you please point me at documentation?

DNS does not address it, and even DNSSEC does not (if you can forge the certificate, and you can mitm the traffic - which state actors are all capable of - then it doesn't matter that you can't forge the DNS response itself).

[aianus]

You can place your own self-signed public key in your namecoin record. There is no longer any need for certificate authorities which can be coerced into forging certificates.

[beagle3]

Well, if this is properly supported by software using namecoin for DNS resolution, then - yes, this may work. The proof of the pudding, however, will arrive once it's eaten. I am not familiar with namecoin to point where the potential problems are, but do note that the failure of CAs is not in the cryptography but rather in the trust model. In modern cryptography, the problems are almost always with the practice, not with the theory.

[rakoo]

> software using namecoin for DNS resolution

Actually, it should be the other way around: dnschain [0] bridges DNS resolution and namecoin, so there's no need to modify existing software.

[0] https://github.com/okTurtles/dnschain

[mike_hearn]

Comodo give away free S/MIME certs:

http://www.comodo.com/home/email-security/free-email-certifi...

They can be generated and installed into the OS keystore by your browser automatically. By the low standards of crypto it works pretty well. Any old email client supports it out of the box.

[frabbit]

Or, you can avoid the obvious problem in using a certificate generated by a non-trustable actor and use one which relies on the WoT instead: http://cacert.org

[mike_hearn]

I find WoT based solutions to be much less trustable overall.

[micro-ram]

We already have a start there. Make all NON-EV certs free.

[Someone1234]

I'm all for that, but realistically how will you verify identity? If there is no identity verification what is stopping me from going out and registering for "google.com" and then using it in my MITM attack?

[pauldino]

I think most non-EV SSL certificates these days are "verified" by sending a message to whatever e-mail address you have on file in your whois record.

Also on Chrome at least certificate pinning should prevent that particular scenario.

[Someone1234]

Chrome's certificate pinning database doesn't scale at all (i.e. it works on less than 0.01% of the internet).

As to the whois thing, what is stopping me from hijacking a domain, changing the whois and then generating keys? The webadmin might never even know. You don't even need access to their email.

Or to put it more realistically: What is stopping the NSA from pressuring a domain registrar into altering the whois for a brief period in order to generate MITM keys?

[pauldino]

Nothing, really. But that is the situation today.