On Wed, Sep 24, 2025 at 4:52 PM Martin Thomson <[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]> > 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]> 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]
