5 ms·

What you're talking about is DANE. RFC 6698 https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_A

What you're talking about is DANE. RFC 6698 https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na... I wrote a short explanation of how it works a while back. https://www.metafarce.com/adventures-in-dane.html https://www.metafarce.com/adventures-in-dane.html The short answer is that DANE has been seeing deployment success for SMTP, but has yet to see much deployment success for HTTPS. https://stats.dnssec-tools.org/ https://stats.dnssec-tools.org/

AndyMcConachie 6y ago
I'm one of the few weirdos that actually validates DANE for HTTPS using some software I wrote called Danish. Once in Python https://github.com/smutt/danish https://github.com/smutt/danish And again in Rust. https://github.com/smutt/danish-rust https://github.com/smutt/danish-rust An old explanation can be found here. https://www.middlebox-dane.org/ https://www.middlebox-dane.org/ Both middlebox-dane.org and metafarce.com have DNS TLSA records that match their certificate from Let's Encrypt. You can do this, but almost no one is. There is some pickup in The Netherlands where I live. For example, www.digid.nl has delpoyed DANE for HTTPS.
jlgaddis 6y ago
> ... 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. --- [0]: https://tools.ietf.org/html/rfc7672 https://tools.ietf.org/html/rfc7672 [1]: https://tools.ietf.org/html/rfc8461 https://tools.ietf.org/html/rfc8461
- tptacek 6y ago
  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.

AndyMcConachie 6y ago

I'm one of the few weirdos that actually validates DANE for HTTPS using some software I wrote called Danish. Once in Python https://github.com/smutt/danish https://github.com/smutt/danish And again in Rust. https://github.com/smutt/danish-rust https://github.com/smutt/danish-rust An old explanation can be found here. https://www.middlebox-dane.org/ https://www.middlebox-dane.org/ Both middlebox-dane.org and metafarce.com have DNS TLSA records that match their certificate from Let's Encrypt. You can do this, but almost no one is. There is some pickup in The Netherlands where I live. For example, www.digid.nl has delpoyed DANE for HTTPS.

jlgaddis 6y ago

> ... 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. --- [0]: https://tools.ietf.org/html/rfc7672 https://tools.ietf.org/html/rfc7672 [1]: https://tools.ietf.org/html/rfc8461 https://tools.ietf.org/html/rfc8461

tptacek 6y ago
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.