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

[Bodo Moeller <[e-mail]>]

Andrey Jivsov <[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 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?

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.)

Bodo