4 ms·

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 se

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
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.
- bryankeithmoore 9y ago
  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 ...
  - 3pt14159 9y ago
    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.
    - deleted 9y ago
      [deleted]
  - deleted 9y ago
    [deleted]
  - 9y ago
hannob 9y ago
There's a draft to cover server to server: https://tools.ietf.org/html/draft-ietf-uta-mta-sts-14 https://tools.ietf.org/html/draft-ietf-uta-mta-sts-14
jlgaddis 9y ago
> 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 https://tools.ietf.org/html/rfc6409 RFC7672: https://tools.ietf.org/html/rfc7672 https://tools.ietf.org/html/rfc7672 MTA-STS: https://tools.ietf.org/html/draft-ietf-uta-mta-sts-14 https://tools.ietf.org/html/draft-ietf-uta-mta-sts-14
- khm 9y ago
  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).
  - noblethrasher 9y ago
    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.
    - khm 9y ago
      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.

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

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.

bryankeithmoore 9y ago
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 ...
- 3pt14159 9y ago
  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.
  - deleted 9y ago
    [deleted]
- deleted 9y ago
  [deleted]
- 9y ago

hannob 9y ago

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

jlgaddis 9y ago

> 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 https://tools.ietf.org/html/rfc6409 RFC7672: https://tools.ietf.org/html/rfc7672 https://tools.ietf.org/html/rfc7672 MTA-STS: https://tools.ietf.org/html/draft-ietf-uta-mta-sts-14 https://tools.ietf.org/html/draft-ietf-uta-mta-sts-14

khm 9y ago
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).
- noblethrasher 9y ago
  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.
  - khm 9y ago
    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.