5 ms·

> 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

by 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.

belorn 3y ago
> isn't that similar to providers managing/having access to the tls keys Yes. Cloudflare-like solutions has access to all the TLS keys. In addition, any cloud solution with with anycast will have partners that has access to all keys, and there is no validation that all partners will respond with the exact same information. The only non-security theater is self hosting of everything with hardware and software under the user's full control. > i have been wondering how common it is for DNS operators to just serve (the signed) zones that get sent in by domain owners. Very common. As a service it is usually called slave zone or hidden master. Practically all DNS providers have this as a product. The solution for public key roll over varies between providers, and some TLDs have started to use CDS/CSYNC which removes the registrar from the whole chain. CDS/CSYNC is however a bit more rare so the more common method is to either use long lived keys or a registrar API for uploading new keys.
- tptacek 3y ago
  Whatever else you think about registrars and DNS providers managing DNSSEC, it simply is the case that none of this counts as "adoption". It's not "adoption" if domain owners aren't adopting it, and it's especially not adoption if the largest and most important domains fastidiously avoid it. You could get anything adopted Internetwide instantly if you just had ISPs quietly turn it on for everybody.
  - teddyh 3y ago
    Does HTTPS adoption somehow not count if your web site provider adopts it, but not you? That is what you are essentially arguing. And just as most people do not run their own web server, even fewer people run their own DNS servers.
    - tptacek 3y ago
      HTTPS adoption is universal. I don't have to pick apart the different modes and qualities of adoption. Most major websites won't even let you not use it anymore. The comparison is risible.
      - teddyh 3y ago
        > I don't have to pick apart the different modes and qualities of adoption. Actually, you do have to make proper counter-arguments. That is how a debate works. Simply declaring your opponent's arguments as "risible" is not cool. If you please, explain how DNSSEC adoption is different from HTTPS adoption. They seem to have quite close analogs: In the usual case, both are done by the server operators (authoritative DNS server and web server, respectively), not by the end customers themselves, and the server operators also handle and hold all related public and private keys. You seem to be arguing upthread that DNSSEC adoption somehow does not count since the end customer does not hold the keys themselves. But the same is the case for typical web hosting. So how is this different?
        tptacek 3y ago

by mjl- 3y ago

belorn 3y ago

> isn't that similar to providers managing/having access to the tls keys Yes. Cloudflare-like solutions has access to all the TLS keys. In addition, any cloud solution with with anycast will have partners that has access to all keys, and there is no validation that all partners will respond with the exact same information. The only non-security theater is self hosting of everything with hardware and software under the user's full control. > i have been wondering how common it is for DNS operators to just serve (the signed) zones that get sent in by domain owners. Very common. As a service it is usually called slave zone or hidden master. Practically all DNS providers have this as a product. The solution for public key roll over varies between providers, and some TLDs have started to use CDS/CSYNC which removes the registrar from the whole chain. CDS/CSYNC is however a bit more rare so the more common method is to either use long lived keys or a registrar API for uploading new keys.

tptacek 3y ago
Whatever else you think about registrars and DNS providers managing DNSSEC, it simply is the case that none of this counts as "adoption". It's not "adoption" if domain owners aren't adopting it, and it's especially not adoption if the largest and most important domains fastidiously avoid it. You could get anything adopted Internetwide instantly if you just had ISPs quietly turn it on for everybody.
- teddyh 3y ago
  Does HTTPS adoption somehow not count if your web site provider adopts it, but not you? That is what you are essentially arguing. And just as most people do not run their own web server, even fewer people run their own DNS servers.
  - tptacek 3y ago
    HTTPS adoption is universal. I don't have to pick apart the different modes and qualities of adoption. Most major websites won't even let you not use it anymore. The comparison is risible.
    - teddyh 3y ago
      > I don't have to pick apart the different modes and qualities of adoption. Actually, you do have to make proper counter-arguments. That is how a debate works. Simply declaring your opponent's arguments as "risible" is not cool. If you please, explain how DNSSEC adoption is different from HTTPS adoption. They seem to have quite close analogs: In the usual case, both are done by the server operators (authoritative DNS server and web server, respectively), not by the end customers themselves, and the server operators also handle and hold all related public and private keys. You seem to be arguing upthread that DNSSEC adoption somehow does not count since the end customer does not hold the keys themselves. But the same is the case for typical web hosting. So how is this different?
      - tptacek 3y ago