Subject: Re: [TLS] Moving SHA-1 signature schemes to not recommended in draft-ietf-tls-md5-sha1-deprecate

From: Sean Turner <[email-masked]>
Date: Fri, 18 Sep 2020 10:28:23 -0400

Rich,

Just to close the loop on this, there are three values: Y, N, and blank. I tend to think we should mark is as “N”:

   If an item is not marked as "Recommended" (i.e., "N"), it does not
   necessarily mean that it is flawed; rather, it indicates that the
   item either has not been through the IETF consensus process, has
   limited applicability, or is intended only for specific use cases.

That specific use case is two servers talking an old version to each other in whatever setting they are being used in.

Also, should we be adding “_legacy” to the names of the code points as was done for rsa_pkcs1_sha256_legacy by:
https://www.ietf.org/archive/id/draft-davidben-tls13-pkcs1-00.txt?

spt

> On Jun 25, 2020, at 08:35, Salz, Rich <rsalz=[email-masked]> wrote:
> 
> 	• I submitted a PR [1] for draft-ietf-tls-md5-sha1-deprecate to move the recommended IANA registry entries for  rsa_pkcs1_sha1 and ecdsa_sha1 in the Signature Scheme registry from Y to N.   This change can be incorporated with any updates from the AD review.  
>  
> Yes yes yes.
>  
> Or no no no?
>  
> I think it is remove the “Y” and leave blank, right?
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: David Benjamin <[email-masked]>
Date: Fri, 18 Sep 2020 10:49:07 -0400

> https://www.ietf.org/archive/id/draft-davidben-tls13-pkcs1-00.txt?

My inclination is no. We didn't go about renaming the huge mess of TLS
cipher suites or anything else that I remember.

The "_legacy" suffix in that draft has a slightly different meaning
(perhaps I should have picked a different name). The existing
rsa_pkcs1_sha256 code points from TLS 1.2 were carried over into TLS 1.3
but with a subsetted meaning. In TLS 1.2, rsa_pkcs1_sha256 advertises both
TLS and X.509 capabilities, but in TLS 1.3 it advertises only X.509
capabilities. rsa_pkcs1_sha256 is undefined for a TLS CertificateVerify
because we took PKCS#1 v1.5 out. So, in order for TLS 1.3 servers to opt
into accepting PKCS#1 v1.5 signatures in CertificateVerify, the draft
needed to define new code points with a CertificateVerify capability.

rsa_pkcs1_sha256_tls1_3_certificate_verify_for_legacy_clients was a
mouthful, so I just added a "legacy" suffix. :-)

David

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 18 Sep 2020 15:50:11 +0000

Okay, I am find with the Y->N change.  Nick, Yoav?