On Wed, Sep 24, 2025 at 5:13 AM John Mattsson <john.matts...@ericsson.com> wrote:
> ”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. > This text is not about multiple executions of key-establishment but about multiple KeyShareEntries in the same protocol run. -Ekr > > *From: *Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org> > *Date: *Wednesday, 24 September 2025 at 12:31 > *To: *Eric Rescorla <e...@rtfm.com> > *Cc: *Paul Wouters <paul=40nohats...@dmarc.ietf.org>, tls@ietf.org < > tls@ietf.org> > *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 <e...@rtfm.com> wrote: > > > > > > 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 > >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
