5 ms·

That exists, and is called DNS-Based Authentication of Named Entities (DANE) [0], and there are proposals for making use of that in TLS. There is no need to st

That exists, and is called DNS-Based Authentication of Named Entities (DANE) [0], and there are proposals for making use of that in TLS. There is no need to start over for transport security. TLS 1.3 is very well designed and will eventually support DANE. [0] https://tools.ietf.org/html/rfc6698

tptacek 8y ago
The "DANE" proposal has been around for over a decade, and was actually implemented (probably twice, but at least in Chrome) and then rescinded, because it in practice doesn't work. But even if it did work, it would still represent a further centralization of trust on the Internet, this time with the central authorities that matter being effectively controlled by governments. DANE is a dead letter.
- cryptonector 8y ago
  DANE definitely works for SMTP. Chrome's efforts at stapling DANE failed, but I think for the wrong reasons.
  - tptacek 8y ago
    No. DANE did such a bad job for SMTP that the major email providers banded together and created an alternate, non-DNSSEC-dependent standard, MTA-STS, to work around it.
    - cryptonector 8y ago
      I'm sorry, but that's nonsense. MTA-STS is about sites that are having trouble deploying DNSSEC. DNSSEC != DANE. DANE depends on DNSSEC.
      - tptacek 8y ago
        No, sorry, the MTA-STS draft itself is clear about this distinction. Also, your argument is circular. DANE definitely does not "work" for SMTP. The necessity for DNSSEC in SMTP is, I think, a desperate trope† that recognizes that the Web PKI has moved past considering DANE and begun investing in direct hardening for the X.509 system. SMTP is other mainstream protocol for which transport security couldn't be guaranteed, is mired in the late 1990s technologically, and doesn't inherit modern browser- and server- based protection. So: SMTP! SMTP is the reason we need DNSSEC! We must get DNSSEC deployed immediately so everyone can have secure SMTP! Except, you know who doesn't agree with you? The people who the most important email services. Hence: MTA-STS --- a standard whose introduction spells out its raison d'être: to avoid DANE! --- and the mooting of that last fragile argument for deploying DNSSEC. DANE is a dead letter. † I'm choosing words carefully
- ietf-dane 8y ago
  [ For the record, not an invitation to a futile further debate, given your long-standing immutably-held views on DNSSEC. Since you'll probably say the same about my work to get DANE for SMTP up and running, we can stop here. All I can add is that those who say it can't be done should not get in the way of the people doing it... :-) ] No, the major providers did not get together to do MTA-STS because DANE was bad. They did it because their existing DNS geo-balancing kit for e.g. google.com and yahoo.com does not offer an easy upgrade path to DNSSEC. Note that Microsoft has a dedicated domain (outlook.com) for email hosting, and can more easily do DNSSEC there without impacting their other "web properties". Note also that Google now MX-hosts many customer domains on "googlemail.com" rather than google.com. So things are starting to change. Furthermore, there are now over 1 million DANE-enabled DNSSEC domains. MTA-STS is far behind, is not downgrade-resistant on first contact and uses weak CA-leap-of-faith DV authentication. It will probably be enabled at the biggest providers by the end of this year, but as you yourself said elsewhere, these providers are the threat, and if so, securing email delivery to the user surveillance empires is not necessarily that important. Mind you, they can play a useful role by enabling validation and helping to keep the TLSA records of receiving systems valid, and perhaps surveillance is not their business for paying customers...
  - tptacek 8y ago
    The IETF draft itself says that the primary motivation for MTA-STS is to provide transport security when DNSSEC is "undesirable or impractical". You don't have to take my word for it. There are a million DANE-enabled DNSSEC domains because there are registrars, particularly in Europe, that enable it automatically. Who cares? First of all, DNSSEC managed by your registrar is security theater, but, more importantly, the overwhelming majority of those domains do not matter. Who cares if some landing page in the Netherlands has TLSA records? Meanwhile, the domains that really do matter --- the ones managed by the major mail providers --- are doing MTA-STS. SMTP is not a success case for DNSSEC.
    - ietf-dane 8y ago
      gmx.de, comcast.net, freenet.de, mailbox.org, posteo.de and tutanota.de come to mind as counter-examples as well as various universities, the German parliament, various Dutch government domains, and a couple of thousand self-hosted SOHO domains. But DNSSEC is axiomatically evil, so I must be wrong...

tptacek 8y ago

The "DANE" proposal has been around for over a decade, and was actually implemented (probably twice, but at least in Chrome) and then rescinded, because it in practice doesn't work. But even if it did work, it would still represent a further centralization of trust on the Internet, this time with the central authorities that matter being effectively controlled by governments. DANE is a dead letter.

cryptonector 8y ago
DANE definitely works for SMTP. Chrome's efforts at stapling DANE failed, but I think for the wrong reasons.
- tptacek 8y ago
  No. DANE did such a bad job for SMTP that the major email providers banded together and created an alternate, non-DNSSEC-dependent standard, MTA-STS, to work around it.
  - cryptonector 8y ago
    I'm sorry, but that's nonsense. MTA-STS is about sites that are having trouble deploying DNSSEC. DNSSEC != DANE. DANE depends on DNSSEC.
    - tptacek 8y ago
      No, sorry, the MTA-STS draft itself is clear about this distinction. Also, your argument is circular. DANE definitely does not "work" for SMTP. The necessity for DNSSEC in SMTP is, I think, a desperate trope† that recognizes that the Web PKI has moved past considering DANE and begun investing in direct hardening for the X.509 system. SMTP is other mainstream protocol for which transport security couldn't be guaranteed, is mired in the late 1990s technologically, and doesn't inherit modern browser- and server- based protection. So: SMTP! SMTP is the reason we need DNSSEC! We must get DNSSEC deployed immediately so everyone can have secure SMTP! Except, you know who doesn't agree with you? The people who the most important email services. Hence: MTA-STS --- a standard whose introduction spells out its raison d'être: to avoid DANE! --- and the mooting of that last fragile argument for deploying DNSSEC. DANE is a dead letter. † I'm choosing words carefully
ietf-dane 8y ago
[ For the record, not an invitation to a futile further debate, given your long-standing immutably-held views on DNSSEC. Since you'll probably say the same about my work to get DANE for SMTP up and running, we can stop here. All I can add is that those who say it can't be done should not get in the way of the people doing it... :-) ] No, the major providers did not get together to do MTA-STS because DANE was bad. They did it because their existing DNS geo-balancing kit for e.g. google.com and yahoo.com does not offer an easy upgrade path to DNSSEC. Note that Microsoft has a dedicated domain (outlook.com) for email hosting, and can more easily do DNSSEC there without impacting their other "web properties". Note also that Google now MX-hosts many customer domains on "googlemail.com" rather than google.com. So things are starting to change. Furthermore, there are now over 1 million DANE-enabled DNSSEC domains. MTA-STS is far behind, is not downgrade-resistant on first contact and uses weak CA-leap-of-faith DV authentication. It will probably be enabled at the biggest providers by the end of this year, but as you yourself said elsewhere, these providers are the threat, and if so, securing email delivery to the user surveillance empires is not necessarily that important. Mind you, they can play a useful role by enabling validation and helping to keep the TLSA records of receiving systems valid, and perhaps surveillance is not their business for paying customers...
- tptacek 8y ago
  The IETF draft itself says that the primary motivation for MTA-STS is to provide transport security when DNSSEC is "undesirable or impractical". You don't have to take my word for it. There are a million DANE-enabled DNSSEC domains because there are registrars, particularly in Europe, that enable it automatically. Who cares? First of all, DNSSEC managed by your registrar is security theater, but, more importantly, the overwhelming majority of those domains do not matter. Who cares if some landing page in the Netherlands has TLSA records? Meanwhile, the domains that really do matter --- the ones managed by the major mail providers --- are doing MTA-STS. SMTP is not a success case for DNSSEC.
  - ietf-dane 8y ago
    gmx.de, comcast.net, freenet.de, mailbox.org, posteo.de and tutanota.de come to mind as counter-examples as well as various universities, the German parliament, various Dutch government domains, and a couple of thousand self-hosted SOHO domains. But DNSSEC is axiomatically evil, so I must be wrong...