Re:The modern HTTPS world has no place for old web servers
by jlgaddis on Thursday May 14, 2020 @03:32AM
(#23176537)
> ... DANE has been seeing deployment success for SMTP, ...
Since "DANE for e-mail" is still relatively new / obscure, for the uninitiated, RFC7672 [0] describes "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", which requires DNSSEC -- and, as a result, comes with all of its associated disadvantages / trade-offs.
An alternative, more recent method of providing authenticated and encrypted delivery of e-mail is described in RFC8461 [1], "SMTP MTA Strict Transport Security (MTA-STS)", which uses DNS and HTTPS -- and, thus, relies on CAs / PKIX. MTA-STS doesn't require DNSSEC but it is then susceptible to "malicious downgrades".
Although we're not going to see all e-mail being encrypted in transit anytime soon (if we ever do), it's good to know that there are folks working on solutions, including at some of the largest e-mail providers.
Re:The modern HTTPS world has no place for old web servers
by tptacek on Friday May 15, 2020 @02:20AM
(#23189466)
MTA-STS doesn't so much "not require" DNSSEC so much as explicitly work around ever needing it; that's stated as one of the goals of the protocol in the RFC.
Since "DANE for e-mail" is still relatively new / obscure, for the uninitiated, RFC7672 [0] describes "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", which requires DNSSEC -- and, as a result, comes with all of its associated disadvantages / trade-offs.
An alternative, more recent method of providing authenticated and encrypted delivery of e-mail is described in RFC8461 [1], "SMTP MTA Strict Transport Security (MTA-STS)", which uses DNS and HTTPS -- and, thus, relies on CAs / PKIX. MTA-STS doesn't require DNSSEC but it is then susceptible to "malicious downgrades".
Although we're not going to see all e-mail being encrypted in transit anytime soon (if we ever do), it's good to know that there are folks working on solutions, including at some of the largest e-mail providers.
---
[0]: https://tools.ietf.org/html/rfc7672
[1]: https://tools.ietf.org/html/rfc8461