On Tue, May 14, 2019 at 2:27 PM Hubert Kario <[email protected]> wrote:
> 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 > > got it, then the text needs to be explicit in each case we should not hide ourselves behind a vague SHOULD. > > 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 > > Works for me. I believe the reasoning worth being mentioning. In addition, the section update of 5246 coudl also emphasis changes are not limited to the NEW text. > 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 > > I had the same question ;-) and of course not the response. I believe that we should clarify this and document the choice for MUST/SHOULD. > -- > 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_______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
