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]> wrote: > > > On Mon, Sep 22, 2025 at 4:51 PM Martin Thomson <[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]> 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] >> >> To unsubscribe send an email to [email protected] >> > _______________________________________________ >> > TLS mailing list -- [email protected] >> > To unsubscribe send an email to [email protected] >> > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
