4 ms·

I think the real problem is (emphasis mine): > the MX record is vulnerable to manipulation unless DNSSEC is used, but people don't like DNSSEC which is why MTA

I think the real problem is (emphasis mine): > the MX record is vulnerable to manipulation unless DNSSEC is used, but people don't like DNSSEC which is why MTA-STS was invented This speaks volumes about the way these protocols are developed and subsequently implemented in software. People are not going to like complex solutions and that should be kept in mind when those protocols are being developed and implemented, otherwise its deployment is hampered just like we're seeing now with DNSSEC. In fact, now we've got MTA-STS because "people don't like DNSSEC", involving a whole HTTPS stack on both sides with so much more failure points just to send an email.

AndyMcConachie 5y ago
comcast.net is DNSSEC signed and Comcast was one of the first major ISPs to implement DNSSEC validation. Comcast's MX records are DNSSEC signed. > dig +dnssec comcast.net MX This has nothing to do with DNSSEC.
- Dylan16807 5y ago
  It has nothing to do with Comcast not liking DNSSEC. But if the ecosystem as a whole was happy about DNSSEC and DANE, it's somewhat doubtful we'd have both specs and the involvement of https.
  - tptacek 5y ago
    We would not. There'd be no reason to have MTA-STS if there was universal DNSSEC deployment. Of course, outages like this would be vastly more common, because DNSSEC includes a large superset of the failure modes of MTA-STS.
KennyBlanken 5y ago
It's not that people don't "like" DNSSEC. The author themselves states in a different post on their blog that DNSSEC is avoided like the plague because it is a royal pain in the ass to set up and outages at major corporations (coughSlackcough) that clearly have talented, knowledgeable, experienced ops people show that the standard was not designed with practical implementation in mind. "Security that is difficult to implement and can cause catastrophic-level outages not used by majority of internet; film at 11." Instead of lecturing everyone on how they should be using DNSSEC, what we should be doing is working on "DNSSEC 2.0", from lessons learned in the 2-3 decades people have been trying to use DNSSEC.
- tptacek 5y ago
  Exactly this. DNSSEC is needlessly complicated in large part because its service model was fixed in the mid-late 1990s, when the conventional wisdom was that DNS servers would never be powerful enough to actually perform cryptographic operations. A true DNSSEC 2.0 could simply forego the concept of offline signers (which has largely been foregone already, because online signing is necessary to serve secure NXDOMAINs without revealing all your hostnames) and sign/encrypt on demand. But DNSSEC 2.0 is unlikely to happen, because DoH solves most of the real-world on-the-wire problems with DNS security. There have always been two visions for how to secure the DNS: the top-down way, with signatures rolling down from the roots, a la DNSSEC, and the bottom-up way, where leaf servers allow individual clients to make secure queries, and we gradually converge on a secure DNS as more and more leafs make secure queries available. Top-down won at the IETF, but bottom-up is going to win the market.
  - octoberfranklin 5y ago
    aka DNSCurve. It may turn out that DNSSEC is useful, for exactly one thing: downloading the root zone securely. This circumvents any refusal to do signing-on-the-server by the root zone server operators. Here are the instructions: https://localroot.isi.edu/ https://localroot.isi.edu/ also: https://datatracker.ietf.org/doc/html/rfc8806 https://datatracker.ietf.org/doc/html/rfc8806
octoberfranklin 5y ago
See also: IPv6 instead of RFC 1710. https://datatracker.ietf.org/doc/html/draft-ietf-sipp-ipae-transition-00#section-5 https://datatracker.ietf.org/doc/html/draft-ietf-sipp-ipae-t... Twenty-six years later, we're still waiting for IPv6 to be considered "the Internet".

AndyMcConachie 5y ago

comcast.net is DNSSEC signed and Comcast was one of the first major ISPs to implement DNSSEC validation. Comcast's MX records are DNSSEC signed. > dig +dnssec comcast.net MX This has nothing to do with DNSSEC.

Dylan16807 5y ago
It has nothing to do with Comcast not liking DNSSEC. But if the ecosystem as a whole was happy about DNSSEC and DANE, it's somewhat doubtful we'd have both specs and the involvement of https.
- tptacek 5y ago
  We would not. There'd be no reason to have MTA-STS if there was universal DNSSEC deployment. Of course, outages like this would be vastly more common, because DNSSEC includes a large superset of the failure modes of MTA-STS.

KennyBlanken 5y ago

It's not that people don't "like" DNSSEC. The author themselves states in a different post on their blog that DNSSEC is avoided like the plague because it is a royal pain in the ass to set up and outages at major corporations (coughSlackcough) that clearly have talented, knowledgeable, experienced ops people show that the standard was not designed with practical implementation in mind. "Security that is difficult to implement and can cause catastrophic-level outages not used by majority of internet; film at 11." Instead of lecturing everyone on how they should be using DNSSEC, what we should be doing is working on "DNSSEC 2.0", from lessons learned in the 2-3 decades people have been trying to use DNSSEC.

tptacek 5y ago
Exactly this. DNSSEC is needlessly complicated in large part because its service model was fixed in the mid-late 1990s, when the conventional wisdom was that DNS servers would never be powerful enough to actually perform cryptographic operations. A true DNSSEC 2.0 could simply forego the concept of offline signers (which has largely been foregone already, because online signing is necessary to serve secure NXDOMAINs without revealing all your hostnames) and sign/encrypt on demand. But DNSSEC 2.0 is unlikely to happen, because DoH solves most of the real-world on-the-wire problems with DNS security. There have always been two visions for how to secure the DNS: the top-down way, with signatures rolling down from the roots, a la DNSSEC, and the bottom-up way, where leaf servers allow individual clients to make secure queries, and we gradually converge on a secure DNS as more and more leafs make secure queries available. Top-down won at the IETF, but bottom-up is going to win the market.
- octoberfranklin 5y ago
  aka DNSCurve. It may turn out that DNSSEC is useful, for exactly one thing: downloading the root zone securely. This circumvents any refusal to do signing-on-the-server by the root zone server operators. Here are the instructions: https://localroot.isi.edu/ https://localroot.isi.edu/ also: https://datatracker.ietf.org/doc/html/rfc8806 https://datatracker.ietf.org/doc/html/rfc8806

octoberfranklin 5y ago

See also: IPv6 instead of RFC 1710. https://datatracker.ietf.org/doc/html/draft-ietf-sipp-ipae-transition-00#section-5 https://datatracker.ietf.org/doc/html/draft-ietf-sipp-ipae-t... Twenty-six years later, we're still waiting for IPv6 to be considered "the Internet".