MIME-Version: 1.0
References: 
 <CAMjbhoX3koyy8z9-6dYxDJYTBF7zTQPeC0_i3oBrnyMoZ6OGBg@mail.gmail.com>
In-Reply-To: 
 <CAMjbhoX3koyy8z9-6dYxDJYTBF7zTQPeC0_i3oBrnyMoZ6OGBg@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 9 Jun 2026 09:46:57 -0400
Message-ID: 
 <CAF8qwaBSHQMtQKQjtwwbzWng35BnEjB_b-rAQ+YvyBAStx0Diw@mail.gmail.com>
To: Bas Westerbaan <bas=40cloudflare.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000060292f0653d25d5e"
Message-ID-Hash: PQEZTPU4JQHYQSJIBTNRRISCQO2RRAOB
CC: ckaufman@us.ibm.com, "<tls@ietf.org>" <tls@ietf.org>,
 IETF SecDir <secdir@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5Bsecdir=5D_Re=3A_=5BTLS=5D_Re=3A_Secdir_last_call_review_of_draf?=
	=?utf-8?q?t-ietf-tls-mldsa-03?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/secdir/I2APNf97VYujktlA7ReqkcCIuBE>

--00000000000060292f0653d25d5e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

There is actually a reason to not support these codepoints in TLS 1.2. Or
rather it is not mechanically possible to use these codepoints in TLS 1.2,
due to how TLS 1.2 works, but this fact is probably not obvious to most
readers. (There is no mapping from ML-DSA to TLS 1.2 cipher suites or
ClientCertificateType, which are necessary to use it for the server and
client key, respectively.) Conversely, even though they aren't defined for
use with TLS 1.2, what that means can be non-obvious because a TLS 1.2+1.3
client would still send these, which means a TLS 1.2 server would still see
them (and ignore them) in the ClientHello.

On Tue, Jun 9, 2026 at 7:31=E2=80=AFAM Bas Westerbaan <bas=3D
40cloudflare.com@dmarc.ietf.org> wrote:

> Hi Charlie,
>
> Thanks for the review.
>
>
>> (3) Section 3.3 explicitly says that these algorithms MUST NOT be used i=
n
>> TLS 1.2 or earlier versions. While it's hard to imagine anyone rushing o=
ut
>> to support new algorithms in old protocols, I don't see why it is import=
ant
>> to disallow them, and if they were to support them it would seem
>> appropriate to use these same code points.
>
>
> The normative language is indeed superfluous, certainly
> after draft-ietf-tls-tls12-frozen lands; the comments was put in place to
> be explicit. Martin Thomson and Usama Sardar also would like to see it go=
,
> but otherwise the WG remained silent on the topic. This PR would remove t=
he
> normative language:
>
> https://github.com/tlswg/tls-mldsa/pull/37
>
> Nit:
>> First paragraph of section 3: "as follows as follows" should be "as
>> follows"
>
>
> https://github.com/tlswg/tls-mldsa/pull/38
>
> Thank you,
>
>  Bas
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>

--00000000000060292f0653d25d5e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">There is actually=C2=A0a reason to not support these codep=
oints in TLS 1.2. Or rather it is not mechanically possible to use these co=
depoints in TLS 1.2, due to how TLS 1.2 works, but this fact is probably no=
t obvious to most readers. (There is no mapping from ML-DSA to TLS 1.2 ciph=
er suites or ClientCertificateType, which are necessary to use it for the s=
erver and client key, respectively.) Conversely, even though they aren&#39;=
t defined for use with TLS 1.2, what that means can be non-obvious because =
a TLS 1.2+1.3 client would still send these, which means a TLS 1.2 server w=
ould still see them (and ignore them) in the ClientHello.</div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jun 9, 202=
6 at 7:31=E2=80=AFAM Bas Westerbaan &lt;bas=3D<a href=3D"mailto:40cloudflar=
e.com@dmarc.ietf.org" target=3D"_blank">40cloudflare.com@dmarc.ietf.org</a>=
&gt; wrote:<br></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=
 dir=3D"ltr"><div>Hi Charlie,</div><div><br></div><div>Thanks for the revie=
w.</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">=
(3) Section 3.3 explicitly says that these algorithms MUST NOT be used in T=
LS 1.2 or earlier versions. While it&#39;s hard to imagine anyone rushing o=
ut to support new algorithms in old protocols, I don&#39;t see why it is im=
portant to disallow them, and if they were to support them it would seem ap=
propriate to use these same code points.</blockquote><div><br></div><div>Th=
e normative language is indeed superfluous, certainly after=C2=A0draft-ietf=
-tls-tls12-frozen lands; the comments was put in place to be explicit. Mart=
in Thomson and Usama Sardar also would like to see it go, but otherwise the=
 WG remained silent on the topic. This PR would remove the normative langua=
ge:</div><div><br></div><div><a href=3D"https://github.com/tlswg/tls-mldsa/=
pull/37" target=3D"_blank">https://github.com/tlswg/tls-mldsa/pull/37</a></=
div><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex">Nit:<br>First par=
agraph of section 3: &quot;as follows as follows&quot; should be &quot;as f=
ollows&quot;</blockquote><br><a href=3D"https://github.com/tlswg/tls-mldsa/=
pull/38" target=3D"_blank">https://github.com/tlswg/tls-mldsa/pull/38</a><d=
iv><br></div><div>Thank you,</div><div><br></div><div>=C2=A0Bas<br></div></=
div>
_______________________________________________<br>
TLS mailing list -- <a href=3D"mailto:tls@ietf.org" target=3D"_blank">tls@i=
etf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:tls-leave@ietf.org" targe=
t=3D"_blank">tls-leave@ietf.org</a><br>
</blockquote></div>

--00000000000060292f0653d25d5e--