Hacker News Reader

Comment by jlgaddis | Hacker News Reader

> 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

View on HN

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.

Reply on news.ycombinator.com