Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2

[Hubert Kario <[e-mail]>]

On Tuesday, 14 May 2019 20:09:36 CEST Daniel Migault wrote:
> section 2:
> 
> I am wondering whether SHOULD NOT could be replaced by  MUST NOT. On the
> one hand, deprecation should be smooth, but on the other hand I am reading
> that rfc6194 and rfc6151 already started the deprecation. I would rather
> favour MUST NOT.
> 
> Maybe we need to also indicate that MD5 or SHA-1 are ignored by the
> receiver.

that was the intention behind my suggestion for SHOULD NOT - i.e. the server 
MUST be able to handle ClientHello that does advertise them, but in practice 
ignore them based on required handling for SKE and CV
 
> section 3:
> 
> The title section maybe should be Certificate Request (without 's').
> Similarly to the previous section I would suggest MUST NOT and specifying
> how the client would behave upon receiving MD5 or SHA-1 as hash.

same as above
 
> section 6:
> 
> The current rfc5246 rely on default sha-1 and md5. To ease interoperability
> I am wondering if we strongly recommend to provide the signature algorithm
> extension in addition to the default sha256.

no, sha-1 is the default in case the extension is omitted, but then we also 
specify that if the extension is omitted now, the negotiation MUST fail
the recommendation for sha256 is that it in practice has to be included in the 
extension as some servers use the extension to select server certificate, so 
omitting sha256 there will cause the connection to fail

this is also partially the reason for a SHOULD NOT instead of MUST NOT for 
section 2 and 3 – I do not know how those servers handle interaction between 
SHA-1 missing in the extension and root CA (self-signed certificate) being 
signed by SHA-1

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic