5 ms·

> 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

by 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
        HTTPS is universally adopted. Meanwhile: the DNSSEC root keys could land on Pastebin tonight and nobody would need to be paged. The distinction is so clear that trying to pick apart the description seems disingenuous. I don't think you're experiencing me being evasive so much as that I simply don't accept your premises.
        teddyh 3y ago
        > the DNSSEC root keys could land on Pastebin tonight and nobody would need to be paged. I disagree with this ludicrous assertion, but you are answering a different question, so I will not pursue this question at this time, in favor of the issue at hand: Upthread, you wrote that with “DNS providers managing DNSSEC”, “none of this counts as "adoption”. Why not? You also wrote that “providers managing and custodying keys for their customers […] is security theater”. How is this different from HTTPS keys? Why are HTTPS keys not “security theater”, but DNSSEC keys are?
        tptacek 3y ago
        I'm genuinely interested, because I've asked this question a bunch of times to a bunch of different audiences and never gotten an answer. So that thought experiment again: the DNSSEC root keys are fatally compromised. What are some specific entities that will require an immediate security response? Put differently: what specific entities depend today in any significant way on DNSSEC? Remember when you're thinking about this that most (virtually all, really) of the largest and/or most important organizations on the Internet don't use DNSSEC, so it wouldn't make any difference at all to them. And, in case this needs saying, it doesn't really count (in the spirit of this thought experiment) if the entity you think of is, like, a DNSSEC provider; stipulate, DNSSEC providers themselves would freak out. But who else would?

by belorn 3y ago

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
      HTTPS is universally adopted. Meanwhile: the DNSSEC root keys could land on Pastebin tonight and nobody would need to be paged. The distinction is so clear that trying to pick apart the description seems disingenuous. I don't think you're experiencing me being evasive so much as that I simply don't accept your premises.
      - teddyh 3y ago
        > the DNSSEC root keys could land on Pastebin tonight and nobody would need to be paged. I disagree with this ludicrous assertion, but you are answering a different question, so I will not pursue this question at this time, in favor of the issue at hand: Upthread, you wrote that with “DNS providers managing DNSSEC”, “none of this counts as "adoption”. Why not? You also wrote that “providers managing and custodying keys for their customers […] is security theater”. How is this different from HTTPS keys? Why are HTTPS keys not “security theater”, but DNSSEC keys are?
        tptacek 3y ago
        I'm genuinely interested, because I've asked this question a bunch of times to a bunch of different audiences and never gotten an answer. So that thought experiment again: the DNSSEC root keys are fatally compromised. What are some specific entities that will require an immediate security response? Put differently: what specific entities depend today in any significant way on DNSSEC? Remember when you're thinking about this that most (virtually all, really) of the largest and/or most important organizations on the Internet don't use DNSSEC, so it wouldn't make any difference at all to them. And, in case this needs saying, it doesn't really count (in the spirit of this thought experiment) if the entity you think of is, like, a DNSSEC provider; stipulate, DNSSEC providers themselves would freak out. But who else would?