6 ms·

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

77 points by okket 9y ago

peterwwillis 9y ago
Email is about to get a lot less reliable.
- ts4z 9y ago
  This has been status quo stuff for basically the last ten years. This will be fine.
  - peterwwillis 9y ago
    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.
    - bryankeithmoore 9y ago
      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.
SheinhardtWigCo 9y ago
Email itself ought to be Considered Obsolete. It’s about time for a replacement based on decentralized privacy-preserving protocols like Matrix and IPFS.
- pmilot 9y ago
  How is TLS email not decentralized and/or privacy-preserving?
  - SheinhardtWigCo 9y ago
    The answer is in the title: TLS for Email Submission and Access Email providers can still read your email.
    - bryankeithmoore 9y ago
      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.
korethr 9y ago
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.
- bryankeithmoore 9y ago
  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.
  - korethr 9y ago
    I believe I found them. I'll take a look and offer any comments I think are relevant.
- 3pt14159 9y ago
marcosdumay 9y ago
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"?
- deleted 9y ago
  [deleted]
- dhx 9y ago
  IANA has already assigned TCP port 465 for "submissions" as described by RFC8314. See https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=9 https://www.iana.org/assignments/service-names-port-numbers/... The other service already assigned TCP port 465 was URL Rendezvous Directory for SSM (URD).
- jlgaddis 9y ago
  cf. section 7.3 of the linked RFC.
leggomylibro 9y ago
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 https://en.wikipedia.org/wiki/OSI_model
- tptacek 9y ago
  An architectural counterpoint would be David Clark's Application Layer Framing paper: https://www.cc.gatech.edu/classes/AY2007/cs7260_spring/papers/alf.pdf https://www.cc.gatech.edu/classes/AY2007/cs7260_spring/paper...

77 points by okket 9y ago

peterwwillis 9y ago

Email is about to get a lot less reliable.

ts4z 9y ago
This has been status quo stuff for basically the last ten years. This will be fine.
- peterwwillis 9y ago
  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.
  - bryankeithmoore 9y ago
    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.

SheinhardtWigCo 9y ago

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

pmilot 9y ago
How is TLS email not decentralized and/or privacy-preserving?
- SheinhardtWigCo 9y ago
  The answer is in the title: TLS for Email Submission and Access Email providers can still read your email.
  - bryankeithmoore 9y ago
    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.

korethr 9y ago

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.

bryankeithmoore 9y ago
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.
- korethr 9y ago
  I believe I found them. I'll take a look and offer any comments I think are relevant.
3pt14159 9y ago

marcosdumay 9y ago

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"?

deleted 9y ago
[deleted]
dhx 9y ago
IANA has already assigned TCP port 465 for "submissions" as described by RFC8314. See https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=9 https://www.iana.org/assignments/service-names-port-numbers/... The other service already assigned TCP port 465 was URL Rendezvous Directory for SSM (URD).
jlgaddis 9y ago
cf. section 7.3 of the linked RFC.

leggomylibro 9y ago

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 https://en.wikipedia.org/wiki/OSI_model

tptacek 9y ago
An architectural counterpoint would be David Clark's Application Layer Framing paper: https://www.cc.gatech.edu/classes/AY2007/cs7260_spring/papers/alf.pdf https://www.cc.gatech.edu/classes/AY2007/cs7260_spring/paper...