4 ms·

There is one case where I think DNSSEC provides a lot of value: domain validation for the purpose of issuing a TLS certificate. To get a DV certificate, the mo

by thayne 3y ago

There is one case where I think DNSSEC provides a lot of value: domain validation for the purpose of issuing a TLS certificate. To get a DV certificate, the most common kind, you just have to prove you own the domain. If someone can MitM the DNS request to verify domain ownership, then they can issue a certificate for your domain. Transperency logs help protect against this, as long as you are watching them, and notice the bad cert issued before too much damage is done. Granted, there isn't a big risk of MitM between the nameserver and the CA, hopefully with multiple locations. But a state actor might be able to do it. Still, I'm not sure that is worth the complexity of DNSSEC. Especially since you really only need signed records for specific records.

tptacek 3y ago
On-the-ball CAs are already doing multi-perspective lookups from multiple global POPs to reduce the theoretical potential for this attack (which is probably extraordinarily rare). By far the most common way people lose control of their domains (and their certificate identities) is by getting their registrar account phished.
- silisili 3y ago
  Are they doing full chain TCP lookups? Asking earnestly as I don't know. If they aren't, they absolutely should be.
- AndyMcConachie 3y ago
  You're probably correct in your assessment, but it does still happen. https://medium.com/s2wblog/post-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600#d138 https://medium.com/s2wblog/post-mortem-of-klayswap-incident-... https://petsymposium.org/2017/papers/hotpets/bgp-bogus-tls.pdf https://petsymposium.org/2017/papers/hotpets/bgp-bogus-tls.p...
  - tptacek 3y ago
    I think it's quite telling that the examples here all involve BGP subversion, which DNSSEC doesn't coherently mitigate: universal DNSSEC deployment would change the exploit you'd deploy to exploit BGP, but it wouldn't break the vulnerability.
    - nightpool 3y ago
      Out of curiosity—how does DNSSEC fail to address this specific vulnerability? Wouldn't it make it impossible to get an HTTPS/DNS record response for this zone, taking it from a "fail dangerous" MITM attack that could violate confidentiality to a simple "fail safe" DOS attack that only harms availability?
- tialaramex 3y ago
  > On-the-ball CAs are already doing multi-perspective lookups from multiple global POPs to reduce the theoretical potential for this attack (which is probably extraordinarily rare). It was certainly visible when a previous employer tasked me to go looking for it, in I'd guess 2018 or so. I have no details from that work because by convention I keep nothing, although by mistake I do still have a front door key to the office, which I really ought to get back to them one day. IIRC the main targets were military and government entities in less important (so not G7) countries. We were focused on email at the time, but these days perhaps you would target other infrastructure and the shape of the attacks would look different. Since "Governments of poor countries" isn't an attractive sales target for a startup I don't think that work progressed beyond my investigation. The Web PKI assumes the DNS is trustworthy, which in practice means DNSSEC or else just hoping. You are in team hope, and I think you ought to make that clear to people.
  - tptacek 3y ago
    It is simply not true that the WebPKI relies on the continuous global trustworthiness of the DNS. And a fact that you're not communicating to your audience here is that the ordinary way DNS is subverted to trick CAs is by phishing registrar accounts.
- jaas 3y ago
  You can read more about multi-perspective validation here: https://www.cs.princeton.edu/~jrex/papers/multiva20.pdf https://www.cs.princeton.edu/~jrex/papers/multiva20.pdf
AnthonyMouse 3y ago
State actors don't need to MitM the CA, they just order a CA they have leverage over to issue them a certificate.
- tptacek 3y ago
  ... which is then logged in CT logs.
  - AnthonyMouse 3y ago
    As it is if they MitM the CA.
  - chrismorgan 3y ago
    I’m not sure how CT logs actually work, but is it impossible for the CA to issue a certificate that is not entered into the CT logs? If it’s possible, then governments would surely just require that, and then it would only be caught by interception of the actual certificate being used.
    - Khoth 3y ago
      Browsers won't accept a certificate unless it comes with proof that it was submitted to a CT log. So a government could MITM you but they'd have to burn a CA to do it, whether you personally noticed the attack or not, so it's a very high cost attack
      - tialaramex 3y ago
        The proof is an SCT, a signed document from the Log which says "I promise I logged this pre-certificate". [[ In some cases it'll be the actual certificate, but for most real world TLS certificates it's a pre-certificate with the same substantive details, if you think about it you will see why the SCT baked inside your certificate cannot mention the actual document it is baked inside ]] Now, of course at the moment this document is created, there's no way to be sure this claim is true. The logs are a distributed system. Twenty four hours later, (the Maximum Merge Delay, this is a global policy decision) the log should, if you interrogate it, be able to show you a log entry matching the SCT, which traces to the agreed Merkle Tree head for that log. If it cannot, in principle that log has failed and must be distrusted. This happens (to one of the dozens of public logs, somewhere) a few times per year on average. In principle, everybody who sees the log could agree that they see the same Merkle Tree head, thus the certificate really is logged. In practice the mechanisms to ensure this works, a Gossip protocol, do not exist and have never been deployed in practical use. It's probably fine, but without ever completing the system as designed, it does have flaws.

by thayne 3y ago

tptacek 3y ago

On-the-ball CAs are already doing multi-perspective lookups from multiple global POPs to reduce the theoretical potential for this attack (which is probably extraordinarily rare). By far the most common way people lose control of their domains (and their certificate identities) is by getting their registrar account phished.

silisili 3y ago
Are they doing full chain TCP lookups? Asking earnestly as I don't know. If they aren't, they absolutely should be.
AndyMcConachie 3y ago
You're probably correct in your assessment, but it does still happen. https://medium.com/s2wblog/post-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600#d138 https://medium.com/s2wblog/post-mortem-of-klayswap-incident-... https://petsymposium.org/2017/papers/hotpets/bgp-bogus-tls.pdf https://petsymposium.org/2017/papers/hotpets/bgp-bogus-tls.p...
- tptacek 3y ago
  I think it's quite telling that the examples here all involve BGP subversion, which DNSSEC doesn't coherently mitigate: universal DNSSEC deployment would change the exploit you'd deploy to exploit BGP, but it wouldn't break the vulnerability.
  - nightpool 3y ago
    Out of curiosity—how does DNSSEC fail to address this specific vulnerability? Wouldn't it make it impossible to get an HTTPS/DNS record response for this zone, taking it from a "fail dangerous" MITM attack that could violate confidentiality to a simple "fail safe" DOS attack that only harms availability?
tialaramex 3y ago
> On-the-ball CAs are already doing multi-perspective lookups from multiple global POPs to reduce the theoretical potential for this attack (which is probably extraordinarily rare). It was certainly visible when a previous employer tasked me to go looking for it, in I'd guess 2018 or so. I have no details from that work because by convention I keep nothing, although by mistake I do still have a front door key to the office, which I really ought to get back to them one day. IIRC the main targets were military and government entities in less important (so not G7) countries. We were focused on email at the time, but these days perhaps you would target other infrastructure and the shape of the attacks would look different. Since "Governments of poor countries" isn't an attractive sales target for a startup I don't think that work progressed beyond my investigation. The Web PKI assumes the DNS is trustworthy, which in practice means DNSSEC or else just hoping. You are in team hope, and I think you ought to make that clear to people.
- tptacek 3y ago
  It is simply not true that the WebPKI relies on the continuous global trustworthiness of the DNS. And a fact that you're not communicating to your audience here is that the ordinary way DNS is subverted to trick CAs is by phishing registrar accounts.
jaas 3y ago
You can read more about multi-perspective validation here: https://www.cs.princeton.edu/~jrex/papers/multiva20.pdf https://www.cs.princeton.edu/~jrex/papers/multiva20.pdf

AnthonyMouse 3y ago

State actors don't need to MitM the CA, they just order a CA they have leverage over to issue them a certificate.

tptacek 3y ago
... which is then logged in CT logs.
- AnthonyMouse 3y ago
  As it is if they MitM the CA.
- chrismorgan 3y ago
  I’m not sure how CT logs actually work, but is it impossible for the CA to issue a certificate that is not entered into the CT logs? If it’s possible, then governments would surely just require that, and then it would only be caught by interception of the actual certificate being used.
  - Khoth 3y ago
    Browsers won't accept a certificate unless it comes with proof that it was submitted to a CT log. So a government could MITM you but they'd have to burn a CA to do it, whether you personally noticed the attack or not, so it's a very high cost attack
    - tialaramex 3y ago
      The proof is an SCT, a signed document from the Log which says "I promise I logged this pre-certificate". [[ In some cases it'll be the actual certificate, but for most real world TLS certificates it's a pre-certificate with the same substantive details, if you think about it you will see why the SCT baked inside your certificate cannot mention the actual document it is baked inside ]] Now, of course at the moment this document is created, there's no way to be sure this claim is true. The logs are a distributed system. Twenty four hours later, (the Maximum Merge Delay, this is a global policy decision) the log should, if you interrogate it, be able to show you a log entry matching the SCT, which traces to the agreed Merkle Tree head for that log. If it cannot, in principle that log has failed and must be distrusted. This happens (to one of the dozens of public logs, somewhere) a few times per year on average. In principle, everybody who sees the log could agree that they see the same Merkle Tree head, thus the certificate really is logged. In practice the mechanisms to ensure this works, a Gossip protocol, do not exist and have never been deployed in practical use. It's probably fine, but without ever completing the system as designed, it does have flaws.