Bodo Moeller wrote:
> Martin Rex <mrex@sap.com>:
> 
> 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.

It is vague on purpose, because it is supposed to be non-normative.
Why would you want to inconvenience existing implementations
(where the record level protocol version for an alert might get determined
at the record protocol layer, and _not_ in function (as function parameter)
that triggers the alert response, such as:

   ssl3_send_alert(s,SSL3_AL_FATAL,SSL_AD_INAPPROPRIATE_FALLBACK);


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


Which looks very much like an bug in the TLS RFCs.
No, we don't need to be bug-for-bug compatible.


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


Non-obvious intentions of the author do not matter here.
The wording clearly suggests that it would be OK for servers for too high
as well.

Consider the following scenario:

 - server that has TLSv1.0 and SSLv3 disabled (Win2012 ADFS?)
 - middlebox in the path that kills TLSv1.2 connections
 - Client that starts with record.pv={3,3}+ClientHello.client_version={3,3}
   observes a connection closure (caused by the middlebox) and
   retries with  record.pv={3,1}+ClientHello.client_version={3,1}+FB_SCSV
   (MSIE 8 on Win7 with TLSv1.0+TLSv1.1+TLSv1.2 enabled)

I can see three possible server responses, and which one do you think
would be best in helping the client to decide how to continue (and why):

 (1) server sees the FB_SCSV and responds with fatal invalid_fallback alert
 (2) server sees ClientHello.client_version={3,1} and responds with
     fatal protocol_version alert
 (3) server continues handshake with ServerHello.server_version={3,2}


-Martin