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

[Andrey Jivsov <[e-mail]>]

On 10/25/2014 01:02 AM, Martin Thomson wrote:
> On 25 October 2014 00:55, Andrey Jivsov <[e-mail]> wrote:
>> Repeating my point earlier, it looks kind of harsh to fail TLS 1.1 on the
>> server when it can only negotiate SSL3.0 with that client.
> Why, if the client is willing to do TLS 1.1, there's an unnecessary fallback.
In my example the client failed TLS1.2 ClientHello and decided 
(incorrectly, due to network failure, etc) to do TLS1.1+TLS_FALLBACK_SCSV.

>
> Note that the maximum version in play is always the maximum version
> that the server (or client) is willing to negotiate.
The above is too general, so let's ignore it for now :-)
> If a server is
> capable of 1.2, but configured with 1.1, only downgraded handshakes to
> 1.0 or SSL will cause the alert to be generated.
I don't think this is what Bodo is saying. Sec 3 (server) is missing the 
concept of "configured", while the sec 4 (client) has it.

My example again is:

* the server capable of TLS 1.2 and lower. I mean, it will accept TLS 
1.2 ClientHello.
* the pair of the server and client happened to only able negotiate a 
ciphersuite that is set on the server to be SSL3.0
* client sends TLS1.1+TLS_FALLBACK_SCSV

So, what is server's maximum version? Bodo says it's TLS1.2. Thus, 
TLS1.1+TLS_FALLBACK_SCSV must fail. I say it's harsh because this pair 
can only negotiate SSL 3.0.