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.
Cheers, spt > On Sep 24, 2025, at 20:54, Eric Rescorla <[email protected]> wrote: > > > > On Wed, Sep 24, 2025 at 4:52 PM Martin Thomson <[email protected] > <mailto:[email protected]>> wrote: >> >> >> On Thu, Sep 25, 2025, at 08:16, Eric Rescorla wrote: >> > On Wed, Sep 24, 2025 at 2:47 PM Martin Thomson <[email protected] >> > <mailto:[email protected]>> wrote: >> >> On Thu, Sep 25, 2025, at 03:08, Eric Rescorla wrote: >> >> > On Wed, Sep 24, 2025 at 5:13 AM John Mattsson >> >> > <[email protected] <mailto:[email protected]>> 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. >> >> >> >> That wouldn't be an issue if we didn't allow key share reuse across >> >> connections. >> > >> > I'm not sure that's true. IIRC the rationale for this text was a >> > concern that key shares from different groups in the same connection >> > would be mathematically related. >> >> Sure, identity being the relation most are concerned with. (Non-identity is >> also a relation of sorts...) >> >> I'm saying that we'd have less of a problem getting the text for this right, >> being able to use language along the lines John outlined, if the requirement >> was that a single KEM / ECDH secret could only be *used* once, as opposed to >> the indirect stuff we have. > > Right, and I'd be in favor of that (though as I've said a number of times, as > a generic rule, not as a special rule for ML-KEM). I'm just saying that I > don't think this text is trying to say that, but rather addressing the > relationship between shares in a given connection. > > -Ekr > > >> I guess you are right to point out that you probably shouldn't use the P-256 >> secret with X25519 as well and obviously silly stuff. > > > _______________________________________________ > 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]
