MIME-Version: 1.0
References: 
 <174184001345.838119.1665635750501653391@dt-datatracker-775fc5cbb8-824tp>
 <6BB43AEB-CF42-4FE2-998A-DB85B373D464@proper.com>
In-Reply-To: <6BB43AEB-CF42-4FE2-998A-DB85B373D464@proper.com>
From: Joseph Salowey <joe@salowey.net>
Date: Mon, 17 Mar 2025 17:40:22 +0700
Message-ID: 
 <CAOgPGoBg33o7N95PSue3KMwaOz=DcaP7tnNenX=WYQ_jitAyYw@mail.gmail.com>
To: Paul Hoffman <phoffman@proper.com>
Content-Type: multipart/alternative; boundary="000000000000fc4a0f0630876a06"
Message-ID-Hash: 2L66YVYO5UN3SHCHT2NJD2ZWI3AMPGJP
CC: last-call@ietf.org, draft-ietf-tls-rfc8447bis@ietf.org,
 paul.wouters@aiven.io, tls-chairs@ietf.org, tls@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BTLS=5D_Re=3A_Last_Call=3A_=3Cdraft-ietf-tls-rfc8447bis-11=2Etxt?=
 =?utf-8?q?=3E_=28IANA_Registry_Updates_for_TLS_and_DTLS=29_to_Proposed_Stan?=
 =?utf-8?q?dard?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/tls/Do2vtiWqFk4iAhLpwR-UxJT21RQ>

--000000000000fc4a0f0630876a06
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Paul,

The draft already contains the following guidance to address this point on
how to treat items marked as "D":

"D: Indicates that the item is discouraged. This marking could be used to
identify mechanisms that might result in problems if they are used, such as
a weak cryptographic algorithm or a mechanism that might cause
interoperability problems in deployment. Implementers SHOULD consult the
linked references associated with the item to determine the conditions
under which it SHOULD NOT or MUST NOT be used."

The behavior of TLS when it cannot arrive on an acceptable set of
parameters is defined in the TLS protocol specification.

Cheers,

Joe



On Fri, Mar 14, 2025 at 1:59=E2=80=AFAM Paul Hoffman <phoffman@proper.com> =
wrote:

> Greetings again. The contents of this draft are fine but definitely
> incomplete. The draft gives clear language about whether particular
> cryptographic components are recommended for use in TLS, but no guidance
> for implementations of what those implementations should do if given a
> discouraged code point.
>
> If a TLS server negotiates to a cryptographic component labelled "D". wha=
t
> SHOULD / MUST the client do?
>
> If a TLS client only offers D-level components, what SHOULD / MUST the
> server do?
>
> A program's configuration mechanism SHOULD NOT / MUST NOT allow specifyin=
g
> D-level components?
>
> This draft should either be expanded to say what TLS clients and servers
> and configuration SHOULD / MUST do with D-level components. If it is too
> difficult for the TLS WG to agree on specific actions, the draft should a=
t
> least say that so that the reader knows what to do with these new ratings=
.
> Without such wording, the new "D" label becomes useless in practice, whic=
h
> is clearly bad for security and interoperability.
>
> --Paul Hoffman
>

--000000000000fc4a0f0630876a06
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Paul,</div><div><br></div><div>The draft already c=
ontains the following guidance=C2=A0to address this point on how to treat i=
tems marked as &quot;D&quot;:</div><div><br></div><div>&quot;D: Indicates t=
hat the item is discouraged. This marking could be used to identify mechani=
sms that might result in problems if they are used, such as a weak cryptogr=
aphic algorithm or a mechanism that might cause interoperability problems i=
n deployment. Implementers SHOULD consult the linked references associated =
with the item to determine the conditions under which it SHOULD NOT or MUST=
 NOT be used.&quot;</div><div><br></div><div>The behavior of TLS when it ca=
nnot arrive on an acceptable set of parameters is defined in the TLS protoc=
ol specification.=C2=A0</div><div><br></div><div>Cheers,</div><div><br></di=
v><div>Joe</div><div><br></div><br><br><div class=3D"gmail_quote gmail_quot=
e_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 14, 2025 at =
1:59=E2=80=AFAM Paul Hoffman &lt;<a href=3D"mailto:phoffman@proper.com">pho=
ffman@proper.com</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);pa=
dding-left:1ex">Greetings again. The contents of this draft are fine but de=
finitely incomplete. The draft gives clear language about whether particula=
r cryptographic components are recommended for use in TLS, but no guidance =
for implementations of what those implementations should do if given a disc=
ouraged code point.<br>
<br>
If a TLS server negotiates to a cryptographic component labelled &quot;D&qu=
ot;. what SHOULD / MUST the client do?<br>
<br>
If a TLS client only offers D-level components, what SHOULD / MUST the serv=
er do?<br>
<br>
A program&#39;s configuration mechanism SHOULD NOT / MUST NOT allow specify=
ing D-level components?<br>
<br>
This draft should either be expanded to say what TLS clients and servers an=
d configuration SHOULD / MUST do with D-level components. If it is too diff=
icult for the TLS WG to agree on specific actions, the draft should at leas=
t say that so that the reader knows what to do with these new ratings. With=
out such wording, the new &quot;D&quot; label becomes useless in practice, =
which is clearly bad for security and interoperability.<br>
<br>
--Paul Hoffman<br>
</blockquote></div></div>

--000000000000fc4a0f0630876a06--