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

[Daniel Kahn Gillmor <[e-mail]>]

On Sat 2014-10-25 23:35:28 -0400, Andrey Jivsov wrote:
> Let's wait with TLS_FALLBACK_SCSV for a minute :-).
>
> To be even more specific, let's simplify the above a bit:
>
>         TLS1.2: X, Y
>         TLS1.1: X
>         TLS1.0: X
>         SSL3.0: RC4-MD5
>
> ( SSL3.0 has only RC4-MD5, and RC4-MD5 is not in X or Y. )
 [...]
> Example, using the above table:
>
> ClientHello: TLS1.1+RC4-MD5+TLS_FALLBACK_SCSV
> Server: MUST fail
>
> v.s.
>
> ClientHello: TLS1.1+RC4-MD5
> Server: negotiates SSL3.0+RC4-MD5

I think you've just demonstrated that the server is misconfigured in
this example.

Because of its misconfiguration, the server has selected SSL3.0 when it
could have selected TLS1.1.

(this scenario might have more nuance if we're talking about a TLS 1.3
specification that doesn't permit negotiation of RC4-MD5, but that's not
the scenario painted above)

----

In general, i don't have a lot of sympathy for the complaint that a
network failure causes fallback negotiation, which might fail.  Outside
of TLS, when a network failure causes a TCP session to abort, the
connection fails anyway.

We should have guidance to the implementer of any fallback dance that
the receipt of an inappropriate_fallback alert means you should clear
your notion of whether a given host needs a fallback.

In a browser context, this means that the user clicks "reload", and they
get a new try at the connection.  This is something users are familiar
with in other network-glitch scenarios.

     --dkg