Internet Draft: SMTP Strict Transport Security
tools.ietf.org
tools.ietf.org
Of course email at rest security remains an issue, but that another story.
For all intents and purposes this is most of the English speaking internet. If you swap Yahoo for Verizon and Apple you'd be pretty close.
So, yeah encouraging to get this standard applied, less so if you think it is good for the internet to offload an outsize share of control to 5-10 corporations.
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.
That has already happened a long time ago, so lets try to make the best of the situation.
If you are not willing to do anything significant about it, then at least push people not to trade simplicity and ease-of-use with blockchain short term to give the technoloigy a chance to diverge into numerous protocols and subsystems.
I think you underestimate how much email Yahoo (still) handles. Maybe add Apple to the list, but Verizon is nowhere near the volume / user count of Yahoo.
There are a lot of protocols (say XMPP, IRC or IMAP) around that have opportunistic encryption with STARTTLS-like semantics. Surely, they could all benefit from a similar solution.
IRCS has settled on 6697: https://tools.ietf.org/html/rfc7194
IMAPS uses 993.
That said, dedicated SMTPS port would still be beneficial by cutting down at least 2 RTTs (HELO/EHLO + STARTTLS) from overall transaction time.
TLS is already widely supported among large ISPs, but until now it has been far too easy to fall back to plaintext. There wasn't any way for a receiving ISP to ask all senders to use TLS and not fall back, which meant it happened occasionally. It's why Google's "Safer Email" transparency report shows many senders at 99% percent TLS, rather than 100%:
https://www.google.com/transparencyreport/saferemail/
As receivers deploy strict TLS policies, and as senders add support, I expect to see these numbers reach 100% and stay there. I look forward to having strict TLS support in place in our email systems. Nice job making this happen, folks who contributed!
Unlike HTTP where connecting to abandoned non-TLS websites can be useful, e-mail is only useful if someone is reading it, and if they are reading it they can take action to enable TLS.
Also, if you deploy your STS info via DNS you'll need DNSSEC validation to to ensure that what you read in DNS is actually what the zone holder put there. Without DNSSEC how does a sending SMTP daemon trust the STS policy of the recipient zone. STS policies are stored in DNS TXT records, or their own new RR.
Sure, if DNSSEC fail, then SMTP-STS is better than nothing.
I'm pretty sure that the big providers could have had deployed DNSSEC relatively easily, if they just wanted to.
I think other DNS-based email security features such as DKIM and DMARC motivates DNSSEC as well.
It's a little tricky to explain why this is the case without getting into a lot of gritty detail. A shorthand answer is that browser vendors have, pretty much as a group, decided not to adopt DANE (the DNSSEC-based alternative to the X.509 CA system), and DANE is the only reason anyone cares about DNS security on an Internet where everything is going to be encrypted (usually with TLS) by default.
You don't need a secure DNS for the web.
You don't, with STS deployed, need a secure DNS for email.
Is publishing SSH key fingerprints so important that we should do a forklift upgrade of the DNS? No, of course not.
Also, I think you're underestimating the growth of DNSSEC deployments. I've been watching DNSSEC growth for about 2 years and it is steadily moving up and to the right.
It is nowhere near ready for universal deployment today, and, indeed, virtually nobody relies on it, unlike TLS.
I guess I don't have some expectation that deployment should take place quickly. Or that the first go at a protocol is going to always get it right. Just because a journey is difficult doesn't mean the journey isn't worth taking.
DNSSEC and TLS are unrelated. They're trying to solve different problems.
Geoff Huston at APNIC does some good work at measuring validation. Check out slide 2 and 24 of this preso. https://meetings.icann.org/en/marrakech55/schedule/wed-dnsse...
Again, I'm not arguing that DNSSEC adoption has been easy and fast. But it's being adopted steadily.
In the current protocol the only difference between offline and online signing is in how authoritative servers are implemented. There the differences aren't all that significant (relative to building an authoritative server as a whole) -- the same data needs signing, etc -- so please explain how your protocol makes implementation simpler.
> Obviously it would not be the only difference.
Can you please expand on that? You've said you've been thinking of a DNSSEC2 proposal for a while so you must have more to say.
Give me a solid anchor and a lever that is long enough and I can move the earth.
The problem of all modern crypto technos is 1) CPU burnt for crypto is a nice lever for DOS (and not all our mails require crypto, seriously 60% is spam) 2) they do not solve the 2 general problem
Yes 2 auth/Channels factors seems nice. The problem they stay on the same plane. It is 2 inbound channels.
You know when USA engineers last thought it was smart, kiddies learnt to use a 1$ cpt crunch whistle to phone for free all around the world.
Actually I don't mind, I am broke and totally will love free whatever the stuff that this kind of engineering will offer me.
Are we still sending basically plain text unsigned messages using something akin to the pony express? Does it matter that the pony express carriers communicates securely so no bad guys can snoop the carriers bag of messages At least in the old days you could put a wax seal on the letter to know the letter was legit and not tampered with. With email the entire system is flawed from the get go.
Email is sent via a protocol called SMTP.
SMTP goes over port 25 between major senders (there are other ports but forget that for now).
Since it uses a single port, you can't distinguish between encrypted and plain text communication until you know each end supports encryption. A dated philosophy but people don't upgrade their email servers as often as they do their web browsers so it made sense at the time.
Since the plain text receiving server says "yes I can do STARTTLS", this is easy to man in the middle intercept and say "no encryption here" and the mail goes through anyway.
Even if the receiving end says all mail must arrive over TLS the man in the middle can currently circumvent that by receiving in plain text and forwarding onwards via TLS
This is an RFC to try and prevent that happening.
This stuff is hard, and email nerds (via MAAWG and various other places) have been working on this for years. We don't want to break your current email service, and bringing things up to speed without breaking a ton of eggs has been hurting email for a long time, but we spent too long stopping spam instead of thinking about these problems. Sorry!
Discovering if someone supports Protocol++ if the fallback to Protocol is insecure is a hard problem.
BUT, it's better than not doing anything.
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.
You upgrade to TLS later. But only if the server says it can do that.
A MITM attack can easily say that the receiver can't do TLS and thus can see everything that passes.
This RFC specifies a way to prevent this, assuming clients abide by the requirements. It will be a long and slow roll out to get this done. But it is worth it.
This kind of bureacratic busywork is really, really frustrating. SMTP is nice and simple and does not benefit from this proposal except in the most abstract checklist-compliance sense.
Even worse, of the domains that support STARTTLS, a sizable number either don't present certificates that chain to a widely trusted root, or don't present certificates that actually match their MX. Worse still, because many domains' MXs don't match the domain itself, even if the certificate is trusted for the MX, it may not be trusted for the domain.[1]
So I think unfortunately we're not anywhere near a world where we could actually just drop email on the floor if TLS-with-a-valid-cert isn't present ("valid" not being clearly defined here, of course). I do think we're slowly moving in that direction[2].
It's certainly true that retrofitting security makes the whole thing more complicated, of course. That's a strong argument for ensuring that any retrofitting we do is itself forward-compatible with what we want to do in 30 years. Or for inventing time machines.
1. http://static.googleusercontent.com/media/research.google.co... 2. e.g. http://arstechnica.com/information-technology/2016/02/gmail-...
This is madness, though. TLS is transport-layer security. It's not kerberos and it was never intended to be. The cert produced by the MX should be valid for the MX. Trust is an illusion, but to the extent that you decide to trust anything in the CA system, you trust it for the MX only and use SPF etc to determine if the MX is the correct one.
STARTTLS is a bad idea and should go away entirely. It forces an SMTP server to care about the transport layer, and that's entirely incorrect. I have plenty of SMTP servers that communicate on my networks without ever touching TCP/IP -- forcing them to support STARTTLS specifically is moving backwards.
This RFC is strongly dependent on the internet looking pretty much exactly like it looks today, and enforcing that mode of operation indefinitely. It's short-sighted and harmful to the entire email world.
Also, can be used with DANE for additional security.
DANE is generally a bad idea, and it's great that STS is explicitly proposed as an alternative to it, not an application of it.
What DANE would have done is end the madness that allows me to hack your wordpress blog for a day and then go get myself a certificate for your domain, for free, that doesn't expire for three years. A certificate you will never be able to detect the issue thereof and cannot easily revoke if you do.
And STS isn't an 'alternative' to DANE. The two are completely orthogonal
STS and DANE aren't orthogonal. DNSSEC/DANE offers such marginal value to HTTPS that the browsers that once offered pilot support for it have now eliminated that code; it is off the roadmap for the web. The remaining motivating use case for DNSSEC was SMTP security; DANE was a way to ensure that MTAs used secure transports and avoided downgrade attacks.
But STS does the same thing without requiring the forklift replacement of DNS that DNSSEC requires.
> 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.
It seems crazy to me that, after years of hyperventilating about the implications of the Snowden disclosures, anyone could take DNSSEC seriously. But people do!
At this point, I'm just recapitulating things I've already written, so:
1. Your main argument is that the NSA and its cohorts have control over a handful of many top level domains available. But the same control that would allow them to take control over domains and generate valid DNS signatures for them does allow them to generate valid certificates in every proposed global PKI system, including today's. There is literally zero difference in attack space here.
2. Several of the current CA institutions are under government control. Any one can generate a valid certificate for any domain. It can be done without a trace of evidence. The same active attack against a DNSSEC signed TLD would by necessity be much more visible.
3. Given that DV PKI is what TLS relies on, any adversary that can modify DNS packets in-flight can also create a valid TLS certificate today. We know these attacks are taking place from the Snowden documents.
4. An attacker can choose which CA to attack, and pick the one that is easiest to fool, does not participate in Certificate Transparency etc. There are literally hundreds to choose from. You can mount an attack in advance. Stuxnet suggests this is routine.
5. There are no alternatives that solves what secure DNS does. Key pinning and HSTS is important, but offer a trust-of-first-use model that can at best be complementary to a PKI. It is also important to note that HSTS shares the same deployment problems DNSSEC does. One mistake and your web server and domain is inaccessible. That is the reason none of the banks offer neither HSTS nor DANE. At least my bank sign their domain, so their step should be small.
The smoke-and-mirrors argument that DNSSEC gives governments control over "their" top level domains, when in fact it makes the scope of their control much smaller and more well defined, would be expected from someone who wants to maintain status quo as long as possible.
1. It's not my main argument, but, no: when a CA misbehaves, it is blacklisted (Google's done this). Google can't blacklist .com.
2. No. See FAQ.
3. No. See FAQ.
4. They can't do that if the certificate they're after is pinned. All they'll accomplish is getting the CA killed.
5. The thing DNSSEC secures simply doesn't need to be secured, any more than the IP options header does.
2/3. If you mean the FAQ you wrote yourself, it's misleading at this very point.
4. Pinning is useful, but it isn't a PKI. It's equally useful no matter how you issue certificates.
5. Domain name delegation are one of the Internet's weakest points today. Crypographic assurance of domain ownership would be very useful for a number of reasons.
And by doing so, the world would have evidence that somebody in that trust chain for that TLD has been lying. For TLS, that could be any CA in the world, which means that the number of single points of failure for services on DNSSEC is waaay lower. Because with DNSSEC you at least can chose who has the capability of forging results, with TLS alone that's all of the CA:s.
And why couldn't one combine the approaches anyway, using DNSSEC+DANE with certificate pinning? How would that possibly reduce security vs using standard DNS?
When deployed alone (i.e. without a DANE record, and using Web PKI
for certificate verification), SMTP STS offers the following
disadvantages compared to DANE:
o Infrastructure: DANE may be easier for some providers to deploy.
In particular, for providers who already support DNSSEC, SMTP STS
would additionally require they obtain a CA-signed x509
certificate for the recipient domain.
o Security: DANE offers an advantage against policy-lookup DoS
attacks; that is, while a DNSSEC-signed NX response to a DANE
lookup authoritatively indicates the lack of a DANE record, such
an option to authenticate policy non-existence does not exist when
looking up a policy over plain DNS.Please fix the DNS crap and you will be remembered in the history of those who gave a damn about totally broken stuff.
DNSCrypt: https://dnscrypt.org/ (pushed for ages by OpenDNS and supported by PowerDNS's dnsdist among others)
and, DNS over TLS: https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-...
And in any case, encrypting DNS won't solve the surveillance issue, since the HTTPS handshake sends the domain in clear-text, so that the server knows which certificate to send (https://en.wikipedia.org/wiki/Server_Name_Indication)
I can name thousands of critically important resources that do not use DNSSEC. For instance: any credit card transaction you make on the Internet will not, at any step in the process, involve DNSSEC. The same is true of any stock order at any retail brokerage, or any FIX connection between an exchange and a broker/dealer.
You picked a bad example. I can assure you that the clearing following that very card transaction would involve DNSSEC at least at one point, at least at one bank.