RFC 8314: Use of Transport Layer Security for Email Submission and Access | Hacker News Reader

RFC 8314: Use of Transport Layer Security for Email Submission and Access

tools.ietf.org

77 pointsokket44 comments

So reading this, this attempts to standardize what I understood to be best practice last time I ran a mail server - TLS required for submission and access. I see this as a good thing.

But this doesn't seem to touch on transmission between email servers at all, and that needs to be addressed as well. Email can be submitted protected by TLS, but if it has to cross the Internet in the clear to reach its recipient, then all you've succeeded in doing with submission/access TLS is prevented your user's login credentials from leaking. You've not done much to protect the confidentiality of your user's correspondence. Understand, I'm not denigrating the importance of TLS for submission and access, but it's also not the whole picture.

Yes, you can set your SMTP server to opportunistically use TLS when the other connecting SMTP server supports it as well, but not all SMTP servers do. Mandating TLS makes those servers that don't effectively unreachable. I seem to recall Facebook doing a study about it. The Postfix documentation warns about it as well.

I'm not sure I have a good solution here, other than something akin to the linked RFC: a proposed standard that gives a deprecation/sunset period to transition to mandatory TLS. The problem then, is getting majority compliance during that period. If the IPv6 transition is any indication, that's likely to be an uphill battle, as mandatory TLS between SMTP servers would break a rather large installed base that's presently working just fine.

See my reply below. My draft originally included the mail relaying case but trying to address both submission and relaying in the same document made the document unwieldy. In theory they both use the same protocol (more-or-less) but there are numerous subtle differences that make the two cases vastly different when negotiating encryption.

The IETF UTA working group has documents in process to address the mail relaying case; I'm sure they'd appreciate review and feedback.

I believe I found them. I'll take a look and offer any comments I think are relevant.

The solution here is for Gmail and a few other large providers to announce a date where they will no longer send or accept email from insecure servers. This sounds drastic, but it's not. I've seen military contractors and patent attorneys sending email and attachments with no security at all. We need to stop pretending that security doesn't matter.

For the case of mail submission, there is a lot of legacy hardware/firmware out there still in use that simply doesn't support TLS, and is mission-critical, and is likely to become obsolete before anyone upgrades it. A lot of that traffic is considered nonsensitive by those who need it so trying to force them to be secure isn't going to go over well. Despite that, RFC 8314 recommends that MSPs deprecate cleartext submission and mail access, but it doesn't specify a timetable because the situations vary too widely from one provider to another.

For message relaying, your proposal might indeed work. The vast majority of inter-domain mail traffic goes through a very small number of providers. No mail provider can afford to not be able to exchange mail with gmail, or office365, or ...

This type of thinking is how we get ants.

It is trivial to set up a mail server with TLS and if you don't have fucking TLS bounce it through a protocol upgrade server. If you understood the type of secrets that are getting trivially intercepted you'd realize that a couple hard days for a couple of lazy sys admins is a tiny price to pay for the drastic increase in security.

People are literally getting killed because we're so fucking lazy. Even three letter agencies are sending mail without TLS, this is madness.

Even if they define a 5 to 10 years warning before "deprecating" it is better than finding ourselves in the same hole the same amount of years from now.

What mission critical legacy hardware/firmware doesn't support TLS and is sending email to gmail?

Anyone running that mission critical hardware is free to keep using insecure email, no one is going to stop that. If they really need to send email from that old hardware to gmail, they can set up their own relay that accepts non-tls connections but relays using TLS.

Nearly every printer/copier with a scan-to-email feature in a small-to-medium size business that has moved their all their servers and email into the cloud.

It's drastic enough not to be realistic, it would break mail for too many people, who would blame it on Gmail.

What the big sites can do is add a delay when receiving from a plaintext relay, in a manner similar to greylisting and tarpiting that are widely deployed. The mail is not rejected, just delayed. The delay can be proportional to the amount of mail sent by a domain, and set to increase in time. The same can be done for outgoing mail to domains that don't advertise STARTTLS, drop the connection and retry later.

In the first phase, just issue a warning then drop the first submission attempt, to fillup the logs with a clear message that STARTTLS is strongly preferred. Gradually increase the delay so that large sites have trouble emptying their queue, and continue to increase the delay until the last holdouts can be simply shut out.

The advantage with this approach is that the user of Gmail, Yahoo etc. does not see a problem with his account, while the smaller sites and users will have delays when sending mail and receiving mail and be forced to take action.

I'm pretty sure users would also blame delays on the receiving provider, not the sender (and they wouldn't be wrong, technically). I can picture a user saying "Oh, sometimes it takes ages for mail to arrive to my Gmail address, please send that document to username@<minor provider which doesn't delay mail>".

The key here is to have an implementation schedule crafted so there is a massive differential impact on a selected group of small providers and a negligible impact on overall performance. After issuing warnings for a few months, put a cap on the number of plain-text submissions per domain, large enough to affect just the worldwide top 5-10 domains in that group. As more domains comply, roll that window, so as to keep just a very small fraction of total mail volume delayed, both incoming and outgoing. Since mail delays are common, the risk of switching by your own customers is low, and special exceptions can be made for accounts that communicate with an affected domain often.

It's essential that the major email domains work together so that the users of small non-encrypting domains feel a generalized performance impact, not just a problem with Gmail or just Yahoo.

There's a draft to cover server to server: https://tools.ietf.org/html/draft-ietf-uta-mta-sts-14

> But this doesn't seem to touch on transmission between email servers at all, and that needs to be addressed as well.

No, this RFC doesn't address that -- as illustrated in the title ("...for Email Submission/Access").

As mentioned in section 1 ("Introduction") of the linked RFC:

  This memo does not address the use of TLS with
  SMTP for message relay (where Message Submission
  [RFC6409] does not apply).  Improving the use of
  TLS with SMTP for message relay requires a different
  approach.  One approach to address that topic is
  described in [RFC7672]; another is provided in
  [MTA-STS].

Note that "MTA-STS" ("MTA Strict Transport Security", similar to HSTS in function) is currently a draft. Feedback is solicited and very much welcome.

RFC6409: https://tools.ietf.org/html/rfc6409

RFC7672: https://tools.ietf.org/html/rfc7672

MTA-STS: https://tools.ietf.org/html/draft-ietf-uta-mta-sts-14

MTA-STS is pretty ill-conceived. In essence it mandates that compliant MTAs also run a concurrent web service. The authors do not explain why this is useful instead of the simpler approach -- enhance SMTP to reject mail on port 25 with a NEEDS-TLS error, then fall back to implicit TLS (what port 465 was originally for).

The system needs to be able to authenticate a DNS-resolved endpoint. HTTPS provides this.

Of course, they could have gone with DNSSEC, but HTTPS has the virtue of solving the same problem (modulo proper configuration), while also being more widely deployed and better understood.

HTTPS does not provide authentication sufficiently well to put every egg in its basket.

As for "better understood," the authors of this standard work for Google, Verizon, Microsoft, and Comcast. Combined they probably serve most of the email in the western hemisphere.

There is no excuse for overcomplicating a proposed standard -- and "we have this stuff lying around" is no exception. This plan has the effect of causing a networking protocol to depend on an entire series of unrelated networking protocols.

It does not bode well for the future of independent email operators and it provides no path forward for integrating existing devices. It pushes many, many extra steps onto client devices, necessitating entire additional libraries of software to deal with them. That's not a problem for companies with tens of thousands of developers at their beck and call -- but it is only going to raise the barrier-to-entry of operating an independent service.

Those sound like reasonable objections. Are you posting them to the discussions involved in shaping and ratifying the proposed standard?

What does https do that's different from verifying the cert chain and matching the cn to the hostname? Is this about the ill-conceived cert-pinning that pretends distributing keys for every domain is a scalable alternative to certificate authorities and on-line revocation lists?

An MTA-STS web server is also used for policy discovery, and the HTTPS requirement ensures that the policy is authentic.

Fun fact, the OSI network stack (which wound up losing out to TCP/IP) defined a 'presentation' layer which was meant to handle things like compression and encryption in a way that was transparent to the application logic 'above' it:

https://en.wikipedia.org/wiki/OSI_model

An architectural counterpoint would be David Clark's Application Layer Framing paper:

https://www.cc.gatech.edu/classes/AY2007/cs7260_spring/paper...

So, is IANA going along with registering the port 465 this time, or it will only be another case of "somebody tries to do the right thing; stupid bureaucracy insists it's wrong; case closed"?

IANA has already assigned TCP port 465 for "submissions" as described by RFC8314. See https://www.iana.org/assignments/service-names-port-numbers/...

The other service already assigned TCP port 465 was URL Rendezvous Directory for SSM (URD).

cf. section 7.3 of the linked RFC.

Email is about to get a lot less reliable.

This has been status quo stuff for basically the last ten years. This will be fine.

No it hasn't. "Optional" has been the status quo, meaning a lot of shit remained broken. "Mandatory" means everyone now has to deal with all the broken shit, and the stuff that re-breaks, and the stuff that gets exploited, on and on ad infinitum. This is guaranteed to make less reliable services.

Nothing gets fixed until people realize it's broken. And yet, it's also true that using TLS for mail submission and access has been best common practice for several years, with most providers specifying TLS in their connection instructions and some even deprecating cleartext. This RFC might result in more service calls as users start being told their connections aren't secure, but it also tells providers what to do to fix the problem.

Email itself ought to be Considered Obsolete. It’s about time for a replacement based on decentralized privacy-preserving protocols like Matrix and IPFS.

How is TLS email not decentralized and/or privacy-preserving?

The answer is in the title: TLS for Email Submission and Access

Email providers can still read your email.

This document only addresses email submission and access because a single document that covered email submission, access, relaying, key lookup/verification, and message encryption would be huge and take forever to get consensus on. It made more sense to divide up the work. It just happens that this piece got finished first, probably because it's the simplest piece. Others are working on improving the security of relaying which is harder because in general there's no a priori explicit relationship between an SMTP client and an SMTP server relaying the message - so the client has no way to know on initial contact whether its connection with the server has been intercepted (which would allow the interceptor to downgrade the connection to cleartext and thwart automatic future use of TLS). But even when relaying is more secure, the messages will still be in the format submitted while being relayed, and after being delivered - i.e. usually cleartext.

Making whole message encryption work on a large scale, and incrementally deployable, is hard, because there are lots of corner cases to deal with. For instance, if you leave messages encrypted on the recipient's server, then the server can't assist in searching the text of those messages, which makes searching slow and especially bad for mobile devices. Or you want to know when sending a message if it's safe to encrypt it or not, but even if you define some service to query whether there's a public key associated with the recipient's domain name, that service may not work well if the recipient has their mail forwarded elsewhere. You want the message encryption service to be widely applicable but you also want the user interface to be simple - and corner cases complicate user interfaces.

Or you could start over from scratch (as has been and is being tried by others) and see how hard it is to displace the existing system without an incremental upgrade path. Hopefully we'll get there one way or another.

You don't need an email provider, you can just set up a mail server on your own computer. If the person you are sending your mail to also has their own mail server you send it directly to them without any provider every seeing it.

EDIT: Yes I know... It's not trivial to setup and keep running, "own computer" might need to mean hosted somewhere (VPS, datacenter, etc), and all your contacts might also need to setup mail servers because providers like Gmail might reject your mails. In the end it might not be worth your time, but there's absolutely no technical reason why you'd need a mail provider for emails.

Except that most consumer ISPs block outgoing traffic on port 25 to make spamming more difficult. So you won't be able to send mail directly to the recipient's SMTP server.

> You don't need an email provider, you can just set up a mail server on your own computer.

Not really. It's not possible to send mail from a dynamic IP at all, and there is a lot of technical minutia to not get thrown in the spam folder for major providers. In fact, many major providers simply assume mail sent from an unfamiliar domain and/or IP is spam by default, and you will have to contact them to ask for permission to send to them.

> and there is a lot of technical minutia to not get thrown in the spam folder for major providers. In fact, many major providers simply assume mail sent from an unfamiliar domain and/or IP is spam by default, and you will have to contact them to ask for permission to send to them.

These myths are popular, in my experience they are not true.

> These myths are popular, in my experience they are not true.

I am speaking from personal experience. I've run my own mail server for about 15 years.

A few months I had to publicly complain on twitter about Microsoft blocking my email in order to get them to stop putting my email in the spam folder (after having to move to a new IP). Their support people before I publicly complained just kept responding with a form letter with advice for commercial senders sending transactional, newsletter and marketing content.

I haven't asked anybody for permission, yet email still works. Just follow the basics. Reverse DNS, SPF and DKIM will instantly grant you a place in non-spam.

I just went through the pain of switching to a new IP for my mail server a few months ago.

All major providers except Google were putting my messages in the spam folder by default despite me getting myself whitelisted in DNSWL and having proper FcRDNS, SPF, DKIM and DMARC configuration.

The IP was not in any reputable public blacklists, and the domain had been in use for many years.

Did you check the reputation of your /24 neighborhood?

I have seen Microsoft blocking entire /24 neighborhoods on the basis of a single IP sending spam.

You were probably hit by that as collateral damage.

Yes, I did. It was clean as far as I could tell. It was not just Microsoft, I also had issues with Yahoo, AOL and some others. The block I'm in is listed in some RBL called "spamgrouper"[1] but as far as I can tell nobody pays attention to it. No other lists showed any trouble.

1. http://www.spamgrouper.to/

> ...and all your contacts might also need to setup mail servers

If you can already get your contacts to install software for you, why stay with email at all? You might as well use Telegram, SSB or whatever you want then.

Email is still the most compatible system with ... literally everthing.

Reply on news.ycombinator.com