4 ms·

"SMTP STS relies on the certificate authority (CA) system and a trust-on-first-use (TOFU) approach to avoid interception. The TOFU model allows a degree of secu

"SMTP STS relies on the certificate authority (CA) system and a trust-on-first-use (TOFU) approach to avoid interception. The TOFU model allows a degree of security similar to that of HPKP [RFC7469], reducing the complexity but without the guarantees on first use offered by DNSSEC." Also, can be used with DANE for additional security.

tptacek 11y ago
If, like me, you believe the only real-world adversary for large-scale mail transport between places like Google and Yahoo is state-level actors and dragnet surveillance, then deploying DANE reduces your security, by tying you to trust anchors controlled by world governments. DANE is generally a bad idea, and it's great that STS is explicitly proposed as an alternative to it, not an application of it.
- jakobdabo 11y ago
  I agree that DNSSEC is a flawed technology and needs to be replaced, but I thought it can provide additional security (without doing harm) to STS against for example a malicious provider who can otherwise strip/modify the STS related records from the DNS traffic.
  - tptacek 11y ago
    Importantly, just as with HSTS, once you successfully retrieve a counterparty's STS data, it's no longer straightforward for an ISP to strip that data from the DNS; it's cached, like a cookie. Which means as well that everyone who deploys STS will potentially join a collaborative anti-surveillance surveillance network (also one of the neat things about TLS certificate pinning).
- deleted 11y ago
  [deleted]
- nly 11y ago
  The CA system already uses the DNS as a trust anchor, and will continue to do so as long as DV certs are the standard. DANE likely would not have enabled any form of attack that isn't already possible. What DANE would have done is end the madness that allows me to hack your wordpress blog for a day and then go get myself a certificate for your domain, for free, that doesn't expire for three years. A certificate you will never be able to detect the issue thereof and cannot easily revoke if you do. And STS isn't an 'alternative' to DANE. The two are completely orthogonal
  - tptacek 11y ago
    Arguments like this presuppose that the TLS security system is exactly as it was in 1999. But, of course, it isn't: major sites all pin certificates now, so that if you're well-equipped enough to subvert a CA and you use it to try to subvert a major site, there's a very good chance that literally all you'll accomplish is getting that entire CA blacklisted. STS and DANE aren't orthogonal. DNSSEC/DANE offers such marginal value to HTTPS that the browsers that once offered pilot support for it have now eliminated that code; it is off the roadmap for the web. The remaining motivating use case for DNSSEC was SMTP security; DANE was a way to ensure that MTAs used secure transports and avoided downgrade attacks. But STS does the same thing without requiring the forklift replacement of DNS that DNSSEC requires.
    - nly 11y ago
      I don't know where to begin. > Arguments like this presuppose that the TLS security system is exactly as it was in 1999 For the majority, it is. The % of sites that deploy all of the latest HTTPS bells and whistles, even just looking at the minority of sites that actually enable TLS, is in the low single digits. Only 8% of sites surveyed by Qualys SSL Labs... sites that are presumably run by people who care about security, unlike my bank, even bother to enable HSTS. > major sites all pin certificates now My bank doesn't. Enabling HPKP and HSTS is just risky from a commercial point-of-view. People aren't good at key management. If you botch it, you make your site inaccessible and you lose customers. People screw it up all the time. I've done it. I was speaking to someone just today who was over-zealous with 'includeSubdomains' and made their product blog inaccessible (it was on a blog subdomain, which had an invalid TLS setup because wordpress.com don't support TLS on custom domains). It happens. > if you're well-equipped enough to subvert a CA Strawman, I never held this up as a threat. In any case, it's a bad defence of PKI. Being able to choose from N CAs doesn't help you. You only have to subvert one CA to own the world, just like DANE, where an attacker only has to break your registrar, or the domain registry, and you're toast. The 'world governments' you fear have the capability and thensome. Irrelevant. The threat I explicitly mentioned is that if I own your DNS, I can get myself a cert for you domain. This has the same same threat models as DANE (if "owning your DNS" involves me compromising your DNS server and getting your DNSSEC keys, or guessing your domain registrar password), except DANE doesn't depend on horrible, ineffective, and privacy-invasive, hacks like OSCP... or allow me to simply keep certificates for domains I no longer own. DNS caching effectively gives you the equivalent of OCSP stapling for free. > major sites all pin certificates now TLSA records have all the configurability and capability of HPKP and more, and can be applied to any protocol/endpoint. They even cross the isle to work with the CA system if you so desire, unlike HSTS+HPKP which has become hostile to anything self-signed. > STS and DANE aren't orthogonal They are. DANE relates to key-pinning via TLSA records, not HSTS. > forklift replacement of DNS that DNSSEC requires. DNSSEC is backward compatible. You're talking twaddle. Enabling it these days, if you control your own DNS server, also takes seconds. With EC digital signatures, it's even sensible. Setting up HPKP+HSTS+OSCP stapling is far more fiddley...and stuck in the RSA stone age.

tptacek 11y ago

If, like me, you believe the only real-world adversary for large-scale mail transport between places like Google and Yahoo is state-level actors and dragnet surveillance, then deploying DANE reduces your security, by tying you to trust anchors controlled by world governments. DANE is generally a bad idea, and it's great that STS is explicitly proposed as an alternative to it, not an application of it.

jakobdabo 11y ago
I agree that DNSSEC is a flawed technology and needs to be replaced, but I thought it can provide additional security (without doing harm) to STS against for example a malicious provider who can otherwise strip/modify the STS related records from the DNS traffic.
- tptacek 11y ago
  Importantly, just as with HSTS, once you successfully retrieve a counterparty's STS data, it's no longer straightforward for an ISP to strip that data from the DNS; it's cached, like a cookie. Which means as well that everyone who deploys STS will potentially join a collaborative anti-surveillance surveillance network (also one of the neat things about TLS certificate pinning).
deleted 11y ago
[deleted]
nly 11y ago
The CA system already uses the DNS as a trust anchor, and will continue to do so as long as DV certs are the standard. DANE likely would not have enabled any form of attack that isn't already possible. What DANE would have done is end the madness that allows me to hack your wordpress blog for a day and then go get myself a certificate for your domain, for free, that doesn't expire for three years. A certificate you will never be able to detect the issue thereof and cannot easily revoke if you do. And STS isn't an 'alternative' to DANE. The two are completely orthogonal
- tptacek 11y ago
  Arguments like this presuppose that the TLS security system is exactly as it was in 1999. But, of course, it isn't: major sites all pin certificates now, so that if you're well-equipped enough to subvert a CA and you use it to try to subvert a major site, there's a very good chance that literally all you'll accomplish is getting that entire CA blacklisted. STS and DANE aren't orthogonal. DNSSEC/DANE offers such marginal value to HTTPS that the browsers that once offered pilot support for it have now eliminated that code; it is off the roadmap for the web. The remaining motivating use case for DNSSEC was SMTP security; DANE was a way to ensure that MTAs used secure transports and avoided downgrade attacks. But STS does the same thing without requiring the forklift replacement of DNS that DNSSEC requires.
  - nly 11y ago
    I don't know where to begin. > Arguments like this presuppose that the TLS security system is exactly as it was in 1999 For the majority, it is. The % of sites that deploy all of the latest HTTPS bells and whistles, even just looking at the minority of sites that actually enable TLS, is in the low single digits. Only 8% of sites surveyed by Qualys SSL Labs... sites that are presumably run by people who care about security, unlike my bank, even bother to enable HSTS. > major sites all pin certificates now My bank doesn't. Enabling HPKP and HSTS is just risky from a commercial point-of-view. People aren't good at key management. If you botch it, you make your site inaccessible and you lose customers. People screw it up all the time. I've done it. I was speaking to someone just today who was over-zealous with 'includeSubdomains' and made their product blog inaccessible (it was on a blog subdomain, which had an invalid TLS setup because wordpress.com don't support TLS on custom domains). It happens. > if you're well-equipped enough to subvert a CA Strawman, I never held this up as a threat. In any case, it's a bad defence of PKI. Being able to choose from N CAs doesn't help you. You only have to subvert one CA to own the world, just like DANE, where an attacker only has to break your registrar, or the domain registry, and you're toast. The 'world governments' you fear have the capability and thensome. Irrelevant. The threat I explicitly mentioned is that if I own your DNS, I can get myself a cert for you domain. This has the same same threat models as DANE (if "owning your DNS" involves me compromising your DNS server and getting your DNSSEC keys, or guessing your domain registrar password), except DANE doesn't depend on horrible, ineffective, and privacy-invasive, hacks like OSCP... or allow me to simply keep certificates for domains I no longer own. DNS caching effectively gives you the equivalent of OCSP stapling for free. > major sites all pin certificates now TLSA records have all the configurability and capability of HPKP and more, and can be applied to any protocol/endpoint. They even cross the isle to work with the CA system if you so desire, unlike HSTS+HPKP which has become hostile to anything self-signed. > STS and DANE aren't orthogonal They are. DANE relates to key-pinning via TLSA records, not HSTS. > forklift replacement of DNS that DNSSEC requires. DNSSEC is backward compatible. You're talking twaddle. Enabling it these days, if you control your own DNS server, also takes seconds. With EC digital signatures, it's even sensible. Setting up HPKP+HSTS+OSCP stapling is far more fiddley...and stuck in the RSA stone age.