Re: [TLS] Protocol version for inappropriate_fallback alerts (was: Re: I-D Action: draft-ietf-tls-downgrade-scsv-01.txt)

[Bodo Moeller <[e-mail]>]

Martin Rex <[e-mail]>:

I believe you should get rid of the MUST.
>
> -     [...]  The
> -     record layer version number for this alert MUST be set to either
> -      ClientHello.client_version (as it would for the Server Hello
> -      message if the server was continuing the handshake), or to the
> -      record layer version number used by the client.
> +     [...]  There
> +     has not been a protocol version negotiated at this point of the
> +     TLS handshake, so the inappropriate_fallback alert, like any
> +     other fatal alert this early during the handshake, should use
> +     a record layer protocol_version that the client can reasonably
> +     be expected to understand, such as the record layer protocol_version
> +     that carried the client's ClientHello handshake message or the
> +     ClientHello.client_version.
>

Hm. What else would the client "reasonably be expected to understand"? Your
proposed wording sounds very vague.


I have a serious problem with the text in the parentheses in your current
> version (from above, re-flowed):
>
> -     (unless it responds with a fatal protocol_version alert because the
> -      version indicated in ClientHello.client_version is unsupported).
>
> This text (a) is ignorant about how the SSL&TLS version negotiation is
> supposed to work and (b) gives a blessing to version-intolerant servers.
>

Well, actually I ended up with that text because I copied from the TLS RFCs
-- see the definition of the protocol_version alert:

"The protocol version the client has attempted to negotiate is recognized,
but not supported. (For example, old protocol versions might be avoided for
security reasons). This message is always fatal."


The above wording is *not* meant to encourage servers to send a
protocol_version alert if client_version is too high (new), which I think
is what you got from it. It merely recognizes that servers may be sending a
protocol_version alert if client_version is too low (old). I hadn't thought
of the other interpretation -- the intention here was simply to be clear
that previous current protocol_version behavior is still allowed, and not
overridden by a requirement to always send inappropriate_fallback.

If you read it in its actual context ("If TLS_FALLBACK_SCSV appears in
ClientHello.cipher_suites and the highest protocol version supported by the
server is higher than the version indicated in ClientHello.client_version,
..."), I think that's entirely clear in draft-ietf-tls-downgrade-scsv-02:
if the highest protocol version supported by the client is higher than
ClientHello.client_version and ClientHello.client_version is unsupported by
the server, then clearly client_version is too old. That has nothing to do
with version-intolerance.

Bodo