Key reuse makes a significant performance difference for a busy TLS server generating thousands of ephemeral keys per second. However, in the case of KEM-based key agreement, the client generates the key. While busy TLS client scenarios exist, I do not expect that major TLS libraries will implement client-side key reuse, regardless of whether an RFC explicitly forbids this.
I support adoption. Cheers, Andrei From: Filippo Valsorda <fili...@ml.filippo.io> Sent: Wednesday, April 2, 2025 3:00 AM To: tls@ietf.org Subject: [EXTERNAL] [TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3 I support adoption. I also would like to prohibit key reuse, but opposing adoption feels like a bad way to reach that outcome: if the document is published by the ISE or just lives on as a widely deployed draft, the WG will have no say in what requirements it has. It also seems clear to me the WG consensus will be for the codepoints to remain "Recommended: N" at least for now. Opposing adoption to force the document to be published in a way that can't be "Recommended: Y" feels like (unnecessarily) meta-gaming the IETF process.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
