Feedback-ID: i6d3949ed:Fastmail
Content-Type: multipart/alternative;
 boundary=Apple-Mail-A1F5B425-DA9D-45F5-B3CD-0E198C083311
Content-Transfer-Encoding: 7bit
From: Nadim Kobeissi <nadim@symbolic.software>
Mime-Version: 1.0 (1.0)
Date: Thu, 16 Jul 2026 18:36:59 +0300
Message-Id: <D1B94A2E-895E-4D13-8F2F-B3CBAC273768@symbolic.software>
References: 
 <MN2PR17MB40318B05CDD3267E73EC2E82CDC72@MN2PR17MB4031.namprd17.prod.outlook.com>
In-Reply-To: 
 <MN2PR17MB40318B05CDD3267E73EC2E82CDC72@MN2PR17MB4031.namprd17.prod.outlook.com>
To: Rich Salz <rsalz@akamai.com>
Message-ID-Hash: LWRDYE3SMFKAJWO7PE4ZUQTJ3L5RRL3D
CC: tls@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BTLS=5D_Re=3A_WG_Last_Call=3A_draft-ietf-tls-mlkem-08_=28Ends_20?=
	=?utf-8?q?26-07-08=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/tls/rRnW5vOsJMX3rwOmL6wsuYSQkSg>


--Apple-Mail-A1F5B425-DA9D-45F5-B3CD-0E198C083311
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

You misunderstood the quoting in my reply I think.

Nadim Kobeissi
Symbolic Software =E2=80=A2 https://symbolic.software

> On 16 Jul 2026, at 5:16=E2=80=AFPM, Salz, Rich <rsalz@akamai.com> wrote:
>=20
> =EF=BB=BF
> On 7/16/26, 9:57=E2=80=AFAM, "Salz, Rich" <rsalz=3D40akamai.com@dmarc.ietf=
.org> wrote:
> think it would be better as a separate RFC.  Perhaps collaborate with Don E=
astlake
>=20
> Changing the current drafts is a mistake.=20
>=20
> I received a couple of emails that made me realize I was over-zealous in t=
rimming down.  It was in response to Nadim=E2=80=99s message below.
>=20
> The draft is about using ML-KEM, not about using something based on Kyber.=
 If you want to write about RNG, Don is looking at drafting a successor to 4=
086 so contact him. If you want to write a draft about how to use Kyber, tha=
t=E2=80=99s a separate document.
>=20
> On 7/16/26, 6:41=E2=80=AFAM, "Nadim Kobeissi" <nadim@symbolic.software> wr=
ote:
> Fair enough. Here is a start on a minimal list I think the text needs to
> cover:
>=20
> - cite the third-round Kyber submission;
> - cite FIPS 203 Appendix C, where NIST documents removing `m <- H(m)`;
> - state the FIPS 203 approved-RBG requirement;
> - state that `m` is recovered by the decapsulating peer;
> - recommend restoring Kyber's hashing of `m` as defense in depth against
>  hidden-structure RBG failures;
> - cite Dual_EC_DRBG as the public standardized example.
> - quote the relevant part(s) of FIPS 203 C.1
>=20
> I can turn that into concrete PR text. Before doing that, I would like
> to understand whether the WG is open to text at this level of
> specificity, or whether the only text people are willing to consider is
> a generic RNG sentence. If the generic sentence is the only thing on
> offer, I would request someone else draft it and I am happy to give
> feedback.
>=20
> This is incredibly unreasonable to the point of being disruptive. You are b=
asically demanding that the IETF undermine the entire point of NIST standard=
ization, on top of all your baseless insinuations about personal motivations=
 of those who disagree with you and your unreasonable threat modeling when t=
hinking about the entire question of `m` in ML-KEM and sources of randomness=
.
>=20
> At what point does this become pure concern trolling? I regret even making=
 the effort to catch up on these discussions.
>=20
> Nadim Kobeissi
> Symbolic Software =E2=80=A2 https://symbolic.software
>=20
> On 15 Jul 2026, at 5:25=E2=80=AFAM, Jacob Appelbaum <jacob@appelbaum.net> w=
rote:
>=20
> Hi Paul,
>=20
> On 7/14/26 03:17, Paul Wouters wrote:
> The draft does not define crypto, it normatively references some crypto. I=
t cannot both normatively reference it and modify it to make its own.
>=20
> I do not think that follows and while it does not define the code point,
> it does define how the cryptography is used in TLS including Security
> Considerations. A TLS draft can normatively reference FIPS
> 203 and still explain the relevant assumptions and tradeoffs in Security
> Considerations.
>=20
> FIPS 203 Appendix C itself documents that Kyber originally hashed `m`
> and that NIST removed that step because ML-KEM requires approved
> randomness generation. The TLS draft should say that plainly.
>=20
> Namely, quote the entirety of C.1:
> ```
> C.1 Differences Between CRYSTALS-Kyber and FIPS 203 Initial Pub-
> lic Draft
> =E2=80=A2 In the third-round specification [4], the shared secret key was
> treated as a variable-length
> value whose length depended on how it would be used in the relevant
> application. In this
> specification, the length of the shared secret key is fixed to 256 bits.
> It can be used directly
> in applications as a symmetric key, or symmetric keys can be derived
> from it, as specified
> in Section 3.3.
> =E2=80=A2 The ML-KEM.Encaps and ML-KEM.Decaps algorithms in this specifica=
tion
> use a different
> variant of the Fujisaki-Okamoto transform (see [24, 25]) than the third-
> round specifica-
> tion [4]. Specifically, ML-KEM.Encaps no longer includes a hash of the
> ciphertext in the
> derivation of the shared secret, and ML-KEM.Decaps has been adjusted to
> match this
> change.
> =E2=80=A2 In the third-round specification [4], the initial randomness =F0=
=9D=91=9A in the
> ML-KEM.Encaps algo-
> rithm was first hashed before being used. Specifically, between lines 1
> and 2 in Algorithm
> 20, there was an additional step that performed the operation =F0=9D=91=9A=
 =E2=86=90 =F0=9D=90=BB(=F0=9D=91=9A).
> The purpose
> of this step was to safeguard against the use of flawed randomness
> generation processes.
> As this standard requires the use of NIST-approved randomness
> generation, this step is
> unnecessary and is not performed in ML-KEM.
> =E2=80=A2 This specification includes explicit input checking steps that w=
ere
> not part of the third-round
> specification [4]. For example, ML-KEM.Encaps requires that the byte
> array containing the
> encapsulation key correctly decodes to an array of integers modulo =F0=9D=91=
=9E
> without any modular
> reductions.
> ```
>=20
> Alternatively highlight this part of C.1 from FIPS 203:
> ```
> =E2=80=A2 In the third-round specification [4], the initial randomness =F0=
=9D=91=9A in the
> ML-KEM.Encaps algorithm was first hashed before being used.
> Specifically, between lines 1 and 2 in Algorithm 20, there was an
> additional step that performed the operation =F0=9D=91=9A =E2=86=90 =F0=9D=
=90=BB(=F0=9D=91=9A).
> The purpose of this step was to safeguard against the use of flawed
> randomness generation processes.
> As this standard requires the use of NIST-approved randomness
> generation, this step is unnecessary and is not performed in ML-KEM.
> ```
>=20
> Then I would suggest describing the total set of requirements from
> FIPS203 or giving advice that `=F0=9D=91=9A =E2=86=90 =F0=9D=90=BB(=F0=9D=91=
=9A)` should be used if the NIST-
> approved randomness generation requirement is not met. I would also
> probably want to say that this change by NIST is not robust against a
> failure of their DRBG, nor is it robust against providing an oracle, the
> m-oracle, I suppose which may be queries over TLS and/or used to sample
> the DRBG outputs directly.
>=20
> The IETF cannot modify things that are an external normative reference. ML=
KEM is what NIST defined, not what you are trying to build now.
>=20
> I am not asking the draft to pretend that NIST defined something else. I
> am asking the draft to document the consequence of what NIST defined:
> without the approved-RBG assumption, the rationale for removing Kyber's
> hash over `m` no longer holds.
>=20
> If the draft does not restore `m <- H(m)`, then it should at least state
> the FIPS 203 approved-RBG requirement and the fact that `m` is recovered
> by the decapsulating peer.
>=20
> This matters in practice. Many implementations will use `os.urandom`,
> `/dev/urandom`, `/dev/random`, `/dev/hwrng`, `getentropy()`,
> `getrandom()`, or another platform or library interface. Those may be
> excellent choices in a well-designed system, but they are not
> automatically the same thing as a NIST-approved RBG satisfying the FIPS
> 203 condition used to justify removing the hash.
>=20
> One way to make the dependency clear is to think of the real requirement
> as something closer to:
>=20
> - ML-KEM-512-Hash_DRBG
> - ML-KEM-512-HMAC_DRBG
> - ML-KEM-512-CTR_DRBG
> - ML-KEM-768-Hash_DRBG
> - ML-KEM-768-HMAC_DRBG
> - ML-KEM-768-CTR_DRBG
> - ML-KEM-1024-Hash_DRBG
> - ML-KEM-1024-HMAC_DRBG
> - ML-KEM-1024-CTR_DRBG
>=20
> Listing that is a concrete suggestion for the text but I do not feel
> strongly about where it goes in the text.
>=20
> These are shorthand examples names and I am not suggesting new algorithm
> names. The point is that FIPS 203 relies on an approved RBG of
> appropriate strength. If an implementation omits that part, the reason
> NIST gave for removing Kyber's hash over `m` no longer applies.
>=20
> This answer circles the answer by not distinguishing between the RNG issue=
 and any other issues. You still did not answer the question.
>=20
> My answer is: not as-is.
>=20
> I am open to text that is applied consistently to both ML-KEM drafts.
> But a generic sentence about "use a good RNG" does not address the
> specific FIPS 203 requirement, nor the protocol consequence that `m` is
> recovered by the decapsulating peer.
>=20
> This does answer it better, it seems your answer is "no".
>=20
> No. My answer is not "no no matter what." My answer is "not as-is"
> because your suggestion is not even a full suggestion where I could just
> say yes.
>=20
> Which is the same issue as the "m concern".
>=20
> Related, not identical. The approved-RBG dependency is the assumption
> and a requirement. The `m` concern is the protocol consequence when that
> assumption is not met, or when it is hidden from implementers.
>=20
> For one, this is not different between pure and hybrid, yet you have no is=
sue with the hybrid Security Considerations?
>=20
> I do have an issue with the hybrid draft on this point. The same
> Appendix C tradeoff and the same `m` issue apply there too. Hybrid helps
> against some failures, but it does not automatically help if the same
> recoverable RBG lineage later feeds the classical ephemeral scalar. The
> removal of the hash leads to some fun issues and not only with
> Dual_EC_DRBG but also.
>=20
> Second, it seems as people said, TLS already provides a huge amount of opt=
ions and parameters to use as a covert channel.
>=20
> Agreed. That is why broader covert-channel work is also needed. But that
> does not justify leaving this specific ML-KEM issue unexplained in these
> drafts. It is a bit annoying to go back and forth between each layer
> where a different layer is used as a reason to ignore the issues in the
> layer under discussion.
>=20
> What would a TLS implementer need to know when it uses a cryptographic lib=
rary to support a new cipher, whether hybrid or pure?
>=20
> They need to know at least:
>=20
> 1. FIPS 203 requires ML-KEM randomness from a NIST-approved RBG.
> 2. `m` is recovered by the decapsulating peer.
> 3. Kyber originally hashed `m` to protect against flawed randomness.
> 4. Dual_EC_DRBG is the public standardized example of a
>   hidden-structure RBG failure.
> 5. Hybrid does not automatically help if the same recovered RBG lineage
>   later feeds the classical ephemeral scalar.
> 6. This change was an intentional choice by NIST and the IETF does not
> agree with this change as it cannot mandiate the use of a specific DRBG.
>=20
> First, it seems most of the items you just listed are the same item, and b=
asically you want it to say "don't use pure, use hybrid instead",
>=20
> That is not my position. The `m` issue applies to ML-KEM in both the
> standalone and hybrid drafts. My concern is that the drafts do not
> clearly state the FIPS 203 randomness requirement, the Appendix C
> tradeoff, or the peer-recoverability of `m`.
>=20
> Second, if you want this document to proceed with some newly added text, i=
t is up to you to propose such text to the WG.
>=20
> Fair enough. Here is a start on a minimal list I think the text needs to
> cover:
>=20
> - cite the third-round Kyber submission;
> - cite FIPS 203 Appendix C, where NIST documents removing `m <- H(m)`;
> - state the FIPS 203 approved-RBG requirement;
> - state that `m` is recovered by the decapsulating peer;
> - recommend restoring Kyber's hashing of `m` as defense in depth against
>  hidden-structure RBG failures;
> - cite Dual_EC_DRBG as the public standardized example.
> - quote the relevant part(s) of FIPS 203 C.1
>=20
> I can turn that into concrete PR text. Before doing that, I would like
> to understand whether the WG is open to text at this level of
> specificity, or whether the only text people are willing to consider is
> a generic RNG sentence. If the generic sentence is the only thing on
> offer, I would request someone else draft it and I am happy to give
> feedback.
>=20
> So "pure" is what the IETF is using now for consistency.
>=20
> Point of clarification: did you mean ML-KEM or ML-KEM-WITH-A-DRBG when
> you said pure in that context?
>=20
> The current text is the consensus proposal of two years of talk within the=
 TLS WG.
>=20
> The WGLC for draft-ietf-tls-mlkem-08 has ended, but I have not seen a
> declaration of consensus. We also do not yet have agreed text that
> addresses the FIPS 203 randomness requirement or Appendix C tradeoff.
>=20
> I am not aware of any technical concerns.
>=20
> Then let us test that with concrete text. The concern is not merely a
> different risk preference. It is that NIST's rationale for removing
> Kyber's hash depends on an approved-RBG requirement that the TLS draft
> does not clearly carry forward.
>=20
> So to me that makes it clear that in practise, your answer will remain "no=
".
>=20
> No. If the drafts clearly document the FIPS 203 approved-RBG assumption,
> the peer-recoverability of `m`, and the reason Kyber hashed `m`, I am
> open to changing my view. If the text is only "use a good RNG", then no,
> that is not enough.
>=20
> As I explained above, you providing concrete text additions/ modifications=
 will help determine consensus of your suggestions
>=20
> I take that point. I can provide concrete text. My concern is that the
> Last Call has already closed, so I am asking how the chairs intend to
> handle new text if there is support for it.
>=20
> Rough consensus is achieved when all issues are addressed, but not necessa=
rily accommodated.
>=20
> Agreed. My position is that the issue has not yet been addressed. It has
> mostly been reframed as a generic RNG problem, which misses the specific
> Appendix C tradeoff and the `m` oracle.
>=20
> The one thing that is clear to me is that what you are asking for is basic=
ally changing the normative reference.
>=20
> I reject that framing. Security Considerations routinely explain
> assumptions, risks, and implementation guidance around normative
> references. That is what I am asking for here.
>=20
> The normative reference itself discusses Kyber and ML-KEM together in
> Appendix C. Quoting and explaining that text is not changing the
> normative reference. It is making the reference intelligible to TLS
> implementers.
>=20
> Adding a generic statement about RNG is the only compromise possible.
>=20
> I do not agree. A meaningful compromise would state the actual FIPS 203
> approved-RBG requirement, state that `m` is recovered by the
> decapsulating peer, and explain that Kyber originally hashed `m` to
> protect against flawed randomness.
>=20
> If that is not good enough for you, your only option is to voice that you a=
re against publication -
>=20
> That is not my only option. I am currently against publication as-is,
> but I am also trying to find text that could resolve the issue.
>=20
> and to be consistent, I would expect you to be against publication of both=
 the pure and hybrid mlkem drafts, as they are identical in that part, using=
 the same normative reference of NIST.
>=20
> I am against omitting the relevant FIPS 203 Appendix C details in both
> drafts. I am against omitting advice to implementers who are not running
> a FIPS-validated stack. I am against omitting the fact that `m` is
> available to the decapsulating peer. And I am against omitting the
> historical example of Dual_EC_DRBG when discussing hidden-structure RBG
> failures.
>=20
> A suggestion of generic RNG sentence that is not a concrete suggestion
> is not enough, no. Text that states the FIPS 203 approved-RBG
> requirement, the peer-recoverability of `m`, and the reason Kyber hashed
> `m` would be meaningful.
>=20
> Kind regards,
> Jacob Appelbaum
>=20
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>=20

--Apple-Mail-A1F5B425-DA9D-45F5-B3CD-0E198C083311
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html class=3D"apple-mail-supports-explicit-dark-mode"><head><meta http-equi=
v=3D"content-type" content=3D"text/html; charset=3Dutf-8"></head><body dir=3D=
"auto">You misunderstood the quoting in my reply I think.<br id=3D"lineBreak=
AtBeginningOfSignature"><div dir=3D"ltr"><br><div>Nadim Kobeissi</div><div>S=
ymbolic Software =E2=80=A2 https://symbolic.software</div></div><div dir=3D"=
ltr"><br><blockquote type=3D"cite">On 16 Jul 2026, at 5:16=E2=80=AFPM, Salz,=
 Rich &lt;rsalz@akamai.com&gt; wrote:<br><br></blockquote></div><blockquote t=
ype=3D"cite"><div dir=3D"ltr">=EF=BB=BF

<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">


<div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-ser=
if; font-size: 12pt; color: rgb(0, 0, 0);">
On 7/16/26, 9:57=E2=80=AFAM, "Salz, Rich" &lt;rsalz=3D40akamai.com@dmarc.iet=
f.org&gt; wrote:</div>
<ul data-editing-info=3D"{&quot;applyListStyleFromLevel&quot;:false,&quot;un=
orderedStyleType&quot;:4}" style=3D"direction: ltr; margin-top: 0px; margin-=
bottom: 0px;">
<li style=3D"font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12=
pt; color: rgb(0, 0, 0); direction: ltr; margin-top: 0px; margin-bottom: 0px=
; list-style-type: &quot;=E2=9E=A2 &quot;;">
<div role=3D"presentation" style=3D"direction: ltr;">think it would be bette=
r as a separate RFC. &nbsp;Perhaps collaborate with Don Eastlake</div>
</li></ul>
<div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-ser=
if; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<ul data-editing-info=3D"{&quot;applyListStyleFromLevel&quot;:false,&quot;un=
orderedStyleType&quot;:4}" style=3D"direction: ltr; margin-top: 0px; margin-=
bottom: 0px;">
<li style=3D"font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12=
pt; color: rgb(0, 0, 0); direction: ltr; margin-top: 0px; margin-bottom: 0px=
; list-style-type: &quot;=E2=9E=A2 &quot;;">
<div role=3D"presentation" style=3D"direction: ltr;">Changing the current dr=
afts is a mistake.&nbsp;</div>
</li></ul>
<div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-ser=
if; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-ser=
if; font-size: 12pt; color: rgb(0, 0, 0);">
I received a couple of emails that made me realize I was over-zealous in tri=
mming down. &nbsp;It was in response to Nadim=E2=80=99s message below.</div>=

<div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-ser=
if; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-ser=
if; font-size: 12pt; color: rgb(0, 0, 0);">
The draft is about using ML-KEM, not about using something based on Kyber. I=
f you want to write about RNG, Don is looking at drafting a successor to 408=
6 so contact him. If you want to write a draft about how to use Kyber, that=E2=
=80=99s a separate document.</div>
<div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-ser=
if; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id=3D"mail-editor-reference-message-container">
<div class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"dir=
ection: ltr;">
</div>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">On 7/16/26, 6=
:41=E2=80=AFAM, "Nadim Kobeissi" &lt;nadim@symbolic.software&gt; wrote:</div=
>
<div class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"dir=
ection: ltr;">
Fair enough. Here is a start on a minimal list I think the text needs to<br>=

cover:<br>
<br>
- cite the third-round Kyber submission;<br>
- cite FIPS 203 Appendix C, where NIST documents removing `m &lt;- H(m)`;<br=
>
- state the FIPS 203 approved-RBG requirement;<br>
- state that `m` is recovered by the decapsulating peer;<br>
- recommend restoring Kyber's hashing of `m` as defense in depth against<br>=

&nbsp;hidden-structure RBG failures;<br>
- cite Dual_EC_DRBG as the public standardized example.<br>
- quote the relevant part(s) of FIPS 203 C.1<br>
<br>
I can turn that into concrete PR text. Before doing that, I would like<br>
to understand whether the WG is open to text at this level of<br>
specificity, or whether the only text people are willing to consider is<br>
a generic RNG sentence. If the generic sentence is the only thing on<br>
offer, I would request someone else draft it and I am happy to give<br>
feedback.</div>
<div class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"dir=
ection: ltr;">
<br>
</div>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">This is incr=
edibly unreasonable to the point of being disruptive. You are basically dema=
nding that the IETF undermine the entire point of NIST standardization, on t=
op of all your baseless insinuations
 about personal motivations of those who disagree with you and your unreason=
able threat modeling when thinking about the entire question of `m` in ML-KE=
M and sources of randomness.</div>
<div class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"dir=
ection: ltr;">
<br>
</div>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">At what poin=
t does this become pure concern trolling? I regret even making the effort to=
 catch up on these discussions.</div>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
Nadim Kobeissi<br>
Symbolic Software =E2=80=A2&nbsp;https://symbolic.software</div>
<div class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"dir=
ection: ltr;">
<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">On 15 Jul 20=
26, at 5:25=E2=80=AFAM, Jacob Appelbaum &lt;jacob@appelbaum.net&gt; wrote:</=
div>
<div class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"dir=
ection: ltr;">
<br>
</div>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">Hi Paul,<br>=

<br>
On 7/14/26 03:17, Paul Wouters wrote:</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">The draft do=
es not define crypto, it normatively references some crypto. It cannot both n=
ormatively reference it and modify it to make its own.</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
I do not think that follows and while it does not define the code point,<br>=

it does define how the cryptography is used in TLS including Security<br>
Considerations. A TLS draft can normatively reference FIPS<br>
203 and still explain the relevant assumptions and tradeoffs in Security<br>=

Considerations.<br>
<br>
FIPS 203 Appendix C itself documents that Kyber originally hashed `m`<br>
and that NIST removed that step because ML-KEM requires approved<br>
randomness generation. The TLS draft should say that plainly.<br>
<br>
Namely, quote the entirety of C.1:<br>
```<br>
C.1 Differences Between CRYSTALS-Kyber and FIPS 203 Initial Pub-<br>
lic Draft<br>
=E2=80=A2 In the third-round specification [4], the shared secret key was<br=
>
treated as a variable-length<br>
value whose length depended on how it would be used in the relevant<br>
application. In this<br>
specification, the length of the shared secret key is fixed to 256 bits.<br>=

It can be used directly<br>
in applications as a symmetric key, or symmetric keys can be derived<br>
from it, as specified<br>
in Section 3.3.<br>
=E2=80=A2 The ML-KEM.Encaps and ML-KEM.Decaps algorithms in this specificati=
on<br>
use a different<br>
variant of the Fujisaki-Okamoto transform (see [24, 25]) than the third-<br>=

round specifica-<br>
tion [4]. Specifically, ML-KEM.Encaps no longer includes a hash of the<br>
ciphertext in the<br>
derivation of the shared secret, and ML-KEM.Decaps has been adjusted to<br>
match this<br>
change.<br>
=E2=80=A2 In the third-round specification [4], the initial randomness =F0=9D=
=91=9A in the<br>
ML-KEM.Encaps algo-<br>
rithm was first hashed before being used. Specifically, between lines 1<br>
and 2 in Algorithm<br>
20, there was an additional step that performed the operation =F0=9D=91=9A =E2=
=86=90 =F0=9D=90=BB(=F0=9D=91=9A).<br>
The purpose<br>
of this step was to safeguard against the use of flawed randomness<br>
generation processes.<br>
As this standard requires the use of NIST-approved randomness<br>
generation, this step is<br>
unnecessary and is not performed in ML-KEM.<br>
=E2=80=A2 This specification includes explicit input checking steps that wer=
e<br>
not part of the third-round<br>
specification [4]. For example, ML-KEM.Encaps requires that the byte<br>
array containing the<br>
encapsulation key correctly decodes to an array of integers modulo =F0=9D=91=
=9E<br>
without any modular<br>
reductions.<br>
```<br>
<br>
Alternatively highlight this part of C.1 from FIPS 203:<br>
```<br>
=E2=80=A2 In the third-round specification [4], the initial randomness =F0=9D=
=91=9A in the<br>
ML-KEM.Encaps algorithm was first hashed before being used.<br>
Specifically, between lines 1 and 2 in Algorithm 20, there was an<br>
additional step that performed the operation =F0=9D=91=9A =E2=86=90 =F0=9D=90=
=BB(=F0=9D=91=9A).<br>
The purpose of this step was to safeguard against the use of flawed<br>
randomness generation processes.<br>
As this standard requires the use of NIST-approved randomness<br>
generation, this step is unnecessary and is not performed in ML-KEM.<br>
```<br>
<br>
Then I would suggest describing the total set of requirements from<br>
FIPS203 or giving advice that `=F0=9D=91=9A =E2=86=90 =F0=9D=90=BB(=F0=9D=91=
=9A)` should be used if the NIST-<br>
approved randomness generation requirement is not met. I would also<br>
probably want to say that this change by NIST is not robust against a<br>
failure of their DRBG, nor is it robust against providing an oracle, the<br>=

m-oracle, I suppose which may be queries over TLS and/or used to sample<br>
the DRBG outputs directly.<br>
<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">The IETF can=
not modify things that are an external normative reference. MLKEM is what NI=
ST defined, not what you are trying to build now.</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
I am not asking the draft to pretend that NIST defined something else. I<br>=

am asking the draft to document the consequence of what NIST defined:<br>
without the approved-RBG assumption, the rationale for removing Kyber's<br>
hash over `m` no longer holds.<br>
<br>
If the draft does not restore `m &lt;- H(m)`, then it should at least state<=
br>
the FIPS 203 approved-RBG requirement and the fact that `m` is recovered<br>=

by the decapsulating peer.<br>
<br>
This matters in practice. Many implementations will use `os.urandom`,<br>
`/dev/urandom`, `/dev/random`, `/dev/hwrng`, `getentropy()`,<br>
`getrandom()`, or another platform or library interface. Those may be<br>
excellent choices in a well-designed system, but they are not<br>
automatically the same thing as a NIST-approved RBG satisfying the FIPS<br>
203 condition used to justify removing the hash.<br>
<br>
One way to make the dependency clear is to think of the real requirement<br>=

as something closer to:<br>
<br>
- ML-KEM-512-Hash_DRBG<br>
- ML-KEM-512-HMAC_DRBG<br>
- ML-KEM-512-CTR_DRBG<br>
- ML-KEM-768-Hash_DRBG<br>
- ML-KEM-768-HMAC_DRBG<br>
- ML-KEM-768-CTR_DRBG<br>
- ML-KEM-1024-Hash_DRBG<br>
- ML-KEM-1024-HMAC_DRBG<br>
- ML-KEM-1024-CTR_DRBG<br>
<br>
Listing that is a concrete suggestion for the text but I do not feel<br>
strongly about where it goes in the text.<br>
<br>
These are shorthand examples names and I am not suggesting new algorithm<br>=

names. The point is that FIPS 203 relies on an approved RBG of<br>
appropriate strength. If an implementation omits that part, the reason<br>
NIST gave for removing Kyber's hash over `m` no longer applies.<br>
<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">This answer c=
ircles the answer by not distinguishing between the RNG issue and any other i=
ssues. You still did not answer the question.</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
My answer is: not as-is.<br>
<br>
I am open to text that is applied consistently to both ML-KEM drafts.<br>
But a generic sentence about "use a good RNG" does not address the<br>
specific FIPS 203 requirement, nor the protocol consequence that `m` is<br>
recovered by the decapsulating peer.<br>
<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">This does an=
swer it better, it seems your answer is "no".</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
No. My answer is not "no no matter what." My answer is "not as-is"<br>
because your suggestion is not even a full suggestion where I could just<br>=

say yes.<br>
<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">Which is the=
 same issue as the "m concern".</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
Related, not identical. The approved-RBG dependency is the assumption<br>
and a requirement. The `m` concern is the protocol consequence when that<br>=

assumption is not met, or when it is hidden from implementers.<br>
<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">For one, thi=
s is not different between pure and hybrid, yet you have no issue with the h=
ybrid Security Considerations?</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
I do have an issue with the hybrid draft on this point. The same<br>
Appendix C tradeoff and the same `m` issue apply there too. Hybrid helps<br>=

against some failures, but it does not automatically help if the same<br>
recoverable RBG lineage later feeds the classical ephemeral scalar. The<br>
removal of the hash leads to some fun issues and not only with<br>
Dual_EC_DRBG but also.<br>
<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">Second, it s=
eems as people said, TLS already provides a huge amount of options and param=
eters to use as a covert channel.</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
Agreed. That is why broader covert-channel work is also needed. But that<br>=

does not justify leaving this specific ML-KEM issue unexplained in these<br>=

drafts. It is a bit annoying to go back and forth between each layer<br>
where a different layer is used as a reason to ignore the issues in the<br>
layer under discussion.<br>
<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">What would a=
 TLS implementer need to know when it uses a cryptographic library to suppor=
t a new cipher, whether hybrid or pure?</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
They need to know at least:<br>
<br>
1. FIPS 203 requires ML-KEM randomness from a NIST-approved RBG.<br>
2. `m` is recovered by the decapsulating peer.<br>
3. Kyber originally hashed `m` to protect against flawed randomness.<br>
4. Dual_EC_DRBG is the public standardized example of a<br>
&nbsp;&nbsp;hidden-structure RBG failure.<br>
5. Hybrid does not automatically help if the same recovered RBG lineage<br>
&nbsp;&nbsp;later feeds the classical ephemeral scalar.<br>
6. This change was an intentional choice by NIST and the IETF does not<br>
agree with this change as it cannot mandiate the use of a specific DRBG.<br>=

<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">First, it se=
ems most of the items you just listed are the same item, and basically you w=
ant it to say "don't use pure, use hybrid instead",</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
That is not my position. The `m` issue applies to ML-KEM in both the<br>
standalone and hybrid drafts. My concern is that the drafts do not<br>
clearly state the FIPS 203 randomness requirement, the Appendix C<br>
tradeoff, or the peer-recoverability of `m`.<br>
<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">Second, if y=
ou want this document to proceed with some newly added text, it is up to you=
 to propose such text to the WG.</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
Fair enough. Here is a start on a minimal list I think the text needs to<br>=

cover:<br>
<br>
- cite the third-round Kyber submission;<br>
- cite FIPS 203 Appendix C, where NIST documents removing `m &lt;- H(m)`;<br=
>
- state the FIPS 203 approved-RBG requirement;<br>
- state that `m` is recovered by the decapsulating peer;<br>
- recommend restoring Kyber's hashing of `m` as defense in depth against<br>=

&nbsp;hidden-structure RBG failures;<br>
- cite Dual_EC_DRBG as the public standardized example.<br>
- quote the relevant part(s) of FIPS 203 C.1<br>
<br>
I can turn that into concrete PR text. Before doing that, I would like<br>
to understand whether the WG is open to text at this level of<br>
specificity, or whether the only text people are willing to consider is<br>
a generic RNG sentence. If the generic sentence is the only thing on<br>
offer, I would request someone else draft it and I am happy to give<br>
feedback.<br>
<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">So "pure" is=
 what the IETF is using now for consistency.</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
Point of clarification: did you mean ML-KEM or ML-KEM-WITH-A-DRBG when<br>
you said pure in that context?<br>
<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">The current t=
ext is the consensus proposal of two years of talk within the TLS WG.</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
The WGLC for draft-ietf-tls-mlkem-08 has ended, but I have not seen a<br>
declaration of consensus. We also do not yet have agreed text that<br>
addresses the FIPS 203 randomness requirement or Appendix C tradeoff.<br>
<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">I am not awa=
re of any technical concerns.</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
Then let us test that with concrete text. The concern is not merely a<br>
different risk preference. It is that NIST's rationale for removing<br>
Kyber's hash depends on an approved-RBG requirement that the TLS draft<br>
does not clearly carry forward.<br>
<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">So to me tha=
t makes it clear that in practise, your answer will remain "no".</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
No. If the drafts clearly document the FIPS 203 approved-RBG assumption,<br>=

the peer-recoverability of `m`, and the reason Kyber hashed `m`, I am<br>
open to changing my view. If the text is only "use a good RNG", then no,<br>=

that is not enough.<br>
<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">As I explain=
ed above, you providing concrete text additions/ modifications will help det=
ermine consensus of your suggestions</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
I take that point. I can provide concrete text. My concern is that the<br>
Last Call has already closed, so I am asking how the chairs intend to<br>
handle new text if there is support for it.<br>
<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">Rough consen=
sus is achieved when all issues are addressed, but not necessarily accommoda=
ted.</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
Agreed. My position is that the issue has not yet been addressed. It has<br>=

mostly been reframed as a generic RNG problem, which misses the specific<br>=

Appendix C tradeoff and the `m` oracle.<br>
<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">The one thin=
g that is clear to me is that what you are asking for is basically changing t=
he normative reference.</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
I reject that framing. Security Considerations routinely explain<br>
assumptions, risks, and implementation guidance around normative<br>
references. That is what I am asking for here.<br>
<br>
The normative reference itself discusses Kyber and ML-KEM together in<br>
Appendix C. Quoting and explaining that text is not changing the<br>
normative reference. It is making the reference intelligible to TLS<br>
implementers.<br>
<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">Adding a gen=
eric statement about RNG is the only compromise possible.</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
I do not agree. A meaningful compromise would state the actual FIPS 203<br>
approved-RBG requirement, state that `m` is recovered by the<br>
decapsulating peer, and explain that Kyber originally hashed `m` to<br>
protect against flawed randomness.<br>
<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">If that is n=
ot good enough for you, your only option is to voice that you are against pu=
blication -</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
That is not my only option. I am currently against publication as-is,<br>
but I am also trying to find text that could resolve the issue.<br>
<br>
</div>
<blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">and to be co=
nsistent, I would expect you to be against publication of both the pure and h=
ybrid mlkem drafts, as they are identical in that part, using the same norma=
tive reference of NIST.</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
I am against omitting the relevant FIPS 203 Appendix C details in both<br>
drafts. I am against omitting advice to implementers who are not running<br>=

a FIPS-validated stack. I am against omitting the fact that `m` is<br>
available to the decapsulating peer. And I am against omitting the<br>
historical example of Dual_EC_DRBG when discussing hidden-structure RBG<br>
failures.<br>
<br>
A suggestion of generic RNG sentence that is not a concrete suggestion<br>
is not enough, no. Text that states the FIPS 203 approved-RBG<br>
requirement, the peer-recoverability of `m`, and the reason Kyber hashed<br>=

`m` would be meaningful.<br>
<br>
Kind regards,<br>
Jacob Appelbaum<br>
<br>
_______________________________________________<br>
TLS mailing list -- tls@ietf.org<br>
To unsubscribe send an email to tls-leave@ietf.org</div>
</blockquote>
<div class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"dir=
ection: ltr;">
<br>
</div>
</div>


</div></blockquote></body></html>=

--Apple-Mail-A1F5B425-DA9D-45F5-B3CD-0E198C083311--