On Tue, May 14, 2019 at 12:33 PM David Benjamin <david...@chromium.org> wrote:
> > which exact piece of popular software actually still does that? >> > It ain't curl, it ain't Chrome, it ain't Firefox. >> >> It definitely was implemented in Chrome and Firefox, which is how this >> poor document got onto standards track: >> >> https://tools.ietf.org/html/rfc7507 >> >> TLS Fallback Signaling Cipher Suite Value (SCSV) >> for Preventing Protocol Downgrade Attacks >> >> > >> > It also isn't something done automatically >> > by any TLS implementation that's even remotely popular: >> > OpenSSL, NSS, GnuTLS, schannel, Secure Transport, go... >> >> It is impossible to do this transparently, because the a connection >> is ususable after a fatal TLS hanshake failure (or unexpected socket >> closure). >> >> Any application-level cleartext negotiation will have to be repeated >> as well, and the TLS implementation typically does not know about it. >> (such as HTTP CONNECT or STARTTLS) >> >> The POODLE paper >> https://www.openssl.org/~bodo/ssl-poodle.pdf >> >> asserts that many clients doing downgrade dances exist, and at the >> time of publication, this includes Mozilla Firefox, Google Chrome and >> Microsoft Internet Explorer. >> > > Chrome has not done a downgrade dance for over three years now (Chrome 50, > released in April 2016), even for TLS 1.3. Indeed much of the fuss around > TLS 1.3 was so clients could avoid repeating this mess. > Martin, There's also value in people having fewer choices as security problems are often the result of misconfigurations. A lower number of protocols to support, chose from, and configure correctly is helpful to the larger number of implementers. Additionally, there is at least one library that planned to remove support for 1.0 and 1.1. This means that is product teams need to continue support, they have to run an older version of the library, plus newer ones for 1.3. This gets messy and increases the chance of error. The chance of misconfiguration is not insignificant (by product teams or implementers of those products). Best regards, Kathleen > > David > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Best regards, Kathleen
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
