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

Hi Daniel,

On 7/12/26 21:42, Daniel Apon wrote:
> Hi David, Simon, all--
> 
> In a very general context, there have been well-founded warnings
> before about taking legal advice from a public mailing list, e.g.
> whether a license permits this or that, etc.
> 
> Speaking for myself, to address the weird crux of the current
> technical issue (and again: I am not a lawyer.):
> 
> The licensing effort by NIST was intended to provide patent-free
> commercial access to NIST standards. It seems odd, to me, to see
> this turned around some years later, to question the intentions of
> the NIST licenses about whether one can hash this way or that and be
> compliant with the license that NIST has granted, for free, gratis,
> to the world. Anyway, perhaps this is a question better asked on the
> NIST PQC Forum than the (very specific) TLS WG mailing list.

It isn't weird as much as it tracks with using the patent to achieve a 
specific singular (sizes aside) implementation outcome rather than 
encouraging a variety.

NIST won't provide clarity on the list when directly asked and yet it is 
such a simple question. Many people asked NIST over the years including 
on pqc-forum and in the official comments. Still NIST has continued to 
not address the issue. It makes NIST look like they can't address the 
issue because they don't want developers to make a choice that for 
example, deviates from FIPS 203.

Sounds familiar... oh yes as Ken sent in an email earlier today!

 From Thomas R. Johnson's declassified NSA history:

"(FOUO) Once that decision had been made, the debate turned to the issue 
of minimizing the damage. Narrowing the encryption problem to a single, 
influential algorithm might drive out competitors, and that would reduce 
the field that NSA had to be concerned about. Could a public encryption 
standard be made secure enough to protect against everything but a 
massive brute force attack, but weak enough to still permit an attack of 
some nature using very sophisticated (and expensive) techniques? NSA 
worked closely with IBM to strengthen the algorithm against all except 
brute force attacks and to strengthen substitution tables, called 
S-boxes. Conversely, NSA tried to convince IBM to reduce the length of 
the key from 64 to 48 bits. Ultimately, they compromised on a 56-bit key."

I predict that you don't agree that this is relevant.

As we discussed previously: we don't need to discuss the lattice 
hardness assumptions if the Adversary has an advantage that satisfies 
their attack before the lattice issues are the hardness assumption(s) 
needing to be solved.

Here is a fun idea: someone should call their State Senator or 
Congressperson to request an answer from NIST. It would be much more 
problematic if they refused to answer in that case.

Kind regards,
Jacob Appelbaum

> 
> --Daniel
> 
> On Sun, Jul 12, 2026 at 3:11 PM David Stainton
> <[email protected]> wrote:
> 
>>> 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.
>> 
>> Hi Simon!
>> 
>> I appreciate the warning and I am well aware. Maybe you providing
>> this information is helpful for others on the list but it is
>> simply not relevant to Katzenpost since we have no commercial
>> pursuit, we are not titans of the industry, and furthermore we do
>> not force users to use any particular KEM. Any KEM can be used via
>> specifying it in configuration files. Novel KEMs can also be
>> created via our KEM combiner. In light of all of this, I am merely
>> stating that pretty soon when I get around to it, I will make a
>> modified Kyber that hashes m. And this will be made OPTIONALLY
>> available for use in Katzenpost if users choose to use it; and in
>> this context "users" means mixnet operators.
>> 
>> Best regards, David
>> 
>>> 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
>> 
>> _______________________________________________ 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]