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

Bodo Moeller <> Thu, 13 November 2014 22:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3744C1ADFAD for <>; Thu, 13 Nov 2014 14:08:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.262
X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qx5zU1n29GQz for <>; Thu, 13 Nov 2014 14:08:09 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 504991ADFAB for <>; Thu, 13 Nov 2014 14:08:08 -0800 (PST)
Received: from ( []) by (node=mreue004) with ESMTP (Nemesis) id 0MMrlb-1XupBq2zHT-008edm; Thu, 13 Nov 2014 23:08:06 +0100
Received: by with SMTP id v63so1889926oia.34 for <>; Thu, 13 Nov 2014 14:08:04 -0800 (PST)
MIME-Version: 1.0
X-Received: by with SMTP id bp1mr4232473obb.19.1415916484464; Thu, 13 Nov 2014 14:08:04 -0800 (PST)
Received: by with HTTP; Thu, 13 Nov 2014 14:08:04 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Thu, 13 Nov 2014 23:08:04 +0100
Message-ID: <>
From: Bodo Moeller <>
To: "" <>
Content-Type: multipart/alternative; boundary="089e013d0e021697d10507c4bfb4"
X-Provags-ID: V02:K0:emXAJWpH4y9Lp96Ho4eOUNNZkQziLMrQdxnt4NA/uDp LGMnsQDv0vzWS1gedZEIf9cnMv1XcRQxesr5ho28kjhkFJZ0Au bf0WTIZ3gaOjD8zbueHB6fbXmCtQbxqAu0Ouceetcj7Wyoq/j0 6dpZfRy4VMiTxZ/KdG/Ufu6eTm+zJ9zVWjrpsDJEUBCFsi4M3F tms61dqTk9mBnUoii6tXB1fiRo91Z/BRVj0Bx8IjfHm7dC3pT5 g2jlyPg5FFnC+b+XqaH202gXkwaUTQ69hbPMAGZMwvMOGJVcQd rjsXa9Gm88J557tGCy4H6uKDH48U8LebLmiI6C4Bip7WMl+Pjz 251A6GKpsNpJLqFWDxO3KIqGAG8CFepjantDwwLM4nIo/RUQET OoBPyymWsBfL9oRiu+Z1yC3GXcD51MdjzFstgsihied/jhO2DS n2SlO
X-UI-Out-Filterresults: notjunk:1;
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 22:08:13 -0000

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.

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.