6 ms·

We need certificate transparency logs for DNSSEC (for ICANN and TLDs at least).

by remram 5y ago

tptacek 5y ago
Two big problems with CT for DNSSEC: 1. It doesn't exist right now. 2. Getting CT working for the WebPKI was a lot of work, done in tandem by a lot of very talented people, and because virtually nobody in the industry uses DNSSEC (go look!), there's no incentive for that work to happen. There's no question that the IETF could get a working group together to specify a transparency log for DNSSEC... eventually. I'd happily start a pool to bet on how long it would take them to bikeshed it out. But actually getting it deployed to the level of effectiveness that CT has today is a totally different story. It has been over twenty years of work just getting DNSSEC to the (very bad) place it's at today. We should factor that in when we talk about what DNSSEC can and can't do. A think DNSSEC can't do today: provide transparency logs, like the WebPKI does.
- Operyl 5y ago
  Not arguing either which way, but was curious and did a few names off the top of my head: yes: Cloudflare no: easyDNS, Google, Apple, Facebook, Wikipedia/media, Twitter, Reddit I knew DNSSEC wasn't well-deployed, but I didn't realize how little.
  - tptacek 5y ago
    Keep going! It gets funnier as you keep looking. (For those playing the home game, it's just `host -t ds <domain>` to check for DNSSEC; `host -t ds salesforce.com` is what it looks like when you do have DNSSEC enabled.) To save some trouble: other companies that haven't enabled DNSSEC include Mozilla, Netflix, Stripe, Bank of America, Citigroup, Microsoft, Adobe, Oracle, Amazon, Intel, IBM, Atlassian, Coinbase, Equinix, Datadog, Twilio, Ebay, and Shopify. Speaking of Salesforce: the chatter is that the real reason Slack enabled DNSSEC briefly is because Salesforce --- their parent company --- already had it enabled, presumably for the same bogus FedRAMP reason. Cloudflare is probably the most notable DNSSEC user. But then: Cloudflare sells DNSSEC services.
    - tzs 5y ago
      Some more without: mit.edu, harvard.edu, ucla.edu, usc.edu Some more with: berkeley.edu, stanford.edu, caltech.edu (Dammit...now I'm curious about what is actually in those records, because the 'host -t ds' output for all of them is 3 apparently decimal numbers, a long hex string, and a short hex strings except for Caltech's, which is missing the final short hex string).
      - defanor 5y ago
        > (Dammit...no I'm curious about what is actually in those records, because the 'host -t ds' output for all of them is 3 apparently decimal numbers, a long hex string, and a short hex strings except for Caltech's, which is missing the final short hex string). Those are DS records, what host(1) prints is their presentation format [1]: > The presentation format of the DS record consists of three numbers (key tag, algorithm, and digest type) followed by the digest itself presented in hex Digest type 1 (as for caltech.edu) is for SHA-1 [2], type 2 (as for stanford.edu) is for SHA-256 [3]. So caltech.edu just uses a shorter hash, and whitespace is allowed in the presentation [4]. FWIW, one can also check and verify that/whether DNSSEC works with delv(1) (similar to dig(1), but with validation). [1] https://datatracker.ietf.org/doc/html/rfc3658#section-2.5 https://datatracker.ietf.org/doc/html/rfc3658#section-2.5 [2] https://datatracker.ietf.org/doc/html/rfc3658#section-5 https://datatracker.ietf.org/doc/html/rfc3658#section-5 [3] https://datatracker.ietf.org/doc/html/rfc4509#section-2.1 https://datatracker.ietf.org/doc/html/rfc4509#section-2.1 [4] https://datatracker.ietf.org/doc/html/rfc4034#section-5.3 https://datatracker.ietf.org/doc/html/rfc4034#section-5.3
- dane-pgp 5y ago
  I think you're entitled to also specifically add to your list: 3. The lack of a standardised DELEGATION_ONLY flag. work on which was being pursued in the IETF[0] (and included a little shout out to you[1]) but sadly seems to have stagnated. [0] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-delegation-only-02 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-deleg... [1] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-delegation-only-02#section-13 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-deleg...
  - tptacek 5y ago
    Oh, my god. That's so cute. Thanks for pointing that out to me, I had no idea.
- cryptonector 5y ago
  3. CT doesn't work if domain owners don't watch it.
  - tialaramex 5y ago
    Nah. That's probably relevant for what Thomas imagines doing, but in reality what CT does is provide independent researchers with an easy way to see anomalies. I've done this a few times, academics have done it here and there, and when there are incidents everybody involved will be staring at crt.sh these days. There was a recent m.d.s.policy policy change idea about requiring CAs to publish the SHA256s of problem certificates, perhaps as crt.sh links because again, in practice people are going to look at them on crt.sh (but SHA256 because one day crt.sh will go away and it'd be a shame to have opaque database row numbers instead of SHA256) For example, suppose I find a certificate with a 1024-bit RSA public key issued last Thursday by a particular CA. Before CT if I told m.d.s.policy, you can be 100% sure the CA would say "Oops. But that's the only one, we know what happened and we've definitely fixed it". But with CT, they won't even bother with that lie, because they know a researcher is already running a crt.sh database query to find the others they probably issued. They're going to need to actually find and fix the problem. Ugh. Work. This was a much bigger problem for the Web PKI than it is for DNS today, which is why CT was built. Why? Because of "private" systems. For DNS, we're used to not worrying about private systems at all. You probably have or know somebody who has, a Pi-Hole, which deliberately trashes DNS in order to reduce the amount of advertising you see. It can't trash my DNS this way, and it couldn't trash DNS for somebody using say, Google's DoH servers (but when pointed out this actually makes HN readers angry!) so we don't fret about it. But for the Web PKI "private" systems are a big problem. We don't want a CA selling you a certificate for *.ad-network.example so that you can block their ads "just on your private network". Because we don't trust that it'll stay on your network. Years ago we had a problem where some end users believed "int" was a TLD for internal use, and much worse some CAs believed them. It isn't so of course the certificates for testwww4.int and windows2000dev.int are a big problem even though the people who had them never intended to set up a server claiming to be "testwww4.int" on the public Internet
    - ignoramous 5y ago
- ignoramous 5y ago
  > There's no question that the IETF could get a working group together to specify a transparency log for DNSSEC... eventually. I'd happily start a pool to bet on how long it would take them to bikeshed it out. Don't tempt the IETF... The ADD group has been working on service bindings for DNS to signal the supported set of secure transports for a DNS server. The DNS Privacy Working Group is working on this topic. And now there is DANCE, attempting to apply DANE for network client authentication. And there’s DNSOP of course. One should never underestimate the potential for the IETF to solve the same problem thirty times in thirty different ways. Just think 'IPv6 Transition Mechanisms' to understand just how well the IETF can explore and standardize every possible option, to the inevitable confusion of all! https://blog.apnic.net/2021/11/18/dns-at-ietf-112/ https://blog.apnic.net/2021/11/18/dns-at-ietf-112/

We need certificate transparency logs for DNSSEC (for ICANN and TLDs at least).

by remram 5y ago

We need certificate transparency logs for DNSSEC (for ICANN and TLDs at least).

Two big problems with CT for DNSSEC: 1. It doesn't exist right now. 2. Getting CT working for the WebPKI was a lot of work, done in tandem by a lot of very talented people, and because virtually nobody in the industry uses DNSSEC (go look!), there's no incentive for that work to happen. There's no question that the IETF could get a working group together to specify a transparency log for DNSSEC... eventually. I'd happily start a pool to bet on how long it would take them to bikeshed it out. But actually getting it deployed to the level of effectiveness that CT has today is a totally different story. It has been over twenty years of work just getting DNSSEC to the (very bad) place it's at today. We should factor that in when we talk about what DNSSEC can and can't do. A think DNSSEC can't do today: provide transparency logs, like the WebPKI does.

Operyl 5y ago
Not arguing either which way, but was curious and did a few names off the top of my head: yes: Cloudflare no: easyDNS, Google, Apple, Facebook, Wikipedia/media, Twitter, Reddit I knew DNSSEC wasn't well-deployed, but I didn't realize how little.
- tptacek 5y ago
  Keep going! It gets funnier as you keep looking. (For those playing the home game, it's just `host -t ds <domain>` to check for DNSSEC; `host -t ds salesforce.com` is what it looks like when you do have DNSSEC enabled.) To save some trouble: other companies that haven't enabled DNSSEC include Mozilla, Netflix, Stripe, Bank of America, Citigroup, Microsoft, Adobe, Oracle, Amazon, Intel, IBM, Atlassian, Coinbase, Equinix, Datadog, Twilio, Ebay, and Shopify. Speaking of Salesforce: the chatter is that the real reason Slack enabled DNSSEC briefly is because Salesforce --- their parent company --- already had it enabled, presumably for the same bogus FedRAMP reason. Cloudflare is probably the most notable DNSSEC user. But then: Cloudflare sells DNSSEC services.
  - tzs 5y ago
    Some more without: mit.edu, harvard.edu, ucla.edu, usc.edu Some more with: berkeley.edu, stanford.edu, caltech.edu (Dammit...now I'm curious about what is actually in those records, because the 'host -t ds' output for all of them is 3 apparently decimal numbers, a long hex string, and a short hex strings except for Caltech's, which is missing the final short hex string).
    - defanor 5y ago
      > (Dammit...no I'm curious about what is actually in those records, because the 'host -t ds' output for all of them is 3 apparently decimal numbers, a long hex string, and a short hex strings except for Caltech's, which is missing the final short hex string). Those are DS records, what host(1) prints is their presentation format [1]: > The presentation format of the DS record consists of three numbers (key tag, algorithm, and digest type) followed by the digest itself presented in hex Digest type 1 (as for caltech.edu) is for SHA-1 [2], type 2 (as for stanford.edu) is for SHA-256 [3]. So caltech.edu just uses a shorter hash, and whitespace is allowed in the presentation [4]. FWIW, one can also check and verify that/whether DNSSEC works with delv(1) (similar to dig(1), but with validation). [1] https://datatracker.ietf.org/doc/html/rfc3658#section-2.5 https://datatracker.ietf.org/doc/html/rfc3658#section-2.5 [2] https://datatracker.ietf.org/doc/html/rfc3658#section-5 https://datatracker.ietf.org/doc/html/rfc3658#section-5 [3] https://datatracker.ietf.org/doc/html/rfc4509#section-2.1 https://datatracker.ietf.org/doc/html/rfc4509#section-2.1 [4] https://datatracker.ietf.org/doc/html/rfc4034#section-5.3 https://datatracker.ietf.org/doc/html/rfc4034#section-5.3
dane-pgp 5y ago
I think you're entitled to also specifically add to your list: 3. The lack of a standardised DELEGATION_ONLY flag. work on which was being pursued in the IETF[0] (and included a little shout out to you[1]) but sadly seems to have stagnated. [0] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-delegation-only-02 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-deleg... [1] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-delegation-only-02#section-13 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-deleg...
- tptacek 5y ago
  Oh, my god. That's so cute. Thanks for pointing that out to me, I had no idea.
cryptonector 5y ago
3. CT doesn't work if domain owners don't watch it.
- tialaramex 5y ago
  Nah. That's probably relevant for what Thomas imagines doing, but in reality what CT does is provide independent researchers with an easy way to see anomalies. I've done this a few times, academics have done it here and there, and when there are incidents everybody involved will be staring at crt.sh these days. There was a recent m.d.s.policy policy change idea about requiring CAs to publish the SHA256s of problem certificates, perhaps as crt.sh links because again, in practice people are going to look at them on crt.sh (but SHA256 because one day crt.sh will go away and it'd be a shame to have opaque database row numbers instead of SHA256) For example, suppose I find a certificate with a 1024-bit RSA public key issued last Thursday by a particular CA. Before CT if I told m.d.s.policy, you can be 100% sure the CA would say "Oops. But that's the only one, we know what happened and we've definitely fixed it". But with CT, they won't even bother with that lie, because they know a researcher is already running a crt.sh database query to find the others they probably issued. They're going to need to actually find and fix the problem. Ugh. Work. This was a much bigger problem for the Web PKI than it is for DNS today, which is why CT was built. Why? Because of "private" systems. For DNS, we're used to not worrying about private systems at all. You probably have or know somebody who has, a Pi-Hole, which deliberately trashes DNS in order to reduce the amount of advertising you see. It can't trash my DNS this way, and it couldn't trash DNS for somebody using say, Google's DoH servers (but when pointed out this actually makes HN readers angry!) so we don't fret about it. But for the Web PKI "private" systems are a big problem. We don't want a CA selling you a certificate for *.ad-network.example so that you can block their ads "just on your private network". Because we don't trust that it'll stay on your network. Years ago we had a problem where some end users believed "int" was a TLD for internal use, and much worse some CAs believed them. It isn't so of course the certificates for testwww4.int and windows2000dev.int are a big problem even though the people who had them never intended to set up a server claiming to be "testwww4.int" on the public Internet
  - ignoramous 5y ago
ignoramous 5y ago
> There's no question that the IETF could get a working group together to specify a transparency log for DNSSEC... eventually. I'd happily start a pool to bet on how long it would take them to bikeshed it out. Don't tempt the IETF... The ADD group has been working on service bindings for DNS to signal the supported set of secure transports for a DNS server. The DNS Privacy Working Group is working on this topic. And now there is DANCE, attempting to apply DANE for network client authentication. And there’s DNSOP of course. One should never underestimate the potential for the IETF to solve the same problem thirty times in thirty different ways. Just think 'IPv6 Transition Mechanisms' to understand just how well the IETF can explore and standardize every possible option, to the inevitable confusion of all! https://blog.apnic.net/2021/11/18/dns-at-ietf-112/ https://blog.apnic.net/2021/11/18/dns-at-ietf-112/