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

[Brian Smith <[e-mail]>]

On Fri, Sep 26, 2014 at 12:34 AM, Bodo Moeller <[e-mail]> wrote:
>> I'm OK with that, but if this is the real reason for the MUST, then
>> it's not particularly clear.
>
> Hm, maybe so. I can add a brief note showing how the handshake would fail if
> the server acts on the SCSV in this case, but I don't think the document
> should have to explain why we require the client to omit the SCSV rather
> than having the server ignore it. (Why would you want to send it if nothing
> follows from 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. That would be a very worthwhile addition to the
mechanism.

Cheers,
Brian