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

Hi Jacob,

Everything I wrote in the message at 9:44AM US Eastern time 7/8/2026 is factual regardless of many questions you had for me about things.

Every technical change was publicly discussed at the pqc-forum and there was a publicly known reason for the change.

Beside the removal of the hash of m, are there any other technical details concerning you about the security of ML-KEM in TLS 1.3 ?

Have a great day.

Regards,
Quynh.
PS: Don't be surprised if I don't answer your questions if I think they are not technically important to ML-KEM's security in TLS 1.3. And, likely I won't answer a question if it has already been discussed at the forum.

> -----Original Message-----
> From: Jacob Appelbaum <[email protected]>
> Sent: Wednesday, July 8, 2026 2:11 PM
> To: Dang, Quynh H. (Fed) <[email protected]>; TLS List <[email protected]>
> Cc: Markku-Juhani O. Saarinen <[email protected]>
> Subject: Re: [EXTERNAL] Re: [TLS] Re: [EXTERNAL] Re: WG Last Call: draft-ietf-
> tls-mlkem-08 (Ends 2026-07-08)
>
> Hello Quynh,
>
> Thank you for your reply.
>
> On 7/8/26 15:43, Dang, Quynh H. (Fed) wrote:
> > Hi Jacob,
> >
> > The group authoring FIPS 203 did not have any meeting with the NSA and
> > the NSA had zero authorship of the FIPS 203.
>
> This is a surprising statement given the public information about NIST and
> NSA's relationship.
>
> Public FOIA material [0] appears to show substantial NSA involvement in NIST
> PQC work, which makes your statement surprising and worth clarifying.
>
> The FOIA highlights [1] say the [email protected] team included more NSA
> members than NIST members and that NSA had secret input/meetings with
> NIST on PQC, but that is broader than FIPS 203 authorship:
>
> "NIST's Post Quantum Cryptography Team was mostly NSA. The FOIA results
> show that what NIST publicly labeled as the "Post Quantum Cryptography
> Team, National Institute of Standards and Technology (NIST), [email protected]"
> actually had more NSA members than NIST members. The secret NSA
> members of the [email protected] team were Bradley C. Lackey, Daniel Kirkwood,
> David Hubbard, David Tuller, Jerry Solinas, John McVey, Laurie Law, Mark
> Motley, Nick Gajcowski, Scott Simon, and later Rich Davis." [2] [3] [4]
>
> Some of those names are familiar to me. Are any on this list taking a position
> on the draft in question? A wonderful moment for government transparency
> has presented itself. Thank you to the IETF for this opportunity.
>
> Looking at the released documents such as [5] where a well-known NIST
> (Top) Cryptographer wrote in his email: "I've incorporated the revisions and
> edits we discussed regarding the comments received from Donna and the
> NSA." Quynh - the email metadata from that FOIA release says that you were
> in the CC list.
>
> How should the public reconcile your claim with the released email [5] saying
> that comments from "Donna and the NSA" were incorporated?
>
> Is this a mistake or a misunderstanding? For example are you not counting [5]
> comments from the NSA... because their feedback was incorporated into the
> PQC NISTIR version 2 document as part of the larger PQC process? Does that
> mean NIST's position is that FIPS 203 wasn't influenced by their own PQC
> NISTIR document? I read `NISTIR` in Section 2.2 Acronyms (on page 4) of FIPS
> 203 and the NISTIR is cited as reference [23] (on page 43) of FIPS 203 [6]:
>
> "Alagic G, Apon D, Cooper D, Dang Q, Dang T, Kelsey J, Lichtinger J, Liu YK,
> Miller C, Moody D, Peralta R, Perlner R, Robinson A, Smith-Tone D
> (2022) Status report on the third round of the NIST post-quantum
> cryptography standardization process (National Institute of Standards and
> Technology, Gaithersburg, MD), NIST Interagency or Internal Report
> (IR) 8413.
> https://doi.or/
> g%2F10.6028%2FNIST.IR.8413-
> upd1&data=05%7C02%7Cquynh.dang%40nist.gov%7C8a0445ed945f404f1
> a1b08dedd2d61b4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0%
> 7C639191384484652031%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc
> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld
> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3Rlb5zid5iEipm%2F2fzO%2FMsL
> GO8tIfr2nPEBwbPA6u4I%3D&reserved=0 "
>
> I do not see how to reconcile your statement with the public FOIA record
> without a more precise definition of "the group authoring FIPS 203,"
> "meeting," and "authorship."
>
> It would be immensely helpful if you or NIST could clarify - who do you include
> by name in the group authoring FIPS 203 and what exactly do you mean by a
> meeting?
>
> It sounds pedantic, I realize. Unfortunately it is only because of a proactive
> lawsuit against NIST that members of the public are able to cite the above
> emails. NIST could do themselves a big favor here and release significantly
> more information without being forced through legal process.
>
> >
> > At the time of authoring/writing FIPS 203, we were very confident in
> > the security of the NIST-approved RBGs, we wanted people to use them,
> > so the FIPS had a requirement of using an appropriate security
> > strength NIST-approved RBG.
> >
>
> Didn't NIST write FIPS 203 _after_ NIST's John Kelsey did the retrospective on
> NIST's failure in the Dual_EC_DRBG fiasco? Was this history not part of your
> threat model or included in your (internal or
> external) analysis in any documented manner?
>
> There's an old joke about the TSA and how it tries to solve yesterday's security
> threats tomorrow. Is NIST... at least trying to solve its own security
> catastrophes of a decade ago... today or at least for... tomorrow?
>
> > As others have pointed out before, hashing m in the ML-KEM's spec only
> > protects the KEM, the whole system is still considered compromised
> > when other crypto functions rely on the security of the broken or
> > attacker-controlled RBG.
>
> Okay - I understand that we agree that hashing `m` is not harmful to the ML-
> KEM spec. I also understand that we agree that hashing m even protects the
> KEM.
>
> But do I understand the rest of your point? I read you as saying that...
> NIST... left the `m` unhashed so that the KEM would be unprotected because...
> the rest of the system would also be compromised anyway?
>
> Do you dispute that, if `m` is produced by a Dual_EC_DRBG-shaped RNG, not
> hashing `m` allows a TLS client to obtain a useful oracle that hashing `m` would
> close?
>
> Hashing `m` would protect the KEM and close this ML-KEM oracle against a
> Dual_EC_DRBG-shaped NOBUS advantage for a large-scale adversary.
> Naturally, if the larger protocol leaks a similar RNG state before or after, we
> would have more than one problem to resolve. Still, we should try to resolve
> each of the issues rather than pointing at related problems to justify solving
> none of them.
>
> > We think we made a good judgement call to remove the hash (discussed
> > in my previous email).  We also understood the reason that some others
> > wanted to keep the hash.
>
> What is the standard of evidence that would convince you personally or NIST
> to the contrary to issue an errata such that `m` is hashed to prevent this issue?
>
> For example, what if someone showed you a construction to make ML-KEM
> not just secure against this exact issue but also to resolve the hybrid debate
> without any extra bytes on the wire? I have such a design and I have
> implemented it.
>
> Relatedly, would NIST ensure that the patent/IPR concerns would not be
> enforced against such an implementation?
>
> It would help to clarify whether NIST's patent license agreements apply only to
> ML-KEM as published by NIST, or also to variants that hash `m` or otherwise
> transform `m`. If developers are free to hash `m` or to use a non-NIST-
> approved RBG under NIST's patent license agreements, I am certainly not
> alone in welcoming clarification on this matter.
>
> I have posed many questions, and I appreciate you taking the time to read
> them. Thanks in advance, and thank you again for your work authoring FIPS
> 203.
>
> Kind regards,
> Jacob Appelbaum
>
>
> [0]
> https://nist.p/
> qcrypto.org%2Ffoia%2Findex.html&data=05%7C02%7Cquynh.dang%40nist.
> gov%7C8a0445ed945f404f1a1b08dedd2d61b4%7C2ab5d82fd8fa4797a93e
> 054655c61dec%7C0%7C0%7C639191384484715842%7CUnknown%7CTW
> FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa
> W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KQ
> D%2F%2FTl4lLVgd1YCz5WHMVboj9k7mBmT8iAR8Ypwd%2FQ%3D&reserved
> =0
>
> [1]
> https://nist.p/
> qcrypto.org%2Ffoia%2Fhighlights.html&data=05%7C02%7Cquynh.dang%40
> nist.gov%7C8a0445ed945f404f1a1b08dedd2d61b4%7C2ab5d82fd8fa4797
> a93e054655c61dec%7C0%7C0%7C639191384484767533%7CUnknown%7
> CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi
> JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=l
> 7f7UaDwXTyaTXOuYwYqn2YceWpcuAxic42VhpgiATE%3D&reserved=0
>
> [2]
> https://nist.p/
> qcrypto.org%2Ffoia%2F20230815%2FRe_%2520pqc%2520mailing%2520list
> &data=05%7C02%7Cquynh.dang%40nist.gov%7C8a0445ed945f404f1a1b0
> 8dedd2d61b4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0%7C63
> 9191384484812340%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO
> nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy
> fQ%3D%3D%7C0%7C%7C%7C&sdata=esh2gmMa5l0D9chFkhE%2FgusyQP0
> 9wP0ndToGTyUj4bA%3D&reserved=0(1)-3.pdf
>
> [3]
> https://web/.
> archive.org%2Fweb%2F20230910091944%2Fhttps%3A%2F%2Fcsrc.nist.gov
> %2FCSRC%2Fmedia%2FEvents%2FISPAB-MARCH-2014-
> MEETING%2Fdocuments%2Fa_quantum_world_v1_ispab_march_2014.pdf&
> data=05%7C02%7Cquynh.dang%40nist.gov%7C8a0445ed945f404f1a1b08d
> edd2d61b4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0%7C6391
> 91384484853183%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ
> %3D%3D%7C0%7C%7C%7C&sdata=7fBkCMQjFUXEEl5M07iBe8Ahnf0gm%2
> BHps5sQ9KRXb2Q%3D&reserved=0
> was authored by "Post Quantum Cryptography Team, National Institute of
> Standards and Technology (NIST), [email protected]"
>
> [4]
> https://nist.p/
> qcrypto.org%2Ffoia%2F20230815%2FRe_%2520pqc%2520mailing%2520list
> &data=05%7C02%7Cquynh.dang%40nist.gov%7C8a0445ed945f404f1a1b0
> 8dedd2d61b4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0%7C63
> 9191384484884591%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO
> nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy
> fQ%3D%3D%7C0%7C%7C%7C&sdata=7qLvBB0Se4BCW5rT2D6Qe4%2FW66
> LwDds5xMDEFF5iNz8%3D&reserved=0(1)-3.pdf
> includes the list of [email protected] people
>
> [5]
> https://nist.p/
> qcrypto.org%2Ffoia%2F20230915%2FRe_%2520PQC%2520NISTIR%2520ve
> rsion%25202&data=05%7C02%7Cquynh.dang%40nist.gov%7C8a0445ed94
> 5f404f1a1b08dedd2d61b4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0
> %7C0%7C639191384484909081%7CUnknown%7CTWFpbGZsb3d8eyJFbXB
> 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp
> bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sdhN0Wr05ckhl9vb4Roy
> qPnTC86VVzZWkEwAW55GlcY%3D&reserved=0(2).pdf
>
> [6]
> https://nvlpu/
> bs.nist.gov%2Fnistpubs%2FFIPS%2FNIST.FIPS.203.pdf&data=05%7C02%7Cq
> uynh.dang%40nist.gov%7C8a0445ed945f404f1a1b08dedd2d61b4%7C2ab
> 5d82fd8fa4797a93e054655c61dec%7C0%7C0%7C639191384484927281%
> 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu
> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C
> %7C%7C&sdata=6IyafioHpbMx620xq1tn0MgWzftZUcipmB5Zx2qS3Bk%3D&r
> eserved=0
>
>
> > Regards, Quynh.
> >
> >> -----Original Message----- From: Jacob Appelbaum
> >> <[email protected]> Sent: Wednesday, July 8, 2026 7:21 AM To:
> >> Dang, Quynh H. (Fed) <[email protected]>; TLS List <[email protected]>
> >> Cc: Markku-Juhani O. Saarinen <[email protected]> Subject:
> >> [EXTERNAL] Re: [TLS] Re:
> >> [EXTERNAL] Re: WG Last Call: draft-ietf-tls- mlkem-08 (Ends
> >> 2026-07-08)
> >>
> >> Hi Quynh,
> >>
> >> On 7/8/26 12:57, Dang, Quynh H. (Fed) wrote:
> >>> And NSA did not ask us to consider removing the hash.
> >>
> >> For transparency and clarity: Are you making this statement as a
> >> participant in the confidential NIST/NSA working group meetings as
> >> part of authoring FIPS 203?
> >>
> >> Kind regards, Jacob Appelbaum
> >>
> >>
> >>>
> >>> Regards, Quynh.
> >>>
> >>> From: Dang, Quynh H. (Fed) Sent: Wednesday, July 8, 2026 6:42 AM
> >>> To: TLS List <[email protected]> Cc: Markku-Juhani O. Saarinen
> >>> <[email protected]> Subject: RE: [EXTERNAL] [TLS] Re: WG Last
> >>> Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
> >>>
> >>> Hi all,
> >>>
> >>> See the discussion here about removing the hash of the message m.
> >>>
> >>>
> >> https://gcc02.safelinks.protection.outlook.com/?
> >> url=https%3A%2F%2Fgrou
> >>> ps.google.com%2Fa%2Flist.nist.gov%2Fg%2Fpqc-
> >> forum%2Fc%2FWFRDl8DqYQ4%2F
> >>>
> >>
> m%2FqmVANi7EAwAJ&data=05%7C02%7Cquynh.dang%40nist.gov%7C27e
> >> 432e9a9ac41
> >>>
> >>
> 68aad008dedce325b9%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C
> >> 0%7C639191
> >>>
> >>
> 065341348557%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd
> >> WUsIlYiOiIwL
> >>>
> >>
> jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0
> >> %7C%7C%
> >>>
> >>
> 7C&sdata=nrQbwjt%2FNOMJAsb43n8djjf6m1ec%2BeAkEKUJSq1gIXQ%3D&
> >> reserved=0
> >>>
> >>> The reason to remove it was that hashing m would be bad, introduce a
> >>> cost
> >> for side-channel security implementations (ask Markku for detail).
> >> In addition, we require an approved RBG. If the RBG of a system is
> >> broken, or controlled by the attacker, the security of the whole
> >> system should be assumed to be broken anyway.
> >>>
> >>> I was a main author of the FIPS 203.
> >>>
> >>> Top level cryptographers know ML-KEM was not back-doored.
> >>>
> >>> Regards, Quynh.
> >>>
> >>> From: Thom Wiggers
> >> <[email protected]<mailto:[email protected]>>
> >>> Sent: Wednesday, July 8, 2026 5:52 AM To: Eliot Lear
> >>> <[email protected]<mailto:[email protected]>> Cc:
> >>> <[email protected]<mailto:[email protected]>>
> >>> <[email protected]<mailto:[email protected]>> Subject: [EXTERNAL] [TLS]
> >>> Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
> >>>
> >>> Hi,
> >>>
> >>> ML-KEM is arguably not backdoorable unless you break the RNG.
> >>> Bad RNG is
> >> something that we can't really protect against anyway. Classic
> >> cryptography is also broken if the RNG is busted. Finally, the TLS
> >> key schedule still mixes in all messages from both sides rendering
> >> the point moot for TLS.
> >>>
> >>> On a more instructive point, ETSI's "quantum-safe enterprise
> >>> transport
> >> security" (ETSI TS 104 145<https://
> >> gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>
> http://www/.
> >>
> etsi.org%2F&data=05%7C02%7Cquynh.dang%40nist.gov%7C8a0445ed945f
> 404f1a
> >>
> 1b08dedd2d61b4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0%7
> C639191384
> >>
> 484950857%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs
> IlYiOiIwLjA
> >>
> uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7
> C%7C%7
> >>
> C&sdata=EhOquPsB1E2uZKRWUnBDEZ3K0dxtG8Gg3smMDcFxIa4%3D&reser
> ved=0%2Fd
> >> eliver%2Fetsi_ts%2F104100_104199%2F104145%2F01.0
> >>
> 1.01_60%2Fts_104145v010101p.pdf&data=05%7C02%7Cquynh.dang%40n
> >>
> ist.gov%7C27e432e9a9ac4168aad008dedce325b9%7C2ab5d82fd8fa4797a
> >>
> 93e054655c61dec%7C0%7C0%7C639191065341386930%7CUnknown%7C
> >>
> TWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJ
> >>
> XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=g
> >>
> gAnSn%2FHdBJ81j13mWw9Z%2FVAH47LG8xEjoNjarVQE0g%3D&reserved=0
> >>> , paragraph 5.3.2) relies exactly on generating the encapsulation
> >>> seed
> >> deterministically instead of randomly sampling one. This mainly
> >> breaks forward secrecy, which is certainly bad. But hybrids or not
> >> are not relevant to this. In the classic approach they simply fixed
> >> the DH public key of the server, iirc. Friends don't let friends use
> >> ETS.
> >>>
> >>> Cheers,
> >>>
> >>> Thom
> >>>
> >>> Op 8 jul 2026, om 11:35 heeft Eliot Lear
> >>> <[email protected]<mailto:[email protected]>>
> >> het volgende geschreven:
> >>>
> >>>
> >>> Hi!
> >>>
> >>> ~~~~Disclaimer I'm not a cryptographer. ~~~~
> >>>
> >>> Please see below. On 08.07.2026 08:04, Viktor Dukhovni wrote:
> >>>
> >>> On Tue, Jul 07, 2026 at 10:27:56PM -0700, Christian Huitema
> >>> wrote:
> >>>
> >>>
> >>>
> >>> I just read Jacob Applebaum's message. Given his description of the
> >>>
> >>> late-standardization suspicious change that looks like a backdoor in
> >>> the
> >>>
> >>> ML-KEM specification, I agree with his conclusion. The WG should not
> >>> ask for
> >>>
> >>> publication of the current graph, not until the changes requested by
> >>> Jacob
> >>>
> >>> are made.
> >>>
> >>> The removal of whitening of the `m` random input to Encaps is not a
> >>>
> >>> plausible backdoor.  If all you have is a broken RNG, you're free to
> >>>
> >>> apply whitening to obtain a new less bad RNG and use that instead.
> >>>
> >>>
> >>>
> >>> Nothing stops an ML-KEM implementation from hashing some input (any
> >>>
> >>> number of times, mixing in whatever additional inputs, ...) to
> >>> produce
> >>>
> >>> its random values.  The abstract algorithm starts from the final
> >>> output
> >>>
> >>> of an adequate RNG that requires no further post-processing.
> >>>
> >>>
> >>>
> >>> There's nothing suspicious about this simplification.  The critique
> >>> in
> >>>
> >>> question makes no sense to me.  Don't use a broken RNG.
> >>>
> >>>
> >>> That sounds about right to me, but as someone who is not a
> >>> cryptographer,
> >> perhaps someone who is could explain how this amounts to a back door,
> >> and not a requirement for a good PRNG?  And if it's not a back door,
> >> should we really relitigate NIST's choices here?
> >>>
> >>> Eliot
> >>>
> >>> * By "back door", I mean an intentionally placed undisclosed
> >>> weakness that
> >> could be exploited by the people who placed it there.
> >>>
> >>>
> >>>
> >>
> <OpenPGP_0x87B66B46D9D27A33.asc>_______________________________
> >> _______
> >>> _________ TLS mailing list -- [email protected]<mailto:[email protected]> To
> >>> unsubscribe send an email to [email protected]<mailto:tls-
> >>> [email protected]>
> >>>
> >>>
> >>>
> >>> _______________________________________________ TLS mailing list
> >>> -- [email protected] To unsubscribe send an email to tls- [email protected]
> >

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]