On Mon, May 6, 2019 at 1:43 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> On Mon, May 06, 2019 at 01:50:42PM -0400, Kathleen Moriarty wrote: > > > Is this better suited for another (short) draft? > > SHA-1 certificates are history now. If we're raising the floor, > it should IMHO be safe to deprecate the MD5 and SHA-1 signature > algorithms from TLS 1.2. > > Does anyone have evidence of medium to long-term requirements for > continued SHA-1 sigalg support? > I've been following this one for some time now. Sadly, we still see quite a lot of SHA-1 sigalg usage with RSA, even more than we see TLS 1.0 and 1.1. (We already removed SHA-1 with ECDSA a couple years ago.) Some of it is because older Schannel will preferentially sign SHA-1 when offered, which is not a problem for removal but confounds metrics. Some of it is a bug in older OpenSSLs where, on connections with SNI, it loses track of the peer signature algorithm preferences and then assumes SHA-1 by default. Some of it is load balancers which implemented TLS 1.2 but failed to actually implement sigalg negotiation, and thus only sign SHA-1. This is a consequence of text in RFC 5246 which says, when the extension is missing, the server should take SHA-1 as default. With the benefit of hindsight, I think that was a mistake. It meant bugs like OpenSSL's get papered over with SHA-1, and any implementors that chose to only sign one algorithm would pick SHA-1. https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1 (This is not to say there shouldn't be text in this document or another that discourages those, or requires servers be able to sign some SHA-2 hash. But I don't expect those to be removable on the web until after TLS 1.0 and 1.1.) David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
