MIME-Version: 1.0
References: 
 <PH0PR07MB9683AED41B66451E26CBC84AD024A@PH0PR07MB9683.namprd07.prod.outlook.com>
In-Reply-To: 
 <PH0PR07MB9683AED41B66451E26CBC84AD024A@PH0PR07MB9683.namprd07.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 24 Aug 2025 13:51:18 -0700
Message-ID: 
 <CABcZeBP1hh_1ZRMAa08-JX164UDVy8jon0nqopDnToL98Pv67Q@mail.gmail.com>
To: ma bing <bingmatv@outlook.com>
Content-Type: multipart/alternative; boundary="000000000000e7792e063d229bdd"
Message-ID-Hash: DRFSEQUEAUNXBU52K4NJSYC72IBDRVUA
CC: "tls@ietf.org" <tls@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BTLS=5D_Re=3A_Concerns_about_the_current_draft=2E?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/tls/DP3Wc-DW7Ncl8__QUGTRAlbtKsU>

--000000000000e7792e063d229bdd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 24, 2025 at 1:35=E2=80=AFPM ma bing <bingmatv@outlook.com> wrot=
e:

> Some websites including Google is using the experimental ECC+Kyber hybrid
> solution, but Google and others  still use AES-128, quantum computer can
> weaken 128-bit symmetric encryption to 64-bit security, it's the 1st
> concern. So the draft should only use AES-256.
>


I assume "the draft" you are referring to is:
https://www.ietf.org/archive/id/draft-ietf-tls-ecdhe-mlkem-00.html?

Assuming so, this draft doesn't use either AES-128 or AES-256. In TLS 1.3,
negotiation of
key establishment algorithms is orthogonal to negotiation of symmetric
cipher suites.
I know opinions differ on whether in fact it's important to use 256-bit
symmetric
algorithms to defend against CRQCs (see
https://www.ietf.org/archive/id/draft-ietf-pquip-pqc-engineers-13.html#name=
-symmetric-cryptography
for a contrary position) but in any case it's irrelevant for this draft.





> And NSA suggests 1024-dimensional MLKEM, the 2nd concern is that Google
> and others use MLKEM768.
>

This draft specifies both MLKEM-768 and MLKEM-1024. NSA requires MLKEM-1024
for
National Security Systems, but I don't think that should lead us to the
concludion that
MLKEM-768 should never be used. For example, RFC 9151 specifies the CNSA
profile for TLS (for traditional algorithms) and requires P-384, but
commercially
P-256 and X25519 are far more common.



> The 3rd concern is that the draft uses ECC in addition to Kyber. NIST has
> approved HQC (Hamming Quasi-Cyclic) in addition to the already approved
> ciphers, I suggest to switch from ECC+Kyber to HQC+Kyber; Since ECC is
> vulnerable to quantum computer, using ECC+Kyber is likely a false positiv=
e,
> so I think HQC+Kyber is better. In conclusion, I think there are 3 concer=
ns.
>

The rationale for this design is to have an algorithm that we have high
confidence
in in the setting where a CRQC is not available and combine it with an
algorithm
that we have less overall confidence in but that is designed to be
quantum-resistant.
That way if the newer PQ algorithm is broken in some other way than the
development
of a CRQC, we have had no loss of security. Substituting HQC for ECC would
not
achieve this objective.

-Ekr

--000000000000e7792e063d229bdd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Aug 24,=
 2025 at 1:35=E2=80=AFPM ma bing &lt;<a href=3D"mailto:bingmatv@outlook.com=
">bingmatv@outlook.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">



<div><div>Some websites including Google is using the experimental ECC+Kybe=
r hybrid solution, but Google and others=C2=A0 still use AES-128, quantum c=
omputer can weaken 128-bit symmetric encryption to 64-bit security, it&#39;=
s the 1st concern. So the draft should only use
 AES-256. </div></div></blockquote><div><br></div><div><div><br></div><div>=
I assume &quot;the draft&quot; you are referring to is:</div><div><a href=
=3D"https://www.ietf.org/archive/id/draft-ietf-tls-ecdhe-mlkem-00.html">htt=
ps://www.ietf.org/archive/id/draft-ietf-tls-ecdhe-mlkem-00.html</a>?</div><=
div><br></div><div>Assuming so, this draft doesn&#39;t use either AES-128 o=
r AES-256. In TLS 1.3, negotiation of</div><div>key establishment algorithm=
s is orthogonal to negotiation of symmetric cipher suites.</div><div>I know=
 opinions differ on whether in fact it&#39;s important to use 256-bit symme=
tric</div><div>algorithms
 to defend against CRQCs=20
(see=C2=A0<a href=3D"https://www.ietf.org/archive/id/draft-ietf-pquip-pqc-e=
ngineers-13.html#name-symmetric-cryptography">https://www.ietf.org/archive/=
id/draft-ietf-pquip-pqc-engineers-13.html#name-symmetric-cryptography</a></=
div><div>for a contrary position) but in any case it&#39;s irrelevant for t=
his draft.</div><div><br><br></div><br></div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div><div>And NSA suggests 1024-dimens=
ional MLKEM, the 2nd concern is that Google and others use MLKEM768.</div><=
/div></blockquote><div><br></div><div>This draft specifies both MLKEM-768 a=
nd MLKEM-1024.=C2=A0NSA requires MLKEM-1024 for</div><div>National Security=
 Systems, but I don&#39;t think that should lead us to the concludion that<=
/div><div>MLKEM-768 should never be used. For example, RFC 9151 specifies t=
he CNSA</div><div>profile for TLS (for traditional algorithms) and requires=
 P-384, but commercially</div><div>P-256 and X25519 are far more common.</d=
iv><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div><div> The 3rd concern is that the draft uses ECC in additio=
n to Kyber. NIST has approved HQC (Hamming Quasi-Cyclic) in addition to the=
 already approved ciphers,
 I suggest to switch from ECC+Kyber to HQC+Kyber; Since ECC is vulnerable t=
o quantum computer, using ECC+Kyber is likely a false positive, so I think =
HQC+Kyber is better. In conclusion, I think there are 3 concerns.</div></di=
v></blockquote><div><br></div>The rationale for this design is to have an a=
lgorithm that we have high confidence</div><div class=3D"gmail_quote gmail_=
quote_container">in in the setting where a CRQC is not available and combin=
e it with an algorithm</div><div class=3D"gmail_quote gmail_quote_container=
">that we have less overall confidence in but that is designed to be quantu=
m-resistant.</div><div class=3D"gmail_quote gmail_quote_container">That way=
 if the newer PQ algorithm is broken in some other way than the development=
</div><div class=3D"gmail_quote gmail_quote_container">of a CRQC, we have h=
ad no loss of security. Substituting HQC for ECC would not</div><div class=
=3D"gmail_quote gmail_quote_container">achieve this objective.</div><div cl=
ass=3D"gmail_quote gmail_quote_container"><br></div><div class=3D"gmail_quo=
te gmail_quote_container">-Ekr</div><div class=3D"gmail_quote gmail_quote_c=
ontainer"><br></div></div>

--000000000000e7792e063d229bdd--