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] >
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
