4 ms·

The next steps: 1. Add support for DNS-based persistent authentication: https://datatracker.ietf.org/doc/draft-ietf-acme-dns-persist/ https://datatracker.ietf.

by cyberax 11mo ago

The next steps: 1. Add support for DNS-based persistent authentication: https://datatracker.ietf.org/doc/draft-ietf-acme-dns-persist/ https://datatracker.ietf.org/doc/draft-ietf-acme-dns-persist... 2. Allow the user to just publish their public key into that TXT record. 3. Cut out the middleman and do the authentication directly in the browser. 4. DANE

tptacek 11mo ago
DANE isn't going to happen, and if you want to tilt at that windmill, it's Chrome and Mozilla you need to pressure, not LetsEncrypt.
- cyberax 11mo ago
  I mean, these are the steps that can bring it. And with Let's Encrypt as a safe fallback, it actually is feasible this time. Long shot? Yes. But not impossible.
  - tptacek 11mo ago
    The first step you'd need is a reliable way to deliver DNSSEC records to browsers, which does not currently exist. So I feel like you're missing at least a step 0, if not a step -1 (of getting ~anybody to actually sign zones.)
    - kbolino 11mo ago
      Aren't browsers generally implementing their own DNS resolution (via DoH) nowadays anyway? Not sure it helps that much, but operating systems not enforcing/delivering DNSSEC seems like a side-stepped problem now.
      - tptacek 11mo ago
        No, not as a general rule they aren't. And remember, the DNSSEC record delivery problem isn't an issue for the majority of all browser sessions, just a small minority that are on paths that won't pass DNSSEC records reliably. Since you can't just write those paths off, and you can't really reliably detect them, you end up needing a resolution fallback --- at which point you might as well not be using DANE. This was a big enough issue that there was a whole standards push to staple DNSSEC records to the TLS handshake (which then fell apart).
    - cyberax 11mo ago
      I sign my zones :) The reliable way is DoH/DoT that are rapidly going to become the standard. They don't suffer from fragmentation issues, so they can reliably get the DNSSEC chain. Or maybe the next step is putting the stapled response into the certificate. Perhaps it can even be used by Let's Encrypt as a part of the challenge, providing the incentive to get it right. The original stapled DNSSEC experiment was suffering from misaligned incentives. CAs didn't care at all about it.
      - tptacek 11mo ago
        Huh? What did CAs have to do with stapling?
        cyberax 11mo ago
        Stapling needs to be an intermediary step, in parallel with existing trusted CAs. When stapling was tried first in Chrome, no CAs were interested in setting up something like Let's Encrypt, using DNSSEC to automatically issue certificates.
        tptacek 11mo ago
        No it doesn't? Why would it? I'm confused by what it is you think CAs have to do with DNSSEC stapling. CAs are absolutely not the reason DANE staples failed.
        cyberax 11mo ago
        Staples failed because they couldn't work alone. They were considered a replacement for completely self-signed certificates. That's why the committee tried to mandate the stillborn pinning idea. The option to use stapling in addition to a CA-signed certificate was not really considered. After all, if you paid for a CA-signed cert then why would you bother with stapling?
        tptacek 11mo ago
  - ekr____ 11mo ago
    What's the incentive for individual sites or browsers to do this? From the site's perspective, they're going to need to have a WebPKI certificate for the foreseeable future, basically until there is no appreciable population of WebPKI-only clients, which is years in the future. So DANE is strictly more work. From the browser's perspective, very few sites actually support DANE, and the current situation is satisfactory, so why go to any additional effort? In order for technologies to get wide deployment, they usually need to be valuable to individual ecosystem actors at the margin, i.e., they have to get value by deploying them today. Even stipulating that an eventual DANE-only system is better, it doesn't provide any benefit in the near term, so it's very hard to get deployment.
    - tptacek 11mo ago
      A fun note: I vibecoded a dumb thingy that monitors the top 1000 zones on the Tranco research list of popular zones for DNSSEC status: https://dnssecmenot.fly.dev/ https://dnssecmenot.fly.dev/ Obviously, the headline is that just 2% of the top 100 zones are signed (thanks to Cloudflare). But the funnier thing is: in 5+ months of letting this thing run, it's picked up just three changes to DNSSEC status among all the zones it monitors. The third happened just an hour or so ago, when Canva disabled DNSSEC.
    - crote 11mo ago
      DANE could've worked as an alternative to LetsEncrypt, if all CAs had refused to cross-sign it and essentially killed it for years until everyone's cert stores had caught up.
zeagle 11mo ago
For someone who runs a small personal website and uses LE to secure this + some web exposed services, could you explain how this is different/better than acme-dns-certbot?
- cyberax 11mo ago
  Let's Encrypt is a single point of failure. WebPKI also suffers from an inability to properly do delegation. It's not possible for me to create an intermediary certificate valid only for *.mycompany.com If I want to use WebPKI, I have to either expose every host inside my company to everyone (via CT transparency logs) or use a wildcard certificate. And wildcard certs allow attackers to impersonate anything within my domain, if they get access to just one host. X.509 technically supports name constraints ( https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10 https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10 ), but its implementation was inconsistent. In particular, some implementations did not apply it to the Common Name. Fortunately, Common Name is on the path to deprecation.
  - crote 11mo ago
    CT logs do allow enumeration, but avoiding that is just security through obscurity. WebPKI is intended for publicly-accessible hosts, so hopefully you already have some kind of firewall in place to protect them! If you want to avoid enumeration of internal-only hosts: just use your own self-signed root cert. CT logs are a crucial part of protecting against rogue CAs, so don't expect that to go away any time soon. With ACME most of the delegation issues have pretty much been solved. Publicly-accessible hosts can easily get a cert - if and only if the domain resolves to that host. Want even stricter enforcement? Nobody's stopping you from writing an ACME proxy which only forwards requests from known-good hosts to LE & friends.
    - cyberax 11mo ago
      > CT logs do allow enumeration, but avoiding that is just security through obscurity. Well, yes. There are also other issues, like rate limits. Some companies have hundreds of thousands of hosts (some virtual) and requesting certificates for all of them might be problematic. > If you want to avoid enumeration of internal-only hosts: just use your own self-signed root cert. This becomes increasingly problematic, as browsers start relying on DoH/DoT, or making it more difficult to enroll custom root certs. > Nobody's stopping you from writing an ACME proxy which only forwards requests from known-good hosts to LE & friends. I actually tried that. LE uses multiple viewpoints to resolve the challenges, so you need to open your internal DNS resolvers/HTTPS to basically all the world. Or play with the horror of split-horizon DNS.

by cyberax 11mo ago

tptacek 11mo ago

DANE isn't going to happen, and if you want to tilt at that windmill, it's Chrome and Mozilla you need to pressure, not LetsEncrypt.

cyberax 11mo ago
I mean, these are the steps that can bring it. And with Let's Encrypt as a safe fallback, it actually is feasible this time. Long shot? Yes. But not impossible.
- tptacek 11mo ago
  The first step you'd need is a reliable way to deliver DNSSEC records to browsers, which does not currently exist. So I feel like you're missing at least a step 0, if not a step -1 (of getting ~anybody to actually sign zones.)
  - kbolino 11mo ago
    Aren't browsers generally implementing their own DNS resolution (via DoH) nowadays anyway? Not sure it helps that much, but operating systems not enforcing/delivering DNSSEC seems like a side-stepped problem now.
    - tptacek 11mo ago
      No, not as a general rule they aren't. And remember, the DNSSEC record delivery problem isn't an issue for the majority of all browser sessions, just a small minority that are on paths that won't pass DNSSEC records reliably. Since you can't just write those paths off, and you can't really reliably detect them, you end up needing a resolution fallback --- at which point you might as well not be using DANE. This was a big enough issue that there was a whole standards push to staple DNSSEC records to the TLS handshake (which then fell apart).
  - cyberax 11mo ago
    I sign my zones :) The reliable way is DoH/DoT that are rapidly going to become the standard. They don't suffer from fragmentation issues, so they can reliably get the DNSSEC chain. Or maybe the next step is putting the stapled response into the certificate. Perhaps it can even be used by Let's Encrypt as a part of the challenge, providing the incentive to get it right. The original stapled DNSSEC experiment was suffering from misaligned incentives. CAs didn't care at all about it.
    - tptacek 11mo ago
      Huh? What did CAs have to do with stapling?
      - cyberax 11mo ago
        Stapling needs to be an intermediary step, in parallel with existing trusted CAs. When stapling was tried first in Chrome, no CAs were interested in setting up something like Let's Encrypt, using DNSSEC to automatically issue certificates.
        tptacek 11mo ago
        No it doesn't? Why would it? I'm confused by what it is you think CAs have to do with DNSSEC stapling. CAs are absolutely not the reason DANE staples failed.
        cyberax 11mo ago
        Staples failed because they couldn't work alone. They were considered a replacement for completely self-signed certificates. That's why the committee tried to mandate the stillborn pinning idea. The option to use stapling in addition to a CA-signed certificate was not really considered. After all, if you paid for a CA-signed cert then why would you bother with stapling?
        tptacek 11mo ago
- ekr____ 11mo ago
  What's the incentive for individual sites or browsers to do this? From the site's perspective, they're going to need to have a WebPKI certificate for the foreseeable future, basically until there is no appreciable population of WebPKI-only clients, which is years in the future. So DANE is strictly more work. From the browser's perspective, very few sites actually support DANE, and the current situation is satisfactory, so why go to any additional effort? In order for technologies to get wide deployment, they usually need to be valuable to individual ecosystem actors at the margin, i.e., they have to get value by deploying them today. Even stipulating that an eventual DANE-only system is better, it doesn't provide any benefit in the near term, so it's very hard to get deployment.
  - tptacek 11mo ago
    A fun note: I vibecoded a dumb thingy that monitors the top 1000 zones on the Tranco research list of popular zones for DNSSEC status: https://dnssecmenot.fly.dev/ https://dnssecmenot.fly.dev/ Obviously, the headline is that just 2% of the top 100 zones are signed (thanks to Cloudflare). But the funnier thing is: in 5+ months of letting this thing run, it's picked up just three changes to DNSSEC status among all the zones it monitors. The third happened just an hour or so ago, when Canva disabled DNSSEC.
  - crote 11mo ago
    DANE could've worked as an alternative to LetsEncrypt, if all CAs had refused to cross-sign it and essentially killed it for years until everyone's cert stores had caught up.

zeagle 11mo ago

For someone who runs a small personal website and uses LE to secure this + some web exposed services, could you explain how this is different/better than acme-dns-certbot?

cyberax 11mo ago
Let's Encrypt is a single point of failure. WebPKI also suffers from an inability to properly do delegation. It's not possible for me to create an intermediary certificate valid only for *.mycompany.com If I want to use WebPKI, I have to either expose every host inside my company to everyone (via CT transparency logs) or use a wildcard certificate. And wildcard certs allow attackers to impersonate anything within my domain, if they get access to just one host. X.509 technically supports name constraints ( https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10 https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10 ), but its implementation was inconsistent. In particular, some implementations did not apply it to the Common Name. Fortunately, Common Name is on the path to deprecation.
- crote 11mo ago
  CT logs do allow enumeration, but avoiding that is just security through obscurity. WebPKI is intended for publicly-accessible hosts, so hopefully you already have some kind of firewall in place to protect them! If you want to avoid enumeration of internal-only hosts: just use your own self-signed root cert. CT logs are a crucial part of protecting against rogue CAs, so don't expect that to go away any time soon. With ACME most of the delegation issues have pretty much been solved. Publicly-accessible hosts can easily get a cert - if and only if the domain resolves to that host. Want even stricter enforcement? Nobody's stopping you from writing an ACME proxy which only forwards requests from known-good hosts to LE & friends.
  - cyberax 11mo ago
    > CT logs do allow enumeration, but avoiding that is just security through obscurity. Well, yes. There are also other issues, like rate limits. Some companies have hundreds of thousands of hosts (some virtual) and requesting certificates for all of them might be problematic. > If you want to avoid enumeration of internal-only hosts: just use your own self-signed root cert. This becomes increasingly problematic, as browsers start relying on DoH/DoT, or making it more difficult to enroll custom root certs. > Nobody's stopping you from writing an ACME proxy which only forwards requests from known-good hosts to LE & friends. I actually tried that. LE uses multiple viewpoints to resolve the challenges, so you need to open your internal DNS resolvers/HTTPS to basically all the world. Or play with the horror of split-horizon DNS.