cyberaxDec 10

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

Automated Certificate Management Environment (ACME) Challenge for Persistent DNS TXT Record Validation

This document specifies "dns-persist-01", a new validation method for the Automated Certificate Management Environment (ACME) protocol. This method allows a Certification Authority (CA) to verify control over a domain by confirming the presence of a persistent DNS TXT record containing CA and account identification information. This method is particularly suited for environments where traditional challenge methods are impractical, such as IoT deployments, multi- tenant platforms, and scenarios requiring batch certificate operations. The validation method is designed with a strong focus on security and robustness, incorporating widely adopted industry best practices for persistent domain control validation. This design aims to make it suitable for Certification Authorities operating under various policy environments, including those that align with the CA/ Browser Forum Baseline Requirements.

IETF Datatracker
Show threadtptacekDec 10
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.
Show threadcyberaxDec 10

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.

Show threadtptacekDec 10
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.)
Show threadcyberaxDec 10

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.

Show threadtptacek
Huh? What did CAs have to do with stapling?
Dec 10 at 3:21pmWeb
Show threadcyberaxDec 11
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.
Show threadtptacekDec 11
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.
Show threadcyberaxDec 12

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?

Show threadtptacekDec 12
Whatever thing you're talking about, it does not appear to be DANE stapling.