On Wed, Oct 21, 2015 at 12:15:25PM -0700, Martin Thomson wrote: > The current draft permits the use of SHA-1 in the certificate chain, > which gives SHA-1 a free pass indefinitely.
Forbidding the sending of SHA-1 chains was wrong last time we discussed this at length, and remains wrong now. Whether SHA-1 in the chain is used to make trust decisions is only known to the client, and the server MUST NOT preempt that by denying the client access to whatever chain it has on hand. Each peer MUST try to send a chain that matches an advertised signature algorithm if it has a choice of chains, but otherwise MUST send whatever it has. > That means that clients that want to disable SHA-1 (real soon now, we > promise), can signal that preference cleanly. The clients can indeed not signal SHA-1 support, and SHOULD avoid trusting SHA-1, but the server MUST still send whatever chain it has and let the client decide. > I've opened PR #317 for this, but the commit is probably more useful > to review, since I built this on top of ekr's client authentication > changes (to avoid messy rebases): > > https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5 The final diff "hunk" is dejavu-all-over-again. This text must stay unchanged. indicated supported pairs, then it SHOULD continue the handshake by sending the client a certificate chain of its choice that may include algorithms that are not known to be supported by the client. This fallback chain MAY -use the deprecated SHA-1 hash algorithm. +use the deprecated SHA-1 hash algorithm only if the "signature_algorithms" +extension provided by the client permits it. If the client cannot construct an acceptable chain using the provided certificates and decides to abort the handshake, then it MUST send an "unsupported_certificate" alert message and close the connection. So, no to the diff above. -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
