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

[Brian Smith <[e-mail]>]

On Mon, Oct 13, 2014 at 4:47 PM, Bodo Moeller <[e-mail]> wrote:
> Brian Smith <[e-mail]>:
>> CASE 3: Client did not include the TLS_FALLBACK_SCSV, the server
>> forgot session state when it was upgraded. The server starts a new TLS
>> 1.1 session. Thus, the downgrade protection mechanism has failed to
>> prevent a version downgrade.
>
> Right, this is the most problematic case. Resuming a session using the old
> protocol version (if the server still recognizes that session) is one thing,
> but using the old version for a new session is another.
>
> However, this issue really just follows from the relevant language in the
> TLS RFCs: "Whenever a client already knows the highest protocol version
> known to a server (for example, when resuming a session), it SHOULD initiate
> the connection in that native protocol." If the client follows these
> directions, using the old protocol version even in case the server gets
> upgraded is expected.

I agree. But, my conclusion is that the TLS specification is wrong,
and that that advice should be dropped from it and ignored by clients,
because it enables this scenerio. I also think that the spec should be
changed to require servers to never resume a session for a version
lower than min(ClientHello.version, <the highest version the server
supports>), for similar reasons.

In fact, your draft would be a good place to tell clients that they
SHOULD NOT follow that advice in the TLS specifications.

>> I think the best solution is to take my original suggestion (i.e. keep
>> the current logic, but make it more clear),
>
> Now I'm a bit confused. If you consider that consequence (using the old
> version if server capabilities have improved since) "improper", why do you
> suggest keeping the current logic?

The current logic in your draft says that if the client doesn't
downgrade ClientHello.client_version to equal the version in the
resumed session, then it must send the TLS_DOWNGRADE_SCSV if
ClientHello.client_version is less than the highest version that it
supports. That is the correct logic. The way it is written has made
people think that TLS_DOWNGRADE_SCSV is never supposed to be sent
during resumption handshakes, which is why it is good to clarify it.

>> I think it is realistic to expect that servers that implement the
>> inappropriate_fallback logic to implement at least TLS 1.2 (or at
>> least TLS 1.1),
>
> I'm not so sure -- the TLS_FALLBACK_SCSV mechanism by design works equally
> well with TLS 1.0 and can be easily retrofitted at least in principle. Thus,
> to allow essentially *every* implementation to benefit from the SCSV, I
> wouldn't want to require any higher version.

OK.

Cheers,
Brian