[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 20 26-07-08)

Simon Josefsson <[email protected]> Sun, 12 Jul 2026 17:24:54 +0200
Newsgroups	gmane.ietf.tls
Message-ID	<[email protected]>
David Stainton <[email protected]> writes:

> Hi Kris, No. Let’s not move the discussion away from the draft and
> from the extremely relevant context of TLS.
>
> Restoring the hash is reasonable and NIST’s removal wasn’t well
> motivated or justified, their silence to reasonable questions now is
> suspicious when we consider the relevant history.
>
> There may be better designs but they will only slow down deployment.
> The best course of action is restoring the hash over m. It lasted for
> three rounds without a security issue being found by NIST or NSA.
>
> I am going to update the golang hpqc library and the katzenpost mixnet
> project will take the defense in depth route.

The NIST Kyber patent license only grants you a license to use ML-KEM
when implemented according to NIST specifications.

If you deviate, such as by taking the defense-in-depth approach to hash
m to improve robustness against a compromised PRNG, the NIST patent
license does not cover your usage.

People in the IETF used to prefer patent un-encumbered technology, but
things are different today.

https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/selected-algos-2022/nist-pqc-license-summary-and-excerpts.pdf

/Simon

> David Stainton
> Founder and core developer, Katzenpost post quantum mixnet
>
> On Sun, Jul 12, 2026 at 1:08 PM Kris Kwiatkowski <[email protected]> wrote:
>>
>>
>> On 12/07/2026 09:06, John Mattsson wrote:
>>
>>
>> Regarding Jakob Appelbaum's suggested text, I agree that wording
>> along the lines of "the m value is recoverable by the decapsulating
>> peer" should be added to draft-ietf-tls-ecdhe-mlkem,
>> draft-ietf-tls-mlkem, and likely to future IETF KEM specifications
>> as well.
>>
>>
>> I agree with the points below, including that the broader CSPRNG
>> guidance discussion belongs in a wider IETF context such as an
>> RFC4086bis effort.
>>
>> On where the suggested text about 'm' being recoverable by the
>> decapsulating peer should go: I think
>> draft-sfluhrer-cfrg-ml-kem-security-considerations is the proper
>> home for it, rather than the documents that merely define code
>> points for TLS. The TLS drafts could then simply reference
>> it. Duplicating ML-KEM security considerations across
>> draft-ietf-tls-ecdhe-mlkem, draft-ietf-tls-mlkem, and every future
>> KEM code point document seems fragile, and a single CFRG document
>> keeps the guidance consistent. This follows the same logic as your
>> RFC4086bis suggestion: put the guidance where it can be referenced,
>> not in each protocol-specific draft.
>>
>> For the same reason, the discussion itself belongs in CFRG, where it
>> would get review from the crowd focused on cryptographic mechanisms.
>>
>> Cheers,
>> Kris
>>
>> _______________________________________________
>> 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]
signature.asc (application/pgp-signature, 1.2 KB)