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
