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

[Andrey Jivsov <[e-mail]>]

On 10/25/2014 01:52 PM, Brian Smith wrote:
> On Sat, Oct 25, 2014 at 12:41 PM, Andrey Jivsov <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     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
>
>
> No. The set of ciphers that can be negotiated with TLS 1.2 must overlap
> with the set of ciphers that clients offer in their TLS 1.2 handshake.

I was talking about the way ciphers are structured on the server, but I 
think we agree because you accept the below "table" and use the word 
"overlap" (as oppose to superset).

>
>     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
>
>
> That seems OK to me. You just need to make sure that X is offered by all
> the clients you want to support that support TLS_FALLBACK_SCSV and that
> don't support TLS 1.2, and that at least one of {X, Y}  is supported by
> by all TLS-1.2-capable clients that support TLS_FALLBACK_SCSV.
> (Approximately.)

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

If you accept that this is allowed on the server, for the purpose of the 
draft what's the server's maximum protocol version?

1. TLS1.2
2. runtime-dependent, the highest version that a given ClientHello and 
server's set of ciphersuites can possibly negotiate (e.g. ClientHello 
containing only RC4-MD5 --> SSL3.0).

Certainly, the server max. version is TLS1.2 is the simplest of two. 
However, this results in odd behaviour when the server is required to 
fail fallback handshakes with versions that are more secure than it 
could negotiate if TLS_FALLBACK_SCSV was not present.

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

Had it been SHOULD fail for the server, the server could have noticed 
that this is not a downgrade that harms the security and allowed the 
handshake to continue.