5 ms·

fwiw, i live in a country where rolling out dnssec apparently had some financial incentives for providers, which apparently helped adoption: https://stats.sidnl

by mjl- 3y ago

fwiw, i live in a country where rolling out dnssec apparently had some financial incentives for providers, which apparently helped adoption: https://stats.sidnlabs.nl/en/dnssec.html https://stats.sidnlabs.nl/en/dnssec.html adoption still growing, more than 60% of .nl domains currently dnssec-signed, and around 60% of queries are from validation resolvers. i looked up global stats. world map + tables about current validating resolver queries: https://stats.labs.apnic.net/dnssec https://stats.labs.apnic.net/dnssec. and this is the graph over time of for the world: https://stats.labs.apnic.net/dnssec/XA https://stats.labs.apnic.net/dnssec/XA (30% validating, don't know what the additional 10% mixed means). i did a quick search, but didn't find global stats about domains being dnssec-signed. dnssec is not easy/simple (especially when getting into the details), but i think the contemporary dns servers make it relatively easy to enable dnssec on a zone, managing the signing themselves. i do like the idea of being able to set up secure connections without relying on CAs.

ekr____ 3y ago
The fraction of validating queries is misleading because practically all validation happens in the recursive resolver, which doesn't provide security all the way to the client. At least as far as browser clients goes, we're as far away from setting up connections based on DNSSEC-validated keys as ever.
- mjl- 3y ago
  > The fraction of validating queries is misleading because practically all validation happens in the recursive resolver, which doesn't provide security all the way to the client. At least as far as browser clients goes, we're as far away from setting up connections based on DNSSEC-validated keys as ever. fair point, perhaps partially compensated through tls-protection for recursive dns. don't know how common that is. i wonder whether there is any move by e.g. linux distro's towards including a dnssec-verifying resolver by default. whether they think it's not worth the trouble, or what the inflection point will be. i usually install unbound on new machines. i believe openbsd comes with unbound by default? assuming that's with dnssec-validation enabled. i used to dislike the unhelpful generic error messages for dnssec-related problems (servfail). perhaps that was holding adoption back. but extended dns errors (ede) seem to solve that, though i don't know how commonly the detailed errors make it up the stack in old software.
  - ekr____ 3y ago
    > fair point, perhaps partially compensated through tls-protection for recursive dns. don't know how common that is. Yes, but this isn't a replacement for the WebPKI because it would allow the recursive to impersonate any site, which is obviously unacceptable. > i wonder whether there is any move by e.g. linux distro's towards including a dnssec-verifying resolver by default. whether they think it's not worth the trouble, or what the inflection point will be. i usually install unbound on new machines. i believe openbsd comes with unbound by default? assuming that's with dnssec-validation enabled. A year or so ago we took some measurements of DNSSEC success rates with Firefox on known-good domains that we controlled and the results were very bad. I don't have the data to hand right at the moment, but requiring DNSSEC validation would have produced unacceptably high failure rates.
tptacek 3y ago
Couple things here. First: the European provider DNSSEC adoption stuff is all based on the providers managing and custodying keys for their customers, which is security theater. We'd have universal DNSSEC adoption if nobody ever managed their own DNS! Second: the prospects of DNSSEC replacing CAs are slim-to-nil, since browser experiments with actually using DANE failed. Third: even if a browser did enable DANE, so that some fraction of users could "rely" on it, they'd still be honoring the WebPKI, and you'd be a trivial downgrade attack away from being put back into the WebPKI CA infrastructure. Fourth, and finally, the roots of trust in DNSSEC are themselves commercial entities, and they're less trustworthy (if that's possible for you to imagine) than commercial CAs, because they're not required to participate in a public ledger like CT. Really, though, LetsEncrypt was the death knell for the DANE use case. Certificates are free now, and always will be.
- jcranmer 3y ago
  I was going to say that the DANE PGPKEY stuff was another interesting use case for DANE, but on doing a search for clients who supported it, it seems the answer there has just been to use a .well-known https: url instead. If even the PGP enthusiasts can't be bothered to use the approach, it must be well and truly dead.
- mjl- 3y ago
  > providers managing and custodying keys for their customers, which is security theater isn't that similar to providers managing/having access to the tls keys? well, dns is a bit more essential. but plain dns isn't more secure. ideally we can all only access our own keys, but that doesn't seem to be the standard. i have been wondering how common it is for dns operators to just serve (the signed) zones that get sent in by domain owners. and if that has technical hurdles for the operators (i'm sure the reason for many domain owners is they want to outsource responsibility). > DNSSEC replacing CAs are slim-to-nil, since browser experiments with actually using DANE failed seems like it for browsers. it seems dane for mail has a future. the alternative to dane, pki-based mta-sts, has downsides like tofu for policies and needing long-lived cachable policies, especially not great given the decentralized nature. currently, many domains have no protection for deliveries (unverified mx records & tls certs). found this just now, interesting: https://ripe86.ripe.net/presentations/51-2023-05-23-dnssec.pdf https://ripe86.ripe.net/presentations/51-2023-05-23-dnssec.p... mentions tls with dane records inside. but not necessarily hopeful for dnssec, it is hard to change infrastructure. i always wonder to what extent new protocols are lobbied and their rollout preplanned vs hoping for the best. > you'd be a trivial downgrade attack away from being put back into the WebPKI CA infrastructure. i often wonder why not more "signals" about how to connect are in dns. perhaps lack of dnssec. with dnssec that becomes an option, preventing a downgrade. probably bad middleboxes that don't let certain dns requests through (a reason to encrypt). the trend seems to be https on a subdomain that serves a policy. > Fourth, and finally, the roots of trust in DNSSEC are themselves commercial entities, and they're less trustworthy (if that's possible for you to imagine) than commercial CAs, because they're not required to participate in a public ledger like CT. i should update my knowledge exactly on the good/bad about the dnssec trust roots. if there are good docs out there, i'm interested. > Really, though, LetsEncrypt was the death knell for the DANE use case. Certificates are free now, and always will be. true, it doesn't seem like we're in bad position with LE. and they keep getting better (shorter-lived certs). though perhaps we're getting a little bit reliant on this one CA.

by mjl- 3y ago

ekr____ 3y ago

The fraction of validating queries is misleading because practically all validation happens in the recursive resolver, which doesn't provide security all the way to the client. At least as far as browser clients goes, we're as far away from setting up connections based on DNSSEC-validated keys as ever.

mjl- 3y ago
> The fraction of validating queries is misleading because practically all validation happens in the recursive resolver, which doesn't provide security all the way to the client. At least as far as browser clients goes, we're as far away from setting up connections based on DNSSEC-validated keys as ever. fair point, perhaps partially compensated through tls-protection for recursive dns. don't know how common that is. i wonder whether there is any move by e.g. linux distro's towards including a dnssec-verifying resolver by default. whether they think it's not worth the trouble, or what the inflection point will be. i usually install unbound on new machines. i believe openbsd comes with unbound by default? assuming that's with dnssec-validation enabled. i used to dislike the unhelpful generic error messages for dnssec-related problems (servfail). perhaps that was holding adoption back. but extended dns errors (ede) seem to solve that, though i don't know how commonly the detailed errors make it up the stack in old software.
- ekr____ 3y ago
  > fair point, perhaps partially compensated through tls-protection for recursive dns. don't know how common that is. Yes, but this isn't a replacement for the WebPKI because it would allow the recursive to impersonate any site, which is obviously unacceptable. > i wonder whether there is any move by e.g. linux distro's towards including a dnssec-verifying resolver by default. whether they think it's not worth the trouble, or what the inflection point will be. i usually install unbound on new machines. i believe openbsd comes with unbound by default? assuming that's with dnssec-validation enabled. A year or so ago we took some measurements of DNSSEC success rates with Firefox on known-good domains that we controlled and the results were very bad. I don't have the data to hand right at the moment, but requiring DNSSEC validation would have produced unacceptably high failure rates.

tptacek 3y ago

Couple things here. First: the European provider DNSSEC adoption stuff is all based on the providers managing and custodying keys for their customers, which is security theater. We'd have universal DNSSEC adoption if nobody ever managed their own DNS! Second: the prospects of DNSSEC replacing CAs are slim-to-nil, since browser experiments with actually using DANE failed. Third: even if a browser did enable DANE, so that some fraction of users could "rely" on it, they'd still be honoring the WebPKI, and you'd be a trivial downgrade attack away from being put back into the WebPKI CA infrastructure. Fourth, and finally, the roots of trust in DNSSEC are themselves commercial entities, and they're less trustworthy (if that's possible for you to imagine) than commercial CAs, because they're not required to participate in a public ledger like CT. Really, though, LetsEncrypt was the death knell for the DANE use case. Certificates are free now, and always will be.

jcranmer 3y ago
I was going to say that the DANE PGPKEY stuff was another interesting use case for DANE, but on doing a search for clients who supported it, it seems the answer there has just been to use a .well-known https: url instead. If even the PGP enthusiasts can't be bothered to use the approach, it must be well and truly dead.
mjl- 3y ago
> providers managing and custodying keys for their customers, which is security theater isn't that similar to providers managing/having access to the tls keys? well, dns is a bit more essential. but plain dns isn't more secure. ideally we can all only access our own keys, but that doesn't seem to be the standard. i have been wondering how common it is for dns operators to just serve (the signed) zones that get sent in by domain owners. and if that has technical hurdles for the operators (i'm sure the reason for many domain owners is they want to outsource responsibility). > DNSSEC replacing CAs are slim-to-nil, since browser experiments with actually using DANE failed seems like it for browsers. it seems dane for mail has a future. the alternative to dane, pki-based mta-sts, has downsides like tofu for policies and needing long-lived cachable policies, especially not great given the decentralized nature. currently, many domains have no protection for deliveries (unverified mx records & tls certs). found this just now, interesting: https://ripe86.ripe.net/presentations/51-2023-05-23-dnssec.pdf https://ripe86.ripe.net/presentations/51-2023-05-23-dnssec.p... mentions tls with dane records inside. but not necessarily hopeful for dnssec, it is hard to change infrastructure. i always wonder to what extent new protocols are lobbied and their rollout preplanned vs hoping for the best. > you'd be a trivial downgrade attack away from being put back into the WebPKI CA infrastructure. i often wonder why not more "signals" about how to connect are in dns. perhaps lack of dnssec. with dnssec that becomes an option, preventing a downgrade. probably bad middleboxes that don't let certain dns requests through (a reason to encrypt). the trend seems to be https on a subdomain that serves a policy. > Fourth, and finally, the roots of trust in DNSSEC are themselves commercial entities, and they're less trustworthy (if that's possible for you to imagine) than commercial CAs, because they're not required to participate in a public ledger like CT. i should update my knowledge exactly on the good/bad about the dnssec trust roots. if there are good docs out there, i'm interested. > Really, though, LetsEncrypt was the death knell for the DANE use case. Certificates are free now, and always will be. true, it doesn't seem like we're in bad position with LE. and they keep getting better (shorter-lived certs). though perhaps we're getting a little bit reliant on this one CA.