Internet Draft: SMTP Strict Transport Security

I don't know where to begin.

> Arguments like this presuppose that the TLS security system is exactly as it was in 1999

For the majority, it is. The % of sites that deploy all of the latest HTTPS bells and whistles, even just looking at the minority of sites that actually enable TLS, is in the low single digits. Only 8% of sites surveyed by Qualys SSL Labs... sites that are presumably run by people who care about security, unlike my bank, even bother to enable HSTS.

> major sites all pin certificates now

My bank doesn't. Enabling HPKP and HSTS is just risky from a commercial point-of-view. People aren't good at key management. If you botch it, you make your site inaccessible and you lose customers.

People screw it up all the time. I've done it. I was speaking to someone just today who was over-zealous with 'includeSubdomains' and made their product blog inaccessible (it was on a blog subdomain, which had an invalid TLS setup because wordpress.com don't support TLS on custom domains). It happens.

> if you're well-equipped enough to subvert a CA

Strawman, I never held this up as a threat. In any case, it's a bad defence of PKI. Being able to choose from N CAs doesn't help you. You only have to subvert one CA to own the world, just like DANE, where an attacker only has to break your registrar, or the domain registry, and you're toast. The 'world governments' you fear have the capability and thensome. Irrelevant.

The threat I explicitly mentioned is that if I own your DNS, I can get myself a cert for you domain. This has the same same threat models as DANE (if "owning your DNS" involves me compromising your DNS server and getting your DNSSEC keys, or guessing your domain registrar password), except DANE doesn't depend on horrible, ineffective, and privacy-invasive, hacks like OSCP... or allow me to simply keep certificates for domains I no longer own. DNS caching effectively gives you the equivalent of OCSP stapling for free.

> major sites all pin certificates now

TLSA records have all the configurability and capability of HPKP and more, and can be applied to any protocol/endpoint. They even cross the isle to work with the CA system if you so desire, unlike HSTS+HPKP which has become hostile to anything self-signed.

> STS and DANE aren't orthogonal

They are. DANE relates to key-pinning via TLSA records, not HSTS.

> forklift replacement of DNS that DNSSEC requires.

DNSSEC is backward compatible. You're talking twaddle. Enabling it these days, if you control your own DNS server, also takes seconds. With EC digital signatures, it's even sensible. Setting up HPKP+HSTS+OSCP stapling is far more fiddley...and stuck in the RSA stone age.

At least in email's case, the most common pattern is for SMTP connections to begin in plaintext and then be upgraded to TLS. This involves the client sending a command to the server inquiring about the server's protocol extensions. The server advertises STARTTLS [1], and then the client invokes the command to upgrade to it. These interactions are all SMTP-specific, and so the SMTP client and server both need to be aware of it. (The client should presumably keep trying to upgrade to TLS, and not send the message plaintext; and a server one day might reject connections that haven't been upgraded.)

For protocols where the common pattern is to establish a connection using TLS from the beginning, it would be easier to do something like what you're describing.

[1] https://tools.ietf.org/html/rfc3207

We are working to switch Haraka to use TLS by default in all systems. A big part of that is adding support for letsencrypt so that we can trivially create a secure outbound certificate for every mail. This stuff is important and we need to make email secure.

Only in the sense that larger companies can afford to fund their employees to work on IETF standards groups, and are thus more likely to end up contributing, editing and managing IETF groups.

The funding is not large, though: no dues, no grants, just the time that people spend and airfare/hotels up to three times a year -- usually two of those being inside the US. And it's possible to have quite a lot of impact simply by volunteering your time in a group in which you have some expertise.

Why? They solve different problems. DNSSEC/DANE moves the TLS CA into the hands of the DNS hierarchy from various corporations. STS just says to use TLS (with this cert, but you can only know the cert is OK to begin with because of a CA, or DANE).