> 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.
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]
