On Fri, Oct 24, 2025 at 10:52 AM Paul Wouters <[email protected]> wrote:
> On Fri, 24 Oct 2025, Sean Turner wrote: > > > 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) > > > > Hi! It appears that the emerging consensus here is to make no changes as > a result of this comment. Mostly this is because it appears that the MUST > will be ignored. > > If you disagree with this, please indicate why by 30 October 2025. > > I think reading it context does help to frame the issue properly for > evaluation: > > > https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-15#section-3.2 > > > A note I have though is as the start of that paragraph states: > > [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. > > The question is if this "relaxing of a [TLS13] requirement" means this > draft Updates: [TLS13]. I think it can be argued that it only updates > the requirement for hybrids, and so one does not need to know this > "relaxing requirement" in other cases, so an Updates: clause is not > needed. But if new drafts specifying hybrids come out, it might not > be obvious to people this is the case unless those drafts mention this > ssue specifically via a normative reference to this draft. So that is > an argument to argue in favour of an Updates: clause. > > The document currently does not have an Updates: clause for this. > We all agree that this is overriding the text in 8446, right? I don't think "Updates" is really clear enough to know whether we need the header or not (this is one reason I'm not a fan of the tags in the first place). With that said, as I observed the other day, RFC 8446-bis is actually ahead of this draft in the pipeline, so I think if we are going to continue to allow this practice, we *should* modify 8446-bis accordingly to permit it. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
