Hi Eric, Ephemeral key reuse in the Windows TLS stack is only done on the sever side, so it does not apply to ML-KEM. (For hybrids, key reuse only applies to the ECDHE component.)
Cheers, Andrei From: Eric Rescorla <e...@rtfm.com> Sent: Monday, December 16, 2024 7:03 AM To: Andrei Popov <andrei.po...@microsoft.com> Cc: Richard Barnes <r...@ipv.sx>; tls@ietf.org Subject: Re: [EXTERNAL] [TLS] Re: Disallowing reuse of ephemeral keys Thanks. It seems like that would imply that Web clients cannot safely enforce a non-reuse requirement even if we had one. Do you plan to reuse ML-KEM keys as well? The situation seems to be different because, as Scott observes, it's the client who reaps the benefit. -Ekr On Thu, Dec 12, 2024 at 4:29 PM Andrei Popov <andrei.po...@microsoft.com<mailto:andrei.po...@microsoft.com>> wrote: * If there are significant implementations which do reuse… By default, servers using Windows TLS stack reuse ECDHE keys for up to 30 sec. Reuse time can be configured or altogether disabled by the system admin. Disabling comes at a significant performance cost (for a busy TLS server). Cheers, Andrei From: Richard Barnes <r...@ipv.sx<mailto:r...@ipv.sx>> Sent: Thursday, December 12, 2024 4:23 PM To: Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> Cc: tls@ietf.org<mailto:tls@ietf.org> Subject: [EXTERNAL] [TLS] Re: Disallowing reuse of ephemeral keys I concur with EKR re: validation. There's plenty of precedent in IETF specs for requirements that cannot be validated by the remote party, especially when it comes to maintaining security properties. See, e.g., the ticket deletion requirements in RFC 8446. --RLB On Thu, Dec 12, 2024 at 7:18 PM Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> wrote: I agree with Richard about the ordering. I think validation presents a distinct question: I don't think we should require validation, as it is extra work for the peer and may not be practical. If there are significant implementations which do reuse, then we should discourage or forbid validation for now [0] to avoid breakage and then later we can allow it. If there are no such implementations, then I think we can allow and/or encourage validation. -Ekr [0] This might be a reason to distinguish between existing and new cipher suites. On Thu, Dec 12, 2024 at 10:01 AM Richard Barnes <r...@ipv.sx<mailto:r...@ipv.sx>> wrote: My preference order would be 3 > 1 >> 2. 3 seems like it encodes the expectation of most people for what the protocol means. If you're using a cipher suite labeled something like "ECDHE", it's reasonable to expect that it's actually ephemeral, i.e., that there's not key material hanging around afterward that could compromise the session. Allowing key reuse (even tacitly) allows one side to silently violate that invariant. I'm not worried about backward compat, since (a) it's wire compatible, and (b) any change here will be a separate RFC, so people who care about validating can ask specifically "do you comply with RFC XXXX"? 1 would be the next most plausible fallback, on the general principle that IETF specifications define externally visible behavior, and this is not. We should not do 2 because as Filippo says, there's no technical reason for it. On Thu, Dec 12, 2024 at 12:54 PM Filippo Valsorda <fili...@ml.filippo.io<mailto:fili...@ml.filippo.io>> wrote: I support some variation of 2 or 3, depending on what encounters the most resistance. I agree there is no technical reason to disallow it for e.g. X25519MLKEM768 and not X25519, but in practice it might be easier to set a new rule for something that's still being rolled out and still a draft. Both ECDH and KEMs support key share (or public key) reuse in theory but in practice it makes implementation issues much more likely to be practically exploitable, and the hypothetical performance gain of reuse is marginal. The spec should defend against that and point implementations towards the safer course of action. As always, there is no protocol police, so implementations that want to risk shooting their foot off will be able to do so, but they will be off-spec, which is a useful signal. _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org> _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
