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

[Bodo Moeller <[e-mail]>]

Brian Smith <[e-mail]>:

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


> Bodo, could you please reword the above to make it clearer?
>

Maybe I should rather change it?

"However, 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 MAY omit
TLS_FALLBACK_SCSV from ClientHello.cipher_suites
even if that version is lower than the latest version supported by the
client.

(Given that the protocol version has previously been negotiated
between the client and server, TLS_FALLBACK_SCSV is only
expected to have an effect if the server has since been updated
to support higher versions. Omitting TLS_FALLBACK_SCSV
lets the client continue to use the previously negotiated protocol
version. Sending TLS_FALLBACK_SCSV, in contrast, could lead
to an inappropriate_fallback alert if the client should start anew
to create a new session using the new highest protocol version.)"

Previously I'd assumed you'd want to keep "normal" behavior (simply
continue to use the previous protocol version), but I don't see a
compelling reason for the specification to prescribe that to clients.

Bodo