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

[Henrik Grubbström <[e-mail]>]

On Thu, Oct 16, 2014 at 6:07 PM, Bodo Moeller <[e-mail]> wrote:
> Florian Weimer <[e-mail]>:
>
>> One interoperability issue I encountered is that I initially sent a
>> protocol version in the inappropriate_fallback alert that the OpenSSL client
>> could not process because the protocol version had not been negotiated at
>> this stage.  (This issue was also present in the code for the renegotiation
>> SCSV.)  This is an ambiguity in the original TLS specification, I think, but
>> perhaps the draft should say that you SHOULD send back the version used by
>> the client.
>
> Thanks for the comment. Is this different from other fatal alerts that the
> server might be sending in direct response to the ClientHello -- such as
> handshake_failure, or even protocol_version?

Not as far as I can see.

> Maybe it wouldn't hurt to explicitly say that if the client's version is
> supported by the server but rejected due to the SCSV, that's the version to
> use for the alert. But then record-layer version numbers are already a muddy
> issue as is; I wouldn't want to specify side aspects of behavior that may be
> incompatible, or utterly confusing if read in conjunction, with the guidance
> on record-layer version numbers provided by the TLS specifications.

The way I've done it is to send early alerts as a packet with
min(client_version, server_max_version), as sending packets indicating
a newer version than the server actually supports seems a bit iffy. Of
course in the specific case of inappropriate_fallback and the
tls_fallback_scsv, for a correct server implementation the
client_version will always be less than the server_max_version as
otherwise the alert wouldn't be sent, so the two end up with the same
result.

-- 
Henrik Grubbström                                       [e-mail]
Roxen Internet Software AB                              [e-mail]