In terms of getting rid of TLS 1.0 and TLS 1.1 altogether, we're seeing around 3% of connections using TLS 1.0 or TLS 1.1. That's quite high, and it's likely that enterprise deployments are much worse.
I started gathering numbers on ServerKeyExchange hashes back in November. The code isn't on Chrome's stable channel yet, but earlier channels say a bit over 5% of ServerKeyExchanges are signed with SHA-1, which is also quite high. I also started probing servers in November and observed: (a) Servers which always sign SHA-1. (b) Servers which sign SHA-1 *unless* signature_algorithms omits it. Then they sign SHA-256!?!!? (c) Servers which sign SHA-2 but fail if signature_algorithms omits SHA-1. The ones I looked at were all from serving SHA-1 certificates, so probably their SSL stack compares certs against sig_algs. (b) and (c) mean that getting a sense of the true impact will be complicated until we finish getting SHA-1 certificates out of our system. I have not dug into what's going on with groups (a) and (b) yet. This all is not to say we shouldn't phase these out. But I do not expect it to be a speedy process for browsers. David On Mon, Jan 11, 2016 at 1:30 PM Kurt Roeckx <k...@roeckx.be> wrote: > Hi, > > After the SLOTH paper, we should think about starting to deprecate > TLS 1.0 and TLS 1.1 and the SHA1 based signature algorithms in TLS > 1.2. > > As I understand it, they estimate that both TLS 1.2 with SHA1 and > TLS 1.0 and 1.1 with MD5|SHA1 currently require about 2^77 to be > broken. They all depend on the chosen prefix collision on SHA1, > with the MD5 part in TLS 1.0 and 1.1 not adding much. > > It seems that disabling SHA1 in TLS 1.2 doesn't buy you anything > unless you also disable TLS 1.0 and 1.1. > > > Kurt > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
