"1. There is a patent license from NIST [1] claiming ML-KEM is covered by patents. Thanks Bas for pointing out that none of I-D's has a IETF IPR disclosures on them. I am surprised nobody has notified the IETF about this already, so I submitted a third-party IPR disclosure update using the IETF IPR web form, to make people aware of the claims. It is probably stuck in the IETF IPR queue somewhere."
It is a fantastic idea to include an IPR disclosure with proper references. (It's likely good to avoid 'interpreting' legal documents in any IETF official document, aside from pointing to the relevant references.) -- " 2. The patent license says (roughly) that it applies when you implement the NIST ML-KEM specifiction, and implicitly: that the license does not apply otherwise. It is unclear to what extent NIST intends ML-KEM to be used in multiple key-establishments, see for example the 'Summary' page of [2] requesting that 'NIST should mandate that ephemeral encapsulation keys are used in exactly one key-establishment transaction'. I agree with that recommendation, but I'm not sure if it will go anywhere. The Ml-KEM specification only talks about a two-party setup, not for multi-party setups. NIST SP 800-56A says an ephemeral private key shall only be used in one key-establishment." Yes: The original intent was that prior IPR claims from the two patents (Ding+CNRS) would be waived, in the case that implementers follow the NIST specification of ML-KEM as-is, without modification. It was fully expected that "variations-on-the-theme" that don't conform to FIPS 203 ( https://csrc.nist.gov/pubs/fips/203/final ) would still be subject to the original patent claims. -- " 3. My take of that is that adapting ML-KEM for non-ephemeral and/or multi-party/session mode and staying within the NIST patent license isn't well-specified. That is the limit of the ML-KEM patent license that I referred to." ML-KEM use for these modes is described in https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-227.pdf on page 16 (paragraph beginning "Static versus ephemeral key pairs" under the bold-paragraph "Additional considerations). Note that SP 800-227 is cited in https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf as Reference 1. --- That all said, I sort of now default back to what others have said (more or less) further down the thread: I (still) support this document change, for reasons totally unrelated to the ML-KEM patent license. On Thu, Mar 26, 2026 at 6:50 AM Simon Josefsson <[email protected]> wrote: > Daniel Apon <[email protected]> writes: > > > I'll be honest; I don't remotely understand how to interpret the English > of > > this sentence: > > > > " 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". " > > > > What "*limits*" on the ML-KEM patent license are you referring to? > > I'll try to explain my position -- Eric apparently interpreted what I > wrote in exactly the opposite way to what I intended, suggesting > something was missing. > > 1. There is a patent license from NIST [1] claiming ML-KEM is covered by > patents. Thanks Bas for pointing out that none of I-D's has a IETF IPR > disclosures on them. I am surprised nobody has notified the IETF about > this already, so I submitted a third-party IPR disclosure update using > the IETF IPR web form, to make people aware of the claims. It is > probably stuck in the IETF IPR queue somewhere. > > 2. The patent license says (roughly) that it applies when you implement > the NIST ML-KEM specifiction, and implicitly: that the license does not > apply otherwise. It is unclear to what extent NIST intends ML-KEM to be > used in multiple key-establishments, see for example the 'Summary' page > of [2] requesting that 'NIST should mandate that ephemeral encapsulation > keys are used in exactly one key-establishment transaction'. I agree > with that recommendation, but I'm not sure if it will go anywhere. The > Ml-KEM specification only talks about a two-party setup, not for > multi-party setups. NIST SP 800-56A says an ephemeral private key shall > only be used in one key-establishment. > > 3. My take of that is that adapting ML-KEM for non-ephemeral and/or > multi-party/session mode and staying within the NIST patent license > isn't well-specified. That is the limit of the ML-KEM patent license > that I referred to. > > 4. Having the TLS spec allow non-ephemeral modes could thus be a problem > from a deployment perspective, where some implementations could use > ML-KEM-derived KEM's in a non-ephemeral mode, and some couldn't. > > 5. The text already says SHOULD NOT, and the feature isn't sufficiently > important to Internet security to motivate a loop-hole, and the feature > breaks Perfect-Forward-Secrecy (which is a useful property), so changing > it to MUST NOT allows us all to just say "please no" to non-ephemeral > uses of ML-KEM keys citing the TLS spec requirement as an argument. If > better specifications on how to actually solve this problem materialize > (inspired by KEMTLS?), they can agument this requirement keyword. I > think there is useful technology here, but not ready yet. > > Even if this wasn't Eric's motivation, this all seems like a reasonable > and useful motivation for changing the text to me. It will be an > argument that I will use when someone suggest to optimize ML-KEM by > re-using the private key for multiple sessions. I don't follow what > Eric means that this argument would reflect badly on anyone, and I'm > hoping that was a misunderstanding that this e-mail improves on. I > believe the argument would reflect well on the people using it. > > There are many other reasonable positions to end up in that are > different from the one above. A simple approach of "The ML-KEM patents > are nonsense and I don't care about them" solves many concerns, and may > be the most pragmatic and common opinion right now. > > /Simon > > [1] > https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/selected-algos-2022/nist-pqc-license-summary-and-excerpts.pdf > > [2] > https://csrc.nist.gov/csrc/media/Presentations/2025/ml-kem-is-great/images-media/ml-kem-is-great.pdf > > > On Tue, Mar 24, 2026 at 12:43 PM Eric Rescorla <[email protected]> wrote: > > > >> > >> > >> On Tue, Mar 24, 2026 at 3:20 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". > >>> > >> > >> No. That's not correct, at least not for me. > >> > >> Separately, I've noticed you have a tendency to attribute motives to > >> others that > >> aren't really accurate and often seem designed to reflect badly on them. > >> I would ask you to stop. > >> > >> -Ekr > >> > >> _______________________________________________ > >> 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]
