4 ms·

SMTP 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 rece

SMTP 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 ago
This 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.
- danmarg 11y ago
  If you required TLS on all SMTP, you would in fact end up having to fail a large number of messages. 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.com/en//pubs/archive/43962.pdf http://static.googleusercontent.com/media/research.google.co... 2. e.g. http://arstechnica.com/information-technology/2016/02/gmail-to-warn-you-if-your-friends-arent-using-secure-email/ http://arstechnica.com/information-technology/2016/02/gmail-...
  - stonogo 11y ago
    >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. 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.
    - danmarg 11y ago
      But I think the authentication problem is in fact the hard problem. Assuming we got rid of STARTTLS (the actual verb) and just always did TLS (say, on some other port), how do you propose to solve it?
      - stonogo 11y ago
        Fortunately, we have an extensible protocol that already supports service advertising and negotiation. There's no reason we can't have an AUTH module that works both ways (both the client and server mutually authenticate, independent of the transport-layer encryption).
nly 11y ago
I don't see a problem here. Just try TLS first always. If it fails and you haven't seen a STS flag for the server, then try plaintext. This should work with any protocol. There's not a whole lot of gain from doing this, except SSL client libs could provide an API for it rather than having to munge every higher protocol to support some kind of STS mechanism.

stonogo 11y ago

This 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.

danmarg 11y ago
If you required TLS on all SMTP, you would in fact end up having to fail a large number of messages. 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.com/en//pubs/archive/43962.pdf http://static.googleusercontent.com/media/research.google.co... 2. e.g. http://arstechnica.com/information-technology/2016/02/gmail-to-warn-you-if-your-friends-arent-using-secure-email/ http://arstechnica.com/information-technology/2016/02/gmail-...
- stonogo 11y ago
  >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. 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.
  - danmarg 11y ago
    But I think the authentication problem is in fact the hard problem. Assuming we got rid of STARTTLS (the actual verb) and just always did TLS (say, on some other port), how do you propose to solve it?
    - stonogo 11y ago
      Fortunately, we have an extensible protocol that already supports service advertising and negotiation. There's no reason we can't have an AUTH module that works both ways (both the client and server mutually authenticate, independent of the transport-layer encryption).

nly 11y ago

I don't see a problem here. Just try TLS first always. If it fails and you haven't seen a STS flag for the server, then try plaintext. This should work with any protocol. There's not a whole lot of gain from doing this, except SSL client libs could provide an API for it rather than having to munge every higher protocol to support some kind of STS mechanism.