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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
