Hi David, > > Just to be clear about the scope of this change, it only prevents literal > > reuse of the same share. It does not rule out implementations generating > > related shares from shared secret material since that is not visible to the > > client. This change enforces non-reuse, not independence of key shares.
You were not really the audience for that note. It was aimed at readers skimming the thread who might read too much into this change and assume that turning this SHOULD into a MUST means TLS 1.3 now guarantees forward secrecy. The point was simply to clarify that this change does not close the door on TLS visibility "attacks" or make any guarantee about forward secrecy. As Martin noted later in this thread, the stated benefit is around reducing tracking. What I found odd in your reply was the suggestion that independence is not relevant to TLS 1.3. That is hard to square with the protocol's own security story. TLS 1.3bis says that forward secrecy depends on fresh (EC)DHE keys for each connection, and it warns that retaining material intended to be ephemeral or connection-specific can effectively create additional long-term keys whose compromise exposes traffic. Sure, for a specific mechanism like ML-KEM under FIPS 203, you can point to a tighter key generation story. But this thread is about TLS 1.3 generally, not ML-KEM specifically, and other key-share primitive specs have even weaker stories here. If one party derives its ephemeral keys from deterministic or otherwise retained state, the counterparty has no way to tell in-band. On the Internet, nobody knows whether your implementation is FIPS-certified or not. I think we can agree that key independence is not something TLS can currently enforce at the protocol layer. But it remains relevant when analyzing the security properties that a TLS 1.3 connection (or sequence of connections) provides in practice. -Nick On Mon, Mar 16, 2026 at 3:40 PM David Benjamin <[email protected]> wrote: > > > Concerns about independence of key shares don't make much sense at the TLS > layer. When TLS says to generate an ECDH/ML-KEM/etc key, you go to > cryptographic primitive's spec and find out how it says to generate a > keypair. It's up to the primitive's responsibility, not TLS's, to provide > "generate key" and "encap" operation that grabs independent random bytes at > the right places. > > For example, FIPS 203 explicitly tells you in several places to grab a number > of random bytes. It also has a section defining this more precisely. Sure, > you may have mechanically implemented your random number as `return 4`. That > would not be FIPS 203. > > (Yes, sometimes primitive specs don't have exactly the "API" we want, so > their TLS documents provide the glue text to bridge between what TLS wants > and the primitive's "API". This is a pretty minor thing that's part of all > spec-writing here. It is also why simply citing a document like FIPS 203 is > insufficient to define a TLS algorithm. But also let's not balloon that > trivial work out of proportion because it's really not that big of a job.) > > So, no, this change does not enforce independence of key shares, but that's > the easy one. We enforce independence in TLS by simply citing the correct > primitive and moving on. TLS's responsibility is to enforce non-reuse of > already-independent key shares, because the primitive cannot know when the > application wants long-lived keys and when it wants ephemeral keys. > > David > > On Mon, Mar 16, 2026 at 2:24 PM Nick Sullivan <[email protected]> > wrote: >> >> I support the change. Prohibiting key share reuse is a worthwhile >> improvement. >> >> Just to be clear about the scope of this change, it only prevents literal >> reuse of the same share. It does not rule out implementations generating >> related shares from shared secret material since that is not visible to the >> client. This change enforces non-reuse, not independence of key shares. >> >> -Nick >> >> On Mon, Mar 16, 2026 at 2:43 PM Muhammad Usama Sardar >> <[email protected]> wrote: >>> >>> On 16.03.26 05:24, Martin Thomson wrote: >>> >>> Proposal: >>> >>> Prohibit key share reuse in TLS 1.3. >>> >>> I support this proposal. As supporting evidence, I'll do and share the >>> formal analysis of the 6 scenarios that John has kindly shared in some >>> other thread. I'll be very surprised if any of those will not break the >>> properties. >>> >>> Best regards, >>> >>> -Usama >>> >>> _______________________________________________ >>> 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] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
