Re: [TLS] Protocol version for inappropriate_fallback alerts

[Bodo Moeller <[e-mail]>]

Florian Weimer <[e-mail]>:

What do you think about explicitly asking the client to tolerate any
>> version (as the TLS RFC does for the Client Hello record version) vs.
>> explicitly telling the server what to use?
>
>

> I think [the former] would be rather misleading because at least OpenSSL
> is not version-tolerant here, in the sense that the application will see a
> different error, and not one that reflects the inappropriate_fallback
> alert, if there is an unexpected version number in the alert message.


Thanks for your comment.

Right, I just wouldn't want to use OpenSSL behavior that might not be ideal
as an excuse to be unreasonably strict in the spec.

But then I think that stating explicit requirements for the server as
draft-ietf-tls-downgrade-scsv-02 does ("The record layer version number for
this alert MUST be set to ...") is not unreasonable in this case: the main
point of this alert is to provide an explicit signal from the server back
to the client *if* the server would normally be willing to negotiate that
protocol version. We're not requiring the server to use a record-layer
protocol version that it doesn't support at all. Server implementations can
first determine the protocol version to use, and *then* look for the SCSV
to check if they should proceed with the handshake: even if the handshake
will be aborted, they'll have the protocol version before they send the
alert.


So I believe that draft-ietf-tls-downgrade-scsv-02 addresses all comments
(cf. slide 5 in
http://www.ietf.org/proceedings/91/slides/slides-91-tls-0.pdf). Joe, Sean,
can we proceed?

Bodo