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= [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]
