10 ms·

Yeah, ok, but then you need to ask if DANE achieves that. And the answer to that is clearly "no". DANE never made it past an experimental browser plugin, and a

by hannob 3y ago

Yeah, ok, but then you need to ask if DANE achieves that. And the answer to that is clearly "no". DANE never made it past an experimental browser plugin, and as far as I know that isn't even developed any more. In the time where DANE achieved nothing, we got Let's Encrypt, we got CT, and a whole bunch of other improvements to the WebPKI.

cyberax 3y ago
DANE technically achieved that, I played around with OpenSSL plugin for DANE back in 2010 (when the . was signed). But yeah, I get your point. Right now, the path ahead is stapled DANE TLS extension. Basically, the idea is that you can use simple unauthenticated DNS to get the domain name, just like now. Then you get the complete DNSSEC-authenticated DNS chain for the DANE record as a part of the TLS handshake: https://datatracker.ietf.org/doc/rfc9102/ https://datatracker.ietf.org/doc/rfc9102/ This seems to be the best of both worlds: 1. We keep DNS as a simple and nimble UDP-based service, without trying to cram the signature in each packet. 2. Since we HAVE to use TLS anyway to achieve any meaningful security, we can just transmit the full DNS chain (up to the root zone!) with signatures easily as a part of the TLS handshake. 3. The client then just needs to validate this chain, and it only needs to have the root zone's key as the root of trust. 4. The root zone's key changes fairly infrequently (once in a decade), so IoT devices can use it to bootstrap themselves.
- AndyMcConachie 3y ago
  > 4. The root zone's key changes fairly infrequently (once in a decade), so IoT devices can use it to bootstrap themselves. This is not true, nor will it be true into the future.
  - cyberax 3y ago
    The last root zone KSK rotation was in 2018. I believe the next one is scheduled to start in 2025 and will take 3 years?
- hannob 3y ago
  > DANE technically achieved that What exactly did DANE achieve? Replacing CAs? I must've missed something, last time I checked every webpage on the planet was still using CA-signed certificates. > Right now, the path ahead is stapled DANE TLS extension. This thing I find really funny. It basically boils down to "we secured DNS. ok, we figured out it doesn't really work. Ok, how about let's stuff our DNS security system into TLS, because over DNS it does not work? Then we have secure DNS!" Though I've heard this idea many years ago, and it appears deployment is nonexistent, so... probably not gonna happen either.
  - cyberax 3y ago
    > What exactly did DANE achieve? Replacing CAs? The RFC provided a standard, but people choose to ignore it. > This thing I find really funny. It basically boils down to "we secured DNS. ok, we figured out it doesn't really work. Ok, how about let's stuff our DNS security system into TLS, because over DNS it does not work? Then we have secure DNS!" Not quite. DNSSEC secured DNS, but it turns out that this by itself is not important in the today's world. However, we do have a very fragile situation where half the Internet now depends on the goodwill and competency of just one organization for their security (I'm talking about Let's Encrypt). > Though I've heard this idea many years ago, and it appears deployment is nonexistent, so... probably not gonna happen either. TLS extension is a fairly new idea, and it only now is starting to get some traction.
    - tptacek 3y ago
      This is the second time on this thread you've claimed that a DANE stapling extension is in the works. But it's not: it was proposed and shot down, years ago.
      - cyberax 3y ago
        That's factually untrue. RFC 9102 was published two years ago in order to gather experimental data: https://datatracker.ietf.org/doc/rfc9102/ https://datatracker.ietf.org/doc/rfc9102/ The relevant RFC for DANE is still active, and it hasn't been obsoleted ("shot down"). The major vulnerability of DANE is MITM attacker's ability to "downgrade" attacks into regular PKI in mixed PKI+DANE deployments. So DANE is at worst no better than PKI. The other problem is the lack of something like certificate transparency for DNS updates and the inability to quickly invalidate erroneous records in caching resolvers, and the general complexity of DNSSEC setup. People (mostly within the RIPE DNS WG) are working on mitigating that: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-automation/ https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-aut... or https://blog.apnic.net/2021/11/02/dnssec-provisioning-automation-with-cds-cdnskey-in-the-real-world/ https://blog.apnic.net/2021/11/02/dnssec-provisioning-automa... Edit: Geoff Houston's basically says that _browsers_ bailed on the stapled DANE TLS extension, which is quite true. It doesn't mean that the work on DANE and DNSSEC has stopped. Yes, it's taking time, but it's still ongoing. As for CT, we don't need _everyone_ to adopt it. Just the most relevant TLDs would be enough. And there is work going on adding something like it for DANE. It's also slow, because there's a desire to obscure the DNS names from the CT logs (current CT logs expose ALL the DNS names, allowing to easily map the internal infrastructure of any company depending on PKI).
- tptacek 3y ago
  The stapling extension for TLS is a dead letter. Work on it was abandoned a couple years ago, when it finally occurred to the working group that control of a CA would allow you to strip the stapled DANE proof off the handshake, which defeats the entire purpose of the extension. DANE advocates counterproposed a pinning mechanism and got laughed out of the discussion by the browsers, for whom "pinning" is a cursed word.
  - cyberax 3y ago
    How would that work if you only trust DANE? And if you have a control over a CA, then you can just issue yourself a certificate for any host anyway, so it's a moot point.
    - tptacek 3y ago
      https://blog.apnic.net/2021/08/31/tls-with-dane/ https://blog.apnic.net/2021/08/31/tls-with-dane/
      - cyberax 3y ago
        Uhm. It doesn't contradict anything I said. If you MITM the session and strip the DANE data, then you'll be left with no trust anchors. You can do the same with the regular CA-based trust chain.

by hannob 3y ago

cyberax 3y ago

DANE technically achieved that, I played around with OpenSSL plugin for DANE back in 2010 (when the . was signed). But yeah, I get your point. Right now, the path ahead is stapled DANE TLS extension. Basically, the idea is that you can use simple unauthenticated DNS to get the domain name, just like now. Then you get the complete DNSSEC-authenticated DNS chain for the DANE record as a part of the TLS handshake: https://datatracker.ietf.org/doc/rfc9102/ https://datatracker.ietf.org/doc/rfc9102/ This seems to be the best of both worlds: 1. We keep DNS as a simple and nimble UDP-based service, without trying to cram the signature in each packet. 2. Since we HAVE to use TLS anyway to achieve any meaningful security, we can just transmit the full DNS chain (up to the root zone!) with signatures easily as a part of the TLS handshake. 3. The client then just needs to validate this chain, and it only needs to have the root zone's key as the root of trust. 4. The root zone's key changes fairly infrequently (once in a decade), so IoT devices can use it to bootstrap themselves.

AndyMcConachie 3y ago
> 4. The root zone's key changes fairly infrequently (once in a decade), so IoT devices can use it to bootstrap themselves. This is not true, nor will it be true into the future.
- cyberax 3y ago
  The last root zone KSK rotation was in 2018. I believe the next one is scheduled to start in 2025 and will take 3 years?
hannob 3y ago
> DANE technically achieved that What exactly did DANE achieve? Replacing CAs? I must've missed something, last time I checked every webpage on the planet was still using CA-signed certificates. > Right now, the path ahead is stapled DANE TLS extension. This thing I find really funny. It basically boils down to "we secured DNS. ok, we figured out it doesn't really work. Ok, how about let's stuff our DNS security system into TLS, because over DNS it does not work? Then we have secure DNS!" Though I've heard this idea many years ago, and it appears deployment is nonexistent, so... probably not gonna happen either.
- cyberax 3y ago
  > What exactly did DANE achieve? Replacing CAs? The RFC provided a standard, but people choose to ignore it. > This thing I find really funny. It basically boils down to "we secured DNS. ok, we figured out it doesn't really work. Ok, how about let's stuff our DNS security system into TLS, because over DNS it does not work? Then we have secure DNS!" Not quite. DNSSEC secured DNS, but it turns out that this by itself is not important in the today's world. However, we do have a very fragile situation where half the Internet now depends on the goodwill and competency of just one organization for their security (I'm talking about Let's Encrypt). > Though I've heard this idea many years ago, and it appears deployment is nonexistent, so... probably not gonna happen either. TLS extension is a fairly new idea, and it only now is starting to get some traction.
  - tptacek 3y ago
    This is the second time on this thread you've claimed that a DANE stapling extension is in the works. But it's not: it was proposed and shot down, years ago.
    - cyberax 3y ago
      That's factually untrue. RFC 9102 was published two years ago in order to gather experimental data: https://datatracker.ietf.org/doc/rfc9102/ https://datatracker.ietf.org/doc/rfc9102/ The relevant RFC for DANE is still active, and it hasn't been obsoleted ("shot down"). The major vulnerability of DANE is MITM attacker's ability to "downgrade" attacks into regular PKI in mixed PKI+DANE deployments. So DANE is at worst no better than PKI. The other problem is the lack of something like certificate transparency for DNS updates and the inability to quickly invalidate erroneous records in caching resolvers, and the general complexity of DNSSEC setup. People (mostly within the RIPE DNS WG) are working on mitigating that: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-automation/ https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-aut... or https://blog.apnic.net/2021/11/02/dnssec-provisioning-automation-with-cds-cdnskey-in-the-real-world/ https://blog.apnic.net/2021/11/02/dnssec-provisioning-automa... Edit: Geoff Houston's basically says that _browsers_ bailed on the stapled DANE TLS extension, which is quite true. It doesn't mean that the work on DANE and DNSSEC has stopped. Yes, it's taking time, but it's still ongoing. As for CT, we don't need _everyone_ to adopt it. Just the most relevant TLDs would be enough. And there is work going on adding something like it for DANE. It's also slow, because there's a desire to obscure the DNS names from the CT logs (current CT logs expose ALL the DNS names, allowing to easily map the internal infrastructure of any company depending on PKI).
tptacek 3y ago
The stapling extension for TLS is a dead letter. Work on it was abandoned a couple years ago, when it finally occurred to the working group that control of a CA would allow you to strip the stapled DANE proof off the handshake, which defeats the entire purpose of the extension. DANE advocates counterproposed a pinning mechanism and got laughed out of the discussion by the browsers, for whom "pinning" is a cursed word.
- cyberax 3y ago
  How would that work if you only trust DANE? And if you have a control over a CA, then you can just issue yourself a certificate for any host anyway, so it's a moot point.
  - tptacek 3y ago
    https://blog.apnic.net/2021/08/31/tls-with-dane/ https://blog.apnic.net/2021/08/31/tls-with-dane/
    - cyberax 3y ago
      Uhm. It doesn't contradict anything I said. If you MITM the session and strip the DANE data, then you'll be left with no trust anchors. You can do the same with the regular CA-based trust chain.