Re: [TLS] An SCSV to stop TLS fallback.

[Brian Smith <[e-mail]>]

On Wed, Nov 27, 2013 at 7:28 AM, Adam Langley <[e-mail]> wrote:
> On Tue, Nov 26, 2013 at 8:42 PM, Brian Smith <[e-mail]> wrote:
>> these fallback connections add a lot of
>> latency. If we attempt a fallback connection in response to a
>> connection reset, and we receive an inappropriate_fallback alert, then
>> we'd have to make yet *another* connection without the fallback.
>
> I didn't have that in mind. In the code as I currently have it
> written, an inappropriate_fallback doesn't trigger an "upgrade".
> Rather the original error code that triggered the downgrade is
> remembered and returned.
>
> So the connection might go: TLS 1.2, connection reset; fallback to TLS
> 1.1, inappropriate_fallback; fail the connection with a connection
> reset error.
>
> We don't retry HTTP connections, after all.

Sorry for the delay.

Firefox does retry for connection resets. In fact, our TLS intolerance
mechanism is implemented by converting the error that causes us to
suspect TLS intolerance into a connection reset error code, and then
returning that connection reset error to our HTTP stack. In the case
of a RST in the middle of a GET request when pipelining is enabled,
Firefox will even resend the GET request on the assumption that it is
idempotent. Firefox has done things this way for a very long time,
presumably to help users get the results they want when they are on
flaky networks.

Anyway, it seems bad get a positive "yes, you can reach me and I will
respond" response from the server and then stop trying to communicate
with it. It is better to find some way to get the HTTP response that
the user is waiting for, if we can find one.

This is why I think it is better to try backporting TLS-1.2-only
cipher suites to TLS 1.1 and TLS 1.0, and then have clients send all
the same extensions in TLS 1.0 and TLS 1.1 that they would send in TLS
1.2, plus an indication of the max version supported in an extension
or an SCSV, and then let the server "upgrade" the connection to TLS
1.2 by using TLS 1.2 features while still indicating in its
ServerHello.server_version.

Granted, there is significant compatibility risk in doing this,
because some intermediary may choke somehow.  It will require
widespread experimentation to see how well it works. I am happy to
change Firefox to support this experiment if we can find partners
running servers on the internet that are also willing to experiment
with it.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)