On Tue, Jul 7, 2026 at 3:31 PM 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. > 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.) > And > since HPKE has no forward secrecy for the ClientHelloInner, > compromising one of those servers doesn't just expose future > connections, it retroactively exposes the inner SNI of every recorded > ClientHello across the whole window. True! That does make this strategy less appealing. --Ben _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
