← Back to context

Comment by cyberax

10 hours ago

The next steps:

1. Add support for DNS-based persistent authentication: 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

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?

  • 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 ), 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.

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.

  • 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.

    • 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.

      1 reply →

    • 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.)

      3 replies →