Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

[Brian Smith <[e-mail]>]

On Wed, Oct 15, 2014 at 9:25 AM, Florian Weimer <[e-mail]> wrote:
> I'm concerned that a straightforward implementation of this new SCSV in
> Firefox will introduce user-visible connection failures when the downgrade
> is caused by a (likely spurious) networking event.

First, Mozilla publishes some data regarding non-secure version
fallback at [1]. (The UI is terrible, but there is an option to get
the raw data in tabular form on the right hand side of the page). You
can see the key for that data in the source code at [2].

Anyway, Firefox needs to stop doing the non-secure version fallback in
the case of network failures. The overwhelming majority of TLS 1.2 ->
TLS 1.1 fallbacks in Firefox are due to server closing the connection
during the handshake. Probably in the vast majority of those cases,
the closed connection is not actually indicating version intolerance.
The second most common case of fallback is receiving a RST. Again, the
vast majority of those RSTs are probably not actually caused by
version intolerance. These two conditions make up about 99% of the
reason for fallback in Firefox.

The problem is there are a very small number of servers that DO
indicate intolerance by closing the connection or with a RST. However,
I also agree with the others that say that it doesn't make sense for
browsers to ask every server to implement the downgrade SCSV to be
safe, because browsers don't want to break compatibility with this
tiny minority of old, broken servers.

My understanding is that the Chrome web browser is currently
experimenting in pre-release versions with not doing the non-secure
fallback from TLS 1.0 to SSL 3.0. I think all browsers should extend
that experiment to disabling the non-secure fallback mechanism
completely.

In particular, browsers should disable the non-secure fallback
mechanism completely before TLS 1.3 gets deployed, so that the TLS 1.3
design doesn't become unnecessarily reliant on the non-secure fallback
mechanism for compatibility. Otherwise, we may never be able to remove
it.

Cheers,
Brian

[1] http://telemetry.mozilla.org/#filter=release%2F32%2FSSL_TLS12_INTOLERANCE_REASON_POST
[2] https://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsNSSIOLayer.cpp?rev=916f2837201c#1047