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

[Brian Smith <[e-mail]>]

On Fri, Sep 26, 2014 at 12:38 PM, Bodo Moeller <[e-mail]> wrote:
> Brian Smith <[e-mail]>:
>> On Fri, Sep 26, 2014 at 12:34 AM, Bodo Moeller <[e-mail]> wrote:

<snip>

> *Could* fail, sorry. (As already explained by Martin, the problem appears if
> by the time you try to resume, the server supports additional protocol
> versions. Of course that could also happen for an immediate retry, and
> you'll have to live with it then; so I wonder if that "MUST" isn't too
> strict after all: if you're willing to start over on inappropriate_fallback,
> you might actually prefer to send TLS_FALLBACK_SCSV *in order* to get a
> connection failure if the server has been updated.)

Right. In general, a resumption ClientHello SHOULD be just like a
non-resumption ClientHello, except for the presence of the session ID
and/or session ticket, because a resumption ClientHello is potentially
the start of a full handshake.

The TLS specs (TLS 1.2, in this case) say:

   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.

However, actually the client does not ever know the highest protocol
version the server supports, because the server may have expanded its
version support since the last time the client contacted it. But, the
consequence of that sentence is that at least NSS sends the session
version as client_version instead of its actual max supported version.
I think that is wrong. However, it isn't clear if there are
compatibility issues with changing that.

>> Here is what the draft actually says:
>>
>>       However, as an exception to the above, when the client intends to
>>       perform an abbreviated handshake to resume a previously negotiated
>>       session and sets ClientHello.client_version to the protocol
>>       version negotiated for that session, the client MUST NOT include
>>       TLS_FALLBACK_SCSV in ClientHello.cipher_suites.
>>
>> So, if the client does NOT set ClientHello.client_version to the
>> version negotiated for that session, then the client MAY send the SCSV
>> in the resumption handshake.
>>
>> Now, if the server could indicate that it supports the SCSV somehow in
>> its ServerHello, then the client could save that acknowledgement in
>> the session state, and then make sure that it always sets
>> ClientHello.client_version to the highest version it supports,
>> regardless of the version that it negotiated for the session it is
>> trying to resume.
>
> Hm, if you can set ClientHello.client_version to the highest version
> supported by the client and the server tolerates that, you shouldn't be
> employing the fallback mechanism with this server in the first place.

I had thought that NSS was changed to use the session version for
ClientHello.client_version during resumption for compatibility
reasons. However, looking at the change history, it appears to be the
case that that change was made coincidentally with a compatibility fix
for renegotiation, not initial resumption handshakes. So, it may be
the case that it is already safe to always send the max supported
version as client_version in an initial resumption handshake, without
any indication from the server, even in the non-secure fallback case.
It would require some implementation to make that change and test the
compatibility to know for sure.

Cheers,
Brian