On Fri, Nov 22, 2019 at 08:18:47PM +0100, Hubert Kario wrote: > On Friday, 22 November 2019 03:25:24 CET, David Benjamin wrote: > > On Fri, Nov 22, 2019 at 8:35 AM Salz, Rich <rs...@akamai.com> wrote: > > > > > > ... > > > SHA-1 signature hashes in TLS 1.2" draft available > > > https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/. > > > Please review the document and send your comments to the list by 2359 UTC > > > on 13 December 2019. > > > > > > I just re-read this. Looks good. Perhaps a sentence of rationale in ... > > > > To that end, the combination of client advice in sections 2 and 4 is a bit > > odd. Section 2 uses SHOULD NOT include MD5 and SHA-1, but section 4 says > > the client MUST NOT accept the MD5 SHA-1, even if it included it. Why would > > the client include it in that case? It seems the two should either both be > > MUST NOT or both be SHOULD NOT. > > because it also influences certificate selection, and getting a certificate > signed with SHA-1 isn't an automatically disqualifying property? > (it may be an intermediate CA that's not used, it may be an explicitly > trusted > certificate, etc.)
If you don't want SHA-1 exchange signatures, you darn sure do not want actual SHA-1 certificates that are not trust anchors anyway. And because TLS 1.2 does not have separate lists for exchange signatures and certificate signatures, the client needs to withdraw advertisment for both in order to not send a misleading offer. And I expect that in practice, not sending SHA-1 in signature_algorithms would cause very little breakage on top of what is already broken due to using SHA-1 exchange signatures. So I think both should be MUST NOT. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
