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> 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> > *Sent:* Thursday, December 12, 2024 4:23 PM > *To:* Eric Rescorla <e...@rtfm.com> > *Cc:* 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> 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> 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> > 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 > To unsubscribe send an email to tls-le...@ietf.org > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
