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
