Re: [TLS] Protocol version for inappropriate_fallback alerts (was: Re: I-D Action: draft-ietf-tls-downgrade-scsv-01.txt) (Martin Rex) Thu, 13 November 2014 23:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5AC2C1AE257 for <>; Thu, 13 Nov 2014 15:20:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KnjtvizKhtTH for <>; Thu, 13 Nov 2014 15:20:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5EDBD1AE2B2 for <>; Thu, 13 Nov 2014 15:19:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D6EE33A2F7; Fri, 14 Nov 2014 00:19:54 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id CE508429CB; Fri, 14 Nov 2014 00:19:54 +0100 (CET)
Received: by (Postfix, from userid 10159) id C65861AFCC; Fri, 14 Nov 2014 00:19:54 +0100 (CET)
In-Reply-To: <>
To: Bodo Moeller <>
Date: Fri, 14 Nov 2014 00:19:54 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
Cc: "" <>
Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts (was: Re: I-D Action: draft-ietf-tls-downgrade-scsv-01.txt)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Nov 2014 23:20:16 -0000

Bodo Moeller wrote:
> Martin Rex <>:
> 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:


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