Re: [TLS] Protocol version for inappropriate_fallback alerts

Bodo Moeller <> Fri, 14 November 2014 08:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2A31D1A870E for <>; Fri, 14 Nov 2014 00:12:58 -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 QcVJuaYHLvru for <>; Fri, 14 Nov 2014 00:12:56 -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 480091A0083 for <>; Fri, 14 Nov 2014 00:12:56 -0800 (PST)
Received: from ( []) by (node=mreue105) with ESMTP (Nemesis) id 0MS2iA-1XRZYF2xZK-00TB4m; Fri, 14 Nov 2014 09:12:54 +0100
Received: by with SMTP id va2so12223377obc.28 for <>; Fri, 14 Nov 2014 00:12:52 -0800 (PST)
MIME-Version: 1.0
X-Received: by with SMTP id fk1mr1200546oeb.44.1415952772647; Fri, 14 Nov 2014 00:12:52 -0800 (PST)
Received: by with HTTP; Fri, 14 Nov 2014 00:12:52 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Fri, 14 Nov 2014 09:12:52 +0100
Message-ID: <>
From: Bodo Moeller <>
To: Florian Weimer <>, Joseph Salowey <>, Sean Turner <>
Content-Type: multipart/alternative; boundary="089e0111b8440853880507cd32eb"
X-Provags-ID: V02:K0:9Ik27HiV9GkobS10JymTjgzbJiDM/yo5WhWUfNlDi61 u2r3Xk+N1NW5hhzYXk0S/5yLrXOpx+iNzMTI+aN/gGFoLGBMxm j1klnzW3txf8GZ5issQOd+s8PiT3CclC0mThwFGLT4Q/kajCwC JB5+aAFkZpLIhFJnSidV5uXJrPHcLnhHjHZiDTnn+g7BQV78F1 yS32QPUzVSEKrsIeUqmvs1d0h3OT8eJUkKoyJ2yvTqkciFOJTO uFeGnK8Dhr6OPhXIPRBFZctJf9cRujq7gabOGnhOeStNSPmhGX 8RAc9vB/hIk5iT1YYPRegPI2Vz8Ok/VNP6jMMgINZPlFlHYP4r i5PT3uZlKy9AZkQmaocbdyShxkPMPTLTi69+I2tD5ZKOblXJDK HlhrMDhMUOwFARrM3UDvU5aMt5PkQ4vuW+0HrxAe3/5whrWC1+ ZUWYO
X-UI-Out-Filterresults: notjunk:1;
Cc: "" <>
Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts
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: Fri, 14 Nov 2014 08:12:58 -0000

Florian Weimer <>:

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

So I believe that draft-ietf-tls-downgrade-scsv-02 addresses all comments
(cf. slide 5 in Joe, Sean,
can we proceed?