I'm also not quite your target, as I think publishing both is fine, but the two are not at all comparable in the first place.
SSLKEYLOGFILE is a purely-local debugging mechanism which, by design, reveals connection secrets to (one hopes) a party that is locally trusted to see the connection for (presumably) diagnostic purposes. The considerations there are around these questions whether the local user of this purely-local mechanism is actually able to adequately evaluate their application-local security goals and use this correctly, because using it wrong breaks all security. They're also local to one end of the connection, where as TLS really only concerns itself with communication between the two ends. Pure vs hybrid ML-KEM has nothing to do with misuse or accurately evaluating this very sharp local security decision. The *only[1]* thing separating them is this trade-off between two tensions: - A subjective and decreasing[2] value hedge against the risk that ML-KEM turns out not to be secure *and we find out before a CRQC becomes relevant*. Once a CRQC is relevant, the legacy X25519 half gives zero value and this is all moot. - A subjective and application-dependent cost in performance, complexity, and coordination due to the explosion of extra algorithms and all the other overhead involved in defining things. *Both* halves of this trade-off are *extremely* subjective and, frankly, of pretty low value. Someone making one choice or the other isn't making a sharp "do I allow this entity to see the connection" decision. They're evaluating this subjective trade-off. (Since accusations keep flying around, I say this as someone who opted to make hybrid the default. And while the volume and tenor of all this discussion have certainly demonstrated that I underestimated the coordination overhead of hybrids, I don't see any reason to change that existing default, RFC or no.) David [1] In particular, "what if ML-KEM is backdoored" or "I think choosing ML-KEM is clearly bad" are not reasons to separate the two. If you do *not* believe ML-KEM is a good bet for post-quantum security, *both* pure and hybrid ML-KEM are out. The only reason we are adding this extra kilobyte to the ClientHello is that we believe there is a pressing need to protect against a CRQC. The legacy X25519 half of the hybrid *will be broken* at that point. That means: * *If* you think all this post-quantum stuff is irrelevant and legacy X25519 will live on, all of this is out. Why in the world would we go from 32 bytes to 1000+ bytes without a darn good reason? * *if* you do not think ML-KEM is our best bet for post-quantum security, you should object to all of this. For *post-quantum* security, hybrids will not save us from a broken ML-KEM. * *If* you think that ML-KEM needs some extra security caveats, you should ask for that consideration to be added to both. Again, for *post-quantum* security, hybrids will not save us from a broken ML-KEM. [2] As time passes, the likelihood of a CRQC becoming relevant goes up, and the confidence one has in ML-KEM goes up. Whatever you believe the baseline was, it should be clear that, every day that passes, the benefit of hybrids goes down. On Wed, Jul 8, 2026 at 11:05 AM Bellebaum, Thomas <thomas.bellebaum= [email protected]> wrote: > Hi Mike, > > not sure I count, because on the one side I did voice concern about the > lack of user-warnings [1,2] but on the other side I agreed that some IETF > standardization was helpful if done right [3]. > > Most importantly, the threat model is different. > HNDL due to a broken KEM is a passive network attack. It works at scale, > simply by collecting ciphertexts. > Lawful interception and relationship abuse are not only active attacks, > but require a partial system compromise (e.g. by RCE or physical access). > > Secondly, the use cases of SSLKEYLOGFILE are at least reasonable to me. > If every application becomes encrypted, tool-based debugging becomes much > easier with a standardized format, in part because no reasonable > alternative exists. > The reasonable alternative here is hybrids, and to the extend that we may > one day move past those, waiting for future improvements. > > Cheers, > > -- TBB > > [1] https://mailarchive.ietf.org/arch/msg/tls/nnqmXWtuBUD7W5NOkB57BYk723c/ > [2] https://mailarchive.ietf.org/arch/msg/tls/dN09iEO9Zt9aOLoFw72pjFoLgKw/ > [3] https://mailarchive.ietf.org/arch/msg/tls/FWmfouytzzqMb614Jv4y1cJxTqc/ > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
