Really now? Participants of this working group (by eg. voting or discussing) are required to disclose IPR. None have been filed on ephemeral or non-ephemeral use of ML-KEM.
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-tls-mlkem https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-tls-ecdhe-mlkem https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-tls-rfc8446bis https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-irtf-cfrg-hybrid-kems https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-connolly-cfrg-xwing-kem On Tue, Mar 24, 2026 at 11:21 AM Simon Josefsson <simon= [email protected]> wrote: > Viktor Dukhovni <[email protected]> writes: > > > On Mon, Mar 23, 2026 at 04:40:14PM -0400, Sean Turner wrote: > > > >> This message starts a two week consensus call on whether > >> draft-ietf-tls-rfc8446bis should prohibit key share reuse between > >> connections. ekr has already produced a PR; see [1]. Please let the > >> list know whether you do or do not support this change by 6 April > >> 2026. Please note that if you already replied in here:[2] there is no > >> need to also reply to this thread unless you changed your mind. > >> > >> Note that as draft-ietf-tls-rfc8446bis in currently in AUTH48, this > >> may add some delay to its publication. We believe that any delay would > >> be small because we already know there are outstanding PRs that needed > >> to be worked. > > > > FWIW, I still believe that the current SHOULD NOT (reuse ephemeral keys) > > is better than the proposed MUST NOT, however that's not a battle worth > > fighting. It seems that the prevailing wisdom is to make the change, > > and no disaster will ensue if it is made. > > +1 > > I believe implementations and deployment that make reasonable use of key > share reuse (which I believe the earlier discussion acknowledged) will > happily continue to do so, violating the MUST NOT, and things will be > fine. > > This all seems motivated by insuring against the ML-KEM patent license > that limits for what ML-KEM can be used for, to allow the IETF to say > "oh but TLS does not allow ephemeral key shared so we don't care about > that use-case". > > /Simon > _______________________________________________ > 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]
