3 ms·

> Crappy DNS servers basically only know how to "make the web work" in the sense it worked in about 1995. They expect questions like A? some.web.server.example

> Crappy DNS servers basically only know how to "make the web work" in the sense it worked in about 1995. They expect questions like A? some.web.server.example and they reply with an IP address, it might be the right IP address, but not always. These servers of course have no idea DNSSEC exists. That's not a good reason not to deploy DNSSEC. If DNSSEC/DANE is deployed, and some clients cannot make use of it because they are shitty, why hold back the non-shitty clients that can deal with DNSSEC/DANE? Just because 100% coverage for all clients isn't possible doesn't mean we shouldn't try to move the ball forward. The perfect is the enemy of the good (/improvement).

tptacek 4y ago
No, it's subtly harder than that. It's not that some clients will get a better experience than others, it's that in an environment of widespread reliability issues, browsers and other TLS clients will need to develop a downgrade protocol to handle the cases where DNSSEC lookups don't work. That downgrade protocol will inevitably break, like every other cryptographic downgrade ever tried. By way of example: until a year or two ago, the last great hope of DANE was on stapled DANE records as a TLS handshake extension. No DNS lookups would even be required. But then, years into the project, somebody realized that attackers would just be able to strip those extensions off of handshakes. The only thing that prevented the attack was the Web PKI roots of trust --- which is what DANE was trying to augment in the first place.
- tialaramex 4y ago
  What would prevent what you're calling "stripping" is that a client which wants to see DANE records won't accept the "stripped" connection because it doesn't have any DANE records and none are stapled. That's true for any imaginable mechanism, if you "strip" the intermediates with conventional Web PKI certificates you're in the same place, if the client has the information already (e.g. a modern Firefox) the connection works and security is maintained, if not the connection fails. The stapling RFC was deliberately sabotaged, by the browser vendors and they more or less openly admitted that. Not their finest moment. The TLS WG (dominated by people working for the browsers) adopted the stapling work saying we'll run with this, and then after stalling for several years they basically said this doesn't do what browsers want (it's for DANE and the browsers have decided they don't want to do DANE) so we aren't going to publish. This is a great way to be an asshole, and if that was actually the goal (which it appears was the case to at least some extent) then I guess bravo.
  - tptacek 4y ago
    My understanding of what happened and what you're talking about is that the antidote to this problem was yet another continuity mechanism, like pinning and HSTS; it doesn't protect first connections, and is a contraption. To a first approximation, DANE is essentially a browser protocol. Obviously, things besides browsers speak TLS, but browsers are the overwhelming primary audience. If the browsers don't want to do DANE, that's a very strong signal. Sorry, I have more to say about this. I feel like there's a general attitude among some IETF people and DANE bystanders (especially people from the European DNS community) that feel like browsers are arbitrary, capricious gatekeepers of how TLS works; that we could have working DANE everywhere but for lazy browser people who don't want to work through the deployment drama, maybe? But that overlooks the fact that the Web PKI is a partnership between the browsers (the root programs in particular) and the PKI providers. Neither side is working entirely on its own, both sides are sort of intensely engaged with each other. We have the Web PKI we have now, with free automated issuance, transparency, and toothy CA revocation, because of a real (if fraught) partnership. Nothing like that appears to exist in the DNS community? Tell me I'm wrong. Why should I believe any of this would work?
Avamander 4y ago
> If DNSSEC/DANE is deployed, and some clients cannot make use of it because they are shitty, why hold back the non-shitty clients that can deal with DNSSEC/DANE? Just because 100% coverage for all clients isn't possible doesn't mean we shouldn't try to move the ball forward. Because that's only the first step. After that you have to solve all the problems WebPKI has already solved for itself. Two primary things - the ability to remove trust anchors and visibility into issuance. Neither of which are in any means doable or solved with DNSSEC at this point in time.
- marcosdumay 4y ago
  The Web PKI has solved none of those, as evidenced by this article. Not without DNSSEC.
  - tptacek 4y ago
    You just rebutted a comment nobody made, and ignored the comment that was made. Like it, and the article itself, says: the DNS PKI hasn't addressed revocation and visibility. The Web PKI has: CAs are required to submit to CT logs, and the browser root programs have killed some of the largest commercial CAs for noncompliance. Neither of those is possible, or will be possible, in the DNS PKI.
    - dane-pgp 4y ago
      > Neither of those is possible, or will be possible, in the DNS PKI. Transparency logs for domain issuance is completely possible, it just requires some engineering and deployment. Remember that HTTPS was in use for decades before CT logging of certificates became mandatory. More importantly, though, we need to be clear about what "noncompliance" means. In the web PKI, it means a CA issuing a certificate for a domain that the requester doesn't control, but the equivalent for that in the DNS PKI would be TLD .foo publishing data for a domain example.bar which is not an attack at all, because no one would care what .foo thinks about a .bar domain. So, rather than relying on browsers being brave enough to kill a large provider (and we need to be honest with ourselves about how much leeway browsers would give to Let's Encrypt if they ever suffered a catastrophic security breach), the DNS PKI simply isn't vulnerable to this problem, because TLDs can't issue certs for domains that aren't registered under them.

tptacek 4y ago

No, it's subtly harder than that. It's not that some clients will get a better experience than others, it's that in an environment of widespread reliability issues, browsers and other TLS clients will need to develop a downgrade protocol to handle the cases where DNSSEC lookups don't work. That downgrade protocol will inevitably break, like every other cryptographic downgrade ever tried. By way of example: until a year or two ago, the last great hope of DANE was on stapled DANE records as a TLS handshake extension. No DNS lookups would even be required. But then, years into the project, somebody realized that attackers would just be able to strip those extensions off of handshakes. The only thing that prevented the attack was the Web PKI roots of trust --- which is what DANE was trying to augment in the first place.

tialaramex 4y ago
What would prevent what you're calling "stripping" is that a client which wants to see DANE records won't accept the "stripped" connection because it doesn't have any DANE records and none are stapled. That's true for any imaginable mechanism, if you "strip" the intermediates with conventional Web PKI certificates you're in the same place, if the client has the information already (e.g. a modern Firefox) the connection works and security is maintained, if not the connection fails. The stapling RFC was deliberately sabotaged, by the browser vendors and they more or less openly admitted that. Not their finest moment. The TLS WG (dominated by people working for the browsers) adopted the stapling work saying we'll run with this, and then after stalling for several years they basically said this doesn't do what browsers want (it's for DANE and the browsers have decided they don't want to do DANE) so we aren't going to publish. This is a great way to be an asshole, and if that was actually the goal (which it appears was the case to at least some extent) then I guess bravo.
- tptacek 4y ago
  My understanding of what happened and what you're talking about is that the antidote to this problem was yet another continuity mechanism, like pinning and HSTS; it doesn't protect first connections, and is a contraption. To a first approximation, DANE is essentially a browser protocol. Obviously, things besides browsers speak TLS, but browsers are the overwhelming primary audience. If the browsers don't want to do DANE, that's a very strong signal. Sorry, I have more to say about this. I feel like there's a general attitude among some IETF people and DANE bystanders (especially people from the European DNS community) that feel like browsers are arbitrary, capricious gatekeepers of how TLS works; that we could have working DANE everywhere but for lazy browser people who don't want to work through the deployment drama, maybe? But that overlooks the fact that the Web PKI is a partnership between the browsers (the root programs in particular) and the PKI providers. Neither side is working entirely on its own, both sides are sort of intensely engaged with each other. We have the Web PKI we have now, with free automated issuance, transparency, and toothy CA revocation, because of a real (if fraught) partnership. Nothing like that appears to exist in the DNS community? Tell me I'm wrong. Why should I believe any of this would work?

Avamander 4y ago

> If DNSSEC/DANE is deployed, and some clients cannot make use of it because they are shitty, why hold back the non-shitty clients that can deal with DNSSEC/DANE? Just because 100% coverage for all clients isn't possible doesn't mean we shouldn't try to move the ball forward. Because that's only the first step. After that you have to solve all the problems WebPKI has already solved for itself. Two primary things - the ability to remove trust anchors and visibility into issuance. Neither of which are in any means doable or solved with DNSSEC at this point in time.

marcosdumay 4y ago
The Web PKI has solved none of those, as evidenced by this article. Not without DNSSEC.
- tptacek 4y ago
  You just rebutted a comment nobody made, and ignored the comment that was made. Like it, and the article itself, says: the DNS PKI hasn't addressed revocation and visibility. The Web PKI has: CAs are required to submit to CT logs, and the browser root programs have killed some of the largest commercial CAs for noncompliance. Neither of those is possible, or will be possible, in the DNS PKI.
  - dane-pgp 4y ago
    > Neither of those is possible, or will be possible, in the DNS PKI. Transparency logs for domain issuance is completely possible, it just requires some engineering and deployment. Remember that HTTPS was in use for decades before CT logging of certificates became mandatory. More importantly, though, we need to be clear about what "noncompliance" means. In the web PKI, it means a CA issuing a certificate for a domain that the requester doesn't control, but the equivalent for that in the DNS PKI would be TLD .foo publishing data for a domain example.bar which is not an attack at all, because no one would care what .foo thinks about a .bar domain. So, rather than relying on browsers being brave enough to kill a large provider (and we need to be honest with ourselves about how much leeway browsers would give to Let's Encrypt if they ever suffered a catastrophic security breach), the DNS PKI simply isn't vulnerable to this problem, because TLDs can't issue certs for domains that aren't registered under them.