5 ms·

Situation with certificate authorities is just getting ridiculous. Before that a lot of extensions were introduced to somehow (poorly) cover other security ris

Situation with certificate authorities is just getting ridiculous. Before that a lot of extensions were introduced to somehow (poorly) cover other security risks (CRL, OSCP, CT Log, ...). Now we admit that secure certificate issuance requires DNSSEC to be in place in order to make CAA work securely. Then why we have ditched DANE[1] in the first place? Why not infer public key trust directly from domain keys of DNSSEC? With dependence on DNSSEC, certificate authorities becoming fifth wheel. [1]: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

tialaramex 4y ago
DANE wasn't deployable. It turns out that a lot of clients out there use some crappy DNS server, maybe they're required to, maybe that's just default configuration but either way that's not going to get fixed. 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. When we send them anything else except 1995 style web browser queries they freak out, and either try to reply to it as though it was an A? query or they ignore the query. So you ask FANCY_MODERN_RECORD? web.site.example and it replies with an IP address even though that record's answer is a 64 byte compressed blob, or it silently ignores you... Here in 2022 things have changed... but only slightly. We mostly got DNS servers to answer AAAA? by doing something at least vaguely sane, in some cases even actual IPv6 answers like the specification says. We think some other records work, although not always. And clients learned "Happy eyeballs" a strategy to just try everything and use whatever worked. But many of the servers out there are still crap. The biggest change in 2022 is that lots of clients (especially web browsers) talk DoH. If you speak DoH (or DoT or any of these protocols but in practice it's DoH) you can actually get good answers from somebody whose DNS server works, a tremendous improvement. The browsers have by various means forced outfits who run such servers to actually do a competent job. Which means they implement DNSSEC, and, since the transport is TLS encrypted, you can choose to trust their validation answer. Which means today arguably DANE is somewhat deployable. But more practically, meanwhile we built a bunch of stuff which means instead of clients needing to do DANE, we can get away with DNSSEC to specialists. Many real world web users have crappy DNS, but Let's Encrypt can get traction or change to a different provider or build their own servers or whatever they want because it's part of their core mission.
- strenholme 4y ago
  We mostly got DNS servers to answer AAAA? That's the sense I get. Back in early 2011, there was still an issue where crappy DNS servers would sometimes respond to AAAA record requests with a "Server fail" error. Because of this, I had to tweak my recursive DNS server to treat a server fail to an AAAA request as if the AAAA record did not exist. This made IPv6 resolution more fragile, but it had to be done because of the state of the internet in early 2011. I finally removed that "feature" here in 2022, when someone asked why I handled server fail responses to AAAA requests in this unusual manner.
- throw0101c 4y ago
  > 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.
    - 4y ago

tialaramex 4y ago

DANE wasn't deployable. It turns out that a lot of clients out there use some crappy DNS server, maybe they're required to, maybe that's just default configuration but either way that's not going to get fixed. 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. When we send them anything else except 1995 style web browser queries they freak out, and either try to reply to it as though it was an A? query or they ignore the query. So you ask FANCY_MODERN_RECORD? web.site.example and it replies with an IP address even though that record's answer is a 64 byte compressed blob, or it silently ignores you... Here in 2022 things have changed... but only slightly. We mostly got DNS servers to answer AAAA? by doing something at least vaguely sane, in some cases even actual IPv6 answers like the specification says. We think some other records work, although not always. And clients learned "Happy eyeballs" a strategy to just try everything and use whatever worked. But many of the servers out there are still crap. The biggest change in 2022 is that lots of clients (especially web browsers) talk DoH. If you speak DoH (or DoT or any of these protocols but in practice it's DoH) you can actually get good answers from somebody whose DNS server works, a tremendous improvement. The browsers have by various means forced outfits who run such servers to actually do a competent job. Which means they implement DNSSEC, and, since the transport is TLS encrypted, you can choose to trust their validation answer. Which means today arguably DANE is somewhat deployable. But more practically, meanwhile we built a bunch of stuff which means instead of clients needing to do DANE, we can get away with DNSSEC to specialists. Many real world web users have crappy DNS, but Let's Encrypt can get traction or change to a different provider or build their own servers or whatever they want because it's part of their core mission.

strenholme 4y ago
We mostly got DNS servers to answer AAAA? That's the sense I get. Back in early 2011, there was still an issue where crappy DNS servers would sometimes respond to AAAA record requests with a "Server fail" error. Because of this, I had to tweak my recursive DNS server to treat a server fail to an AAAA request as if the AAAA record did not exist. This made IPv6 resolution more fragile, but it had to be done because of the state of the internet in early 2011. I finally removed that "feature" here in 2022, when someone asked why I handled server fail responses to AAAA requests in this unusual manner.
throw0101c 4y ago
> 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.
  - 4y ago