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

[Andrey Jivsov <[e-mail]>]

On 10/25/2014 03:25 AM, Bodo Moeller wrote:
> Andrey Jivsov <[e-mail] <mailto:[e-mail]>>:
>
>         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.
>
>
> That's an inconsistency that I can fix. If a protocol version is
> completely disabled in the server, of course using that version isn't
> supposed to be an "inappropriate fallback".
>
>     My example again is:
>
>     * the server capable of TLS 1.2 and lower. I mean, it will accept
>     TLS 1.2 ClientHello.
>
>
> And will negotiate TLS 1.2?
>
>     * 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.
>
>
> If the server is willing to negotiate TLS 1.2, then this is an
> inappropriate fallback and will fail. It's not reasonable to optimize
> the specification to provide extra error redundancy for blatantly stupid
> servers as in this scenario (at the cost of making it more complex,
> which can lead to other problems).
>

Regarding "blatantly stupid servers",

what you are saying is that the set of ciphers that can be negotiated 
with TLS1.2 must be a superset of the ciphers that can be negotiated 
with TLS1.1 in any server configuration, and so on to SSL 3.0

I am not sure that this will always be possible. Let's say I must offer 
RC4-MD5 for legacy products that only support SSL 3.0.

I think it would be more secure to offer

   TLS1.2: X, Y
   TLS1.1: X
   TLS1.0: X
   SSL3.0: X, RC4-MD5

than

   TLS1.2: X, Y, RC4-MD5
   TLS1.1: X, RC4-MD5
   TLS1.0: X, RC4-MD5
   SSL3.0: X, RC4-MD5

where X, Y are reasonable sets that currently works well with modern 
products.

The last line in each of the two sets above is a weak configuration, but 
this is the only cipher+protocol that outdated and unpatched clients can 
negotiate.

If I make RC4-MD5 available for higher protocols, this will mean that 
it's now potentially available to modern clients. Hopefully the clients 
don't negotiate it, or at the very least order it at the bottom of the 
ClientHello, however, there is now an insecure RC4-MD5 offered with 
TLS1.2. At the very least it looks bad to auditors, scanners, etc.

My example earlier in this thread involved the modern client negotiating 
RC4-MD5, supposedly due to misconfiguration. I think the first 
configuration on the server is slightly better because SSL 3.0 would 
likely be disabled by some global override on the client, preventing 
this scenario.

I think one should accept a small probability for TLS1.2-capable servers 
to negotiate lower version with TLS1.2 clients.