[TLS] Re: [EXTERNAL] Re: Disallowing reuse of ephemeral keys

[Eric Rescorla <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> *Sent:* Thursday, December 12, 2024 4:23 PM
> *To:* Eric Rescorla <[e-mail]>
> *Cc:* [e-mail]
> *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-mail]> 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 <[e-mail]> 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 <[e-mail]>
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>