Hi Ben, Thanks for catching that, adding the list back. My fault for dropping off-list.
On "nothing was ever actually on the public_name": for the clean deployment you describe, a dedicated public name with a cert scoped to just that name, I agree a leak costs ECH privacy rather than TLS content. But ECH privacy is the thing this mechanism exists to protect, and the exposure windows aren't comparable. A leaked cert key authenticates retries until the cert expires, typically 90 days, and revocation doesn't reliably reach TLS clients. A leaked signing key is only useful while configs carrying it in trusted_keys are still circulating, and the draft recommends not_after values measured in hours. The clean deployment is also rarer than it sounds. In practice the edge cert that's valid for the public name is often a shared or wildcard cert covering names that serve real traffic, so the key that can forge retries is the same key terminating real connections. And the deployments this draft is actually for can't get a public_name cert at all, so today they have no authenticated retry. The draft doesn't take a key away from your scenario, it makes your scenario possible without ever putting that key online. On durability, that's fair. Baseline retry is anchored in the WebPKI, so an operator who loses every key can re-issue a public_name cert and recover. ECHAuth is anchored in keys the operator pinned, so losing all of them, backups included, means no retry until clients refetch configs from DNS. Best, Nick On Wed, Jul 8, 2026 at 3:23 PM Ben Schwartz <[email protected]> wrote: > > We seem to be off-list. > > On Wed, Jul 8, 2026 at 4:01 AM Nick Sullivan > <[email protected]> wrote: > >> > The key this design > >> > removes from the fleet, one that can authenticate as the public name, > >> > breaks real TLS connections when it leaks. That's the trade, and we > >> > think it's the right one. > >> > >> If that key breaks "real" TLS connections, then it is still widely > >> distributed across the fleet, and is no less vulnerable than before. > > > > > > It isn’t on the fleet anymore, that’s the point. > > If it isn't on the fleet anymore, then nothing was ever actually "on" > the public_name. No TLS-protected content was being sent on > connections under this certificate. That means there were no "real > TLS connections" to this name, so the damage of a leak would have been > limited to ECH privacy, not TLS content privacy. > > In other words: if you can remove the public_name signing keys from > the fleet, then these keys were never any more dangerous than the ECH > decryption keys. > > >> > On Problem 2: "don't lose the decryption key" and "don't lose the auth > >> > key" aren't the same ask. > >> > >> I think they are. The operator is welcome to put a copy of the widely > >> distributed decryption key into cold storage or an HSM too, if that > >> helps their recovery playbook. (The interesting question there is > >> about forward secrecy.) > > > > > > That’s durability, not exposure, and exposure is the point. > > When I say "lose", I am talking about durability. public_name retry > can recover from a loss of all private keys. ECHAuth retry cannot. > > I don't think this is a very important scenario to support; I was just > trying to present a more complete comparison of the different > approaches. > > --Ben _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
