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

[Andrey Jivsov <[e-mail]>]

On 10/24/2014 02:58 AM, Bodo Moeller wrote:
> Andrey Jivsov <[e-mail] <mailto:[e-mail]>>:
>
>     Client decides to drop to TLS1.1 (due to network glitch, etc).
>     [...] The server MUST fail with inappropriate_fallback per sec 3.
>
>     Is it a good idea to reject a more secure protocol than the server
>     can possibly negotiate with this client?
>
>
> In this case, the connection really fails due to the network glitch. 
> If the client wasn't attempting fallback retries, it would similarly 
> fail. (This could happen independently of the cipher suites that the 
> server accepts.)

In this scenario the client would succeed with the same server if the 
server doesn't implement draft-ietf-tls-downgrade-scsv but will fail if 
the server implements draft-ietf-tls-downgrade-scsv-03. Interestingly, 
regardless of draft-ietf-tls-downgrade-scsv-03 implementation the 
negotiated ciphersuite will be the same (when the pair succeeds with the 
handshake, that is)


>
> In the kind of hypothetical scenario that you describe, it indeed 
> wouldn't cause a reduction in security to accept the connection 
> instead of failing, but optimizing for corner cases like this one 
> doesn't seem reasonable: it necessarily would make the mechanism more 
> complex overall.
>
> (The server behavior that you describe also would be really odd. The 
> CBC cipher suites are more broken in SSL 3.0 than in TLS 1.0, and more 
> broken in TLS 1.0 than in TLS 1.1. If the server *does* support one of 
> the newer protocol versions, why would it only support the most broken 
> incarnation of that cipher suite?
>

This configuration of the server may be driven by the logic that "we 
will use legacy algorithms (RC4, SHA1, etc) with legacy protocols (SSL*, 
TLS1.0) for legacy clients".

> Also note that in the *specific* hypothetical scenario that you 
> describe, the server actually would accept the fallback retry: you 
> said that TLS 1.0 is the highest protocol version supported by the 
> server; this is not higher than ClientHello.client_version in the TLS 
> 1.1 retry, so the server wouldn't reject.)

No, this is not what I was saying.

In my scenario the server supports TLS1.2 in general with some 
ciphersuites (and will support TLS1.3 in the future). The server is 
configured in a way that the ciphersuite that it can negotiate with the 
client requires SSLv3.

What does draft-ietf-tls-downgrade-scsv-03 want the server to do here: 
assume it's highest version is TLS1.2 or SSL 3.0?  I.e. is the max. 
version a static property on the server or dynamic based on ciphers in 
ClientHello?