On Sunday 11 October 2015 19:13:03 Dave Garrett wrote: > On Sunday, October 11, 2015 05:58:59 pm Viktor Dukhovni wrote: > > Pointless restrictions lead to fallback to even worse choices. > > And no restrictions lead to horrible fallback choices. Running under > the assumption that some population of implementors is willing to do > something stupid to maintain inertia (e.g. insecure version fallback > dance), sending SHA1 certs is a risk. Yes, the server doesn't know > whether the client can or cannot deal with it safely, but we, from > the perspective of the spec, should be assuming bad scenarios when > designing things.
so what we need is:
1. servers SHOULD NOT send certificates with SHA-1 signatures, except
as a last resort (maybe even add a recommendation that
implementers should warn user when such certificates are configured)
2. clients MUST NOT trust certificates which derive their authenticity
though SHA-1 (or weaker) signatures
but saying that the server MUST NOT send SHA-1 (or other certs) is, as
Victor said, an overreach
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, 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
