Re: [TLS] Protocol version for inappropriate_fallback alerts (Martin Rex) Fri, 14 November 2014 17:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A3A3A1A1AFA for <>; Fri, 14 Nov 2014 09:11:51 -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 1csr3X2hCjKz for <>; Fri, 14 Nov 2014 09:11:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 632401A1B06 for <>; Fri, 14 Nov 2014 09:11:15 -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 20F903A42F; Fri, 14 Nov 2014 18:11:13 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 1192242CB0; Fri, 14 Nov 2014 18:11:13 +0100 (CET)
Received: by (Postfix, from userid 10159) id 072DC1AFD0; Fri, 14 Nov 2014 18:11:13 +0100 (CET)
In-Reply-To: <>
To: Florian Weimer <>
Date: Fri, 14 Nov 2014 18:11:13 +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
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 17:11:52 -0000

Florian Weimer wrote:
> Bodo Moeller wrote:
>> 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.
> You are finalizing the specification after the implementation.  I don't 
> think there is value in *not* documenting existing interoperability 
> requirements.
>> 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.
> Agreed.

This is ignoring the actual problem and passing the buck to implementors.

Keep in mind that there is the general IETF rule

"Be liberal in what you accept, be conservative in what you send",

and we know that there are several "scanners" / "probers" out there,
not just broken TLS implementations, and any kind of guidance should
cover-it-all, rather than leaving undefined behaviour.

The SSL alert response of the server should avoid using a protocol
version at the record layer which
   (a) the server potentially does not even implement and
   (b) which the peer can not reasonably be expected to understand.

(a) may often rule out ClientHello.client_version, not just for
    TLS probers / scanners, but also early adopter clients
    (like bleeding edge web browsers) talking to installed base servers

(b) makes the record_version that the client used at the record layer
    for the record carrying the ClientHello a reasonably safe bet.

but there still is the possibility that a scanner/prober or defective
client uses a protocol version at the record layer that the server
doesn't implement (or which doesn't even exist, mind you that TLSv1.2
requires servers to accept {0x03, 0xXX} at the record layer for the
initial ClientHello), and depending on the design of the existing
server code, the record layer may not want to use an invalid or
unknown protocol value at all, and rather fallback to a truely safe bet
(which I think would be {0x03, 0x00}, inspite of the specific alert
this document is newly defining isn't described in the SSLv3 spec.
(because the latter argument applies to *ALL* existing protocols,
 SSLv3 through TLSv1.2 and is therefore not applicable).

Personally, I would use the record version of the record which carried
the initial ClientHello, because independent of what it is, if the
client used it for ClientHello, it must be OK to use for the response
in the sense of "best effort".

{0x03, 0x00} while being a theoretical and fully spec-compliant "safe bet"
that no reasonable TLS implementation ought to choke on, may cause
choking in less reasonable implementations that started with {0x03, 0x01}
or above.