”The key_exchange values for each KeyShareEntry MUST be generated independently”
this seems like a weird way to try to partially protect against bad implementations that violate NIST requirements and use Key Share entries in more than one execution of key-establishment. The right approach would be to follow NIST SP 800-227 and do: “If an application uses an ephemeral key pair, the key pair shall be used for only one execution of key-establishment via a KEM and shall be destroyed as soon as possible after its use.” I don’t think anybody want to use implementations violating NIST requirements. My suggestion would be to just state that the requirements in NIST SP 800-227 SHALL be followed. Cheers, John From: Bas Westerbaan <[email protected]> Date: Wednesday, 24 September 2025 at 12:31 To: Eric Rescorla <[email protected]> Cc: Paul Wouters <[email protected]>, [email protected] <[email protected]> Subject: [TLS] Re: KeyShareEntry MUST be generated independently - was Re: Mohamed Boucadair's No Objection on draft-ietf-tls-hybrid-design-15: (with COMMENT) (fwd) Optimal X25519 and ML-KEM-768 keygen take roughly the same time. rustls' X25519 implementation is much more optimised than its ML-KEM implementation, hence the minimal difference reusing X25519 keys. On the question at hand: I do not have a preference. I do not see a security problem with it, and clients that care for the performance didn't seem to need explicit permission anyway. Best, Bas On Tue, Sep 23, 2025 at 2:03 AM Eric Rescorla <[email protected]<mailto:[email protected]>> wrote: On Mon, Sep 22, 2025 at 4:51 PM Martin Thomson <[email protected]<mailto:[email protected]>> wrote: If this is removed, so that we effectively require two X25519 (or P-256 or whatever) key generation runs for each handshake, then the MUST will be ignored. We have evidence[1] of this having a material effect on performance and multiple implementations already do it. I believe Eric, as author of RFC 6919, knows how to recognize MUST (BUT WE KNOW YOU WON'T). [1] https://mailarchive.ietf.org/arch/msg/tls/kDPOovPkJ1TO8mcqh_3YuOvcdCs/ and replies It's possible the MUST will be ignored, which is why I asked to hear about implementor's views on this. I agree that if people will ignore it, we shouldn't mandate it. I'm not going to argue about the definition of "material" but for reference, here are the measurements with rustls: https://rustls.dev/perf/2024-12-17-pq-kx/ The post in question describes the difference "as small but measurable" which is to say 4.3% in the (worst) resumed case, which is already less than half as fast as with just X25519. Given that this burden is carried entirely by the client and that most clients do not in fact do huge number of successive TLS handshakes, I'd be interested in hearing from someone who has a system where this would be a noticeable difference in the field as opposed to in a benchmark. -Ekr On Tue, Sep 23, 2025, at 03:56, Eric Rescorla wrote: > My view is it would be better to have one rule, potentially at the cost of > some slight overhead, and the measurements I've seen seem quite > slight. However, given that it's been this way for some time and there > are implementors who do this, I do want to be sure we take their > views into account. > > I do want to mention that I don't think imposing a requirement now need > create an interop problem with the installed base: we could, for instance, > forbid people to check this one thing. > > -Ekr > > > On Mon, Sep 22, 2025 at 10:30 AM Paul Wouters > <[email protected]<mailto:[email protected]>> wrote: >> >> Hi, >> >> While I did approve the draft-ietf-tls-hybrid-design as there were no >> blocking items left, there was a comment by Med and supported by Eric >> to at least talk again about the Key Sharing being allowed or not, eg: >> >> Med said: >> >> # Relaxing a MUST in the base TLS spec? >> >> CURRENT: >> [TLS13] requires that ``The key_exchange values for each >> KeyShareEntry MUST be generated independently.'' In the context of >> this document, since the same algorithm may appear in multiple >> named >> groups, this document relaxes the above requirement to allow the >> same >> key_exchange value for the same algorithm to be reused in multiple >> KeyShareEntry records sent in within the same ClientHello. >> >> Isn’t this modifying aspects of the base TLS? How to reconcile this >> with the >> claim in the previous point? >> >> >> Eric said: >> >> From a technical perspective I'd like to revisit this point. My memory >> is that the >> plausible KEMs actually have fast key generation, as does EC. Why not >> just >> keep the requirement as-is? >> >> We also had two implementations that seemed to do key sharing. >> >> >> Please let me know if you agree with the curent document for the >> relaxing of the TLS 1.3 rules that these "MUST be generated >> independently" to be relaxed, or whether you think the relaxing is >> not neccessary. Please do state _why_ you believe one or the other >> is the right choice. >> >> If this turns out to be a longer dicsussion, I will inform the RFC >> Editor to pause processing of the document in the next few days. >> (In the unlikely even that the authors receive the AUTH48 email, please >> let it sit in your inbox for now) >> >> Paul >> >> _______________________________________________ >> TLS mailing list -- [email protected]<mailto:[email protected]> >> To unsubscribe send an email to [email protected]<mailto:[email protected]> > _______________________________________________ > TLS mailing list -- [email protected]<mailto:[email protected]> > To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
