On Mon, Sep 22, 2025 at 4:51 PM Martin Thomson <m...@lowentropy.net> 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 > > <paul=40nohats...@dmarc.ietf.org> 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 -- 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
