11 ms·
Internet Draft: SMTP Strict Transport Security
- zokier 11y agoVery interesting, seems like this would have potential to improve email transit security quite a bit. It is encouraging to see Google, Microsoft, Yahoo and Comcast in the authors, that would indicate that this has good chance of being applied to large portion of internet email. Of course email at rest security remains an issue, but that another story.
- vonklaus 11y ago> encouraging to see Google, Microsoft, Yahoo and Comcast 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.
- zokier 11y ago> less so if you think it is good for the internet to offload an outsize share of control to 5-10 corporations That has already happened a long time ago, so lets try to make the best of the situation.
- vonklaus 11y agoNo. 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.
- sarthakjain 11y agoGoogle, Yahoo, Gmail each have more than 300M active email accounts. Ships sailed hit the iceberg and they made a movie about it.
- AaronFriel 11y agoIs there anything about IETF standards that creates an outsize share of control for a limited number of corporations?
- dsr_ 11y agoOnly 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.
- djrogers 11y ago>swap Yahoo for Verizon and Apple 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.
- Macha 11y agoVerizon owns AOL now
- euyyn 11y agoFinally!
- Natanael_L 11y agoThose who have taken a close look, how comprehensive is this? Any risk of downgrade attacks, etc?
- jakobdabo 11y ago"SMTP STS relies on the certificate authority (CA) system and a trust-on-first-use (TOFU) approach to avoid interception. The TOFU model allows a degree of security similar to that of HPKP [RFC7469], reducing the complexity but without the guarantees on first use offered by DNSSEC." Also, can be used with DANE for additional security.
- tptacek 11y agoIf, like me, you believe the only real-world adversary for large-scale mail transport between places like Google and Yahoo is state-level actors and dragnet surveillance, then deploying DANE reduces your security, by tying you to trust anchors controlled by world governments. 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.
- jakobdabo 11y agoI agree that DNSSEC is a flawed technology and needs to be replaced, but I thought it can provide additional security (without doing harm) to STS against for example a malicious provider who can otherwise strip/modify the STS related records from the DNS traffic.
- tptacek 11y agoImportantly, just as with HSTS, once you successfully retrieve a counterparty's STS data, it's no longer straightforward for an ISP to strip that data from the DNS; it's cached, like a cookie. Which means as well that everyone who deploys STS will potentially join a collaborative anti-surveillance surveillance network (also one of the neat things about TLS certificate pinning).
- deleted 11y ago
- randomusr 11y agodo the same for the fucking DNS protocol, which is clear-text, it's the weapon of choice for all surveillance/censorship freaks and nobody cares about. And by 'nobody' I am not referring to actual random Joe users, but you - the fucking mastermind developers who create stuff that nobody cares about, hosted on .io domains just because it is cool and looks like some start-up that's about the be the next big thing. Please fix the DNS crap and you will be remembered in the history of those who gave a damn about totally broken stuff.
- jakobdabo 11y agoDNSCurve - https://en.wikipedia.org/wiki/DNSCurve https://en.wikipedia.org/wiki/DNSCurve
- randomusr 11y agoyou do realize that not even 0.001% of people use that, right? DNS has to be encrypted by default for everyone. As in client -> recursor. Without any 3rd party software.
- icebraining 11y agoThen you must ask the OS vendors to include it, not startup developers. 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 https://en.wikipedia.org/wiki/Server_Name_Indication)
- malka 11y agoOne could use a single certificate that is valid for all domain on the server
- icebraining 11y agoThe client would still send the domain, since it doesn't known the server only has one certificate (the domain is sent in the first message, the ClientHello).
- _RPM 11y agoInteresting to see the list of contributors from the various companies: Google, Inc, Yahoo!, Inc, Comcast, Inc, Microsoft, Inc, LinkedIn, 1&1 Mail & Media Development & Technology GmbH . One of my goals is to contribute to an RFC.
- virtuallynathan 11y agoJoin a working group mailing list and pay very close attention. Most of the work happens there, as opposed to at the 3x a year meeting.
- _RPM 11y agoI'm currently subscribed to the DNSOP mailing list, which is really interesting, except it's hard to follow since I just joined.
- tptacek 11y agoSuccessful deployment of STS would bring to zero the number of real-world use cases for DNSSEC/DANE, which would be a very good thing.
- jimktrains2 11y agoWhy? 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).
- yuhong 11y agoDNSSEC however has its own problems. I have been thinking of a DNSSEC2 proposal for a while now that for example would use online signing only.
- mned 11y agoHaving no support for offline signing in and of itself isn't a selling point. What else does your approach have to offer?
- yuhong 11y agoIt is a selling point in that it simplifies the protocol, making it easier to implement. Obviously it would not be the only difference.
- mned 11y ago> It is a selling point in that it simplifies the protocol, making it easier to implement. 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.
- devit 11y agoIt would be nice to also consider completely dropping support for non-TLS SMTP. 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.
- zanny 11y agoWell, we missed out on mandatory encryption in HTTP/2, despite that requiring the webserver to turn it on, so for some reason we still have a lobby for unsecured communications.
- MichaelGG 11y agoExcept browsers won't implement non-TLS HTTP2. So for all the use cases that matter, it's fine. Another good example of implementation trumping "standards".
- rurban 11y agoI only found https://github.com/mrisher/smtp-sts https://github.com/mrisher/smtp-sts so far, but this is just docs. Any implementations in the works?
- baudehlo 11y agoEveryone involved is working on implementations, as well as plenty who aren't involved.
- nly 11y agoWhy do we need to add support for protocols individually for this? Can't we just introduce a TLS extension and an API for detecting these "always use TLS" requests in OpenSSL etc.?
- jcrites 11y agoAt 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 https://tools.ietf.org/html/rfc3207
- baudehlo 11y agoSMTP starts in cleartext. That's the problem. 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.
- stonogo 11y agoThis seems like the slowest possible way to make no useful change. Literally every SMTP-capable software package on earth supports SMTPS on a dedicated port, which requires no changes to protocol. Why not just formalize and mandate this, instead of clinging to a braindead design that requires SMTP to munge the transport level? STARTTLS is a hack. It is not something to be preserved. If the goal is 100% TLS coverage, just mandate that (since everyone already supports it) and move on. 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.
- jcrites 11y agoExcellent! Strict transport security for SMTP has been sorely needed. Once it's widely deployed, it will finally ensure that virtually all email communication occurs over TLS. 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/ 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!
- baudehlo 11y agoWe 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.
- wizkkidd 11y agohttps://en.m.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.m.wikipedia.org/wiki/DNS-based_Authentication_of_...
- wizkkidd 11y agohttps://en.m.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.m.wikipedia.org/wiki/DNS-based_Authentication_of_...
- wizkkidd 11y agohttps://en.m.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.m.wikipedia.org/wiki/DNS-based_Authentication_of_...
- rubyfan 11y agoIs there a TL;DR version of how adding SSL will make it a whole lot better? Sorry to be dumb on this subject but my understanding of how email works (in particular SMTP) seems like the whole model is busted to begin with. 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.
- nxzero 11y agoAgree, idea that the carrier should be trusted or for that matter responsible for the security of a message is dated and largely meaningless security measure. As long as the message is able to be read by anyone other than the sender and intended recipient the message should be assumed as being insecure.
- baudehlo 11y agoHere is my vague attempt at ELI5: 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!
- danmarg 11y ago
- drdaeman 11y agoCan't we pretty much please make it reasonably generic and not SMTP-specific? 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.
- btown 11y agoSMTP needs this so desperately that it's worth making a customized solution - if there is a chance that making the standard generic would slow its adoption or development, it's probably best to do it this way. None of the others underpin, necessarily, a global communication infrastructure that powers the world of business.
- userbinator 11y agoThere are a lot more protocols that would benefit from the more generic and much simpler solution of "define a standard port where the service listens over TLS". IRCS has settled on 6697: https://tools.ietf.org/html/rfc7194 https://tools.ietf.org/html/rfc7194 IMAPS uses 993.
- aexaey 11y agoJust having a dedicated port for TLS-wrapped version of the protocol wouldn't help here. HTTPS has 443, yet we still need HSTS to enforce it. That said, dedicated SMTPS port would still be beneficial by cutting down at least 2 RTTs (HELO/EHLO + STARTTLS) from overall transaction time.
- richardwhiuk 11y agoXMPP is easy to enforce SSL connections on...
- wizkkidd 11y agoLOL...bunch of stuff why/why not with DANE when DANE really solves this...
- wizkkidd 11y agoPostfix supports Dane
- wizkkidd 11y agoDisadvantages When Used Without DANE 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.