On Sat, Oct 10, 2015 at 11:28:28PM +0300, Ilari Liusvaara wrote:
> > To be clear, the only thing that's allowed is SHA-1 in *certificates*.
> > It's forbidden in CertificateVerify.
>
> Isn't using it in certificates precisely more dangeous than using it in
> CertificateVerify (especially with TLS 1.3)?
So long as SHA-1 self-signatures are still tolerated in root or
self-signed end-entity certificates, I have no objection to TLS
1.3 specifying that a certificate signed with SHA-1 is not trusted
even when issued by a trusted issuer.
However, we *must* be careful about what obligations we impose on
a client or server that encounters a certificate chain in which
some certificate which is not self-signed uses a SHA-1 signature.
It would be a big mistake to mandate fatal or even warning alerts
or closing the connection. Rather, the required outcome is that
the chain is simply not trusted.
Whether *that* in turn leads to a connection termination depends
on whether verification is required. Opportunistic clients, or
servers that solicit optional client certificates need to be able
to continue despite the untrusted chain, and do what they do in
the absence of a peer certificate or when the peer certificate has
accceptable signatures, and and yet is still untrusted (or peername
does not match, ...).
So if the draft language for 1.3 essentially only prohibits *trusting*
SHA-1, but does not prohibit the *presence* of SHA-1 in the peer's
chain, I think that should be fine.
I don't want to see client's or servers hanging up just because a
peer presents a SHA-1 chain that would have been simply ignored
had it been SHA2-256 instead.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
