Re: [TLS] Protocol version for inappropriate_fallback alerts
mrex@sap.com (Martin Rex) Fri, 14 November 2014 17:11 UTC
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A3A1A1AFA for <tls@ietfa.amsl.com>; Fri, 14 Nov 2014 09:11:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1csr3X2hCjKz for <tls@ietfa.amsl.com>; Fri, 14 Nov 2014 09:11:40 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632401A1B06 for <tls@ietf.org>; Fri, 14 Nov 2014 09:11:15 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 20F903A42F; Fri, 14 Nov 2014 18:11:13 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 1192242CB0; Fri, 14 Nov 2014 18:11:13 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 072DC1AFD0; Fri, 14 Nov 2014 18:11:13 +0100 (CET)
In-Reply-To: <5465F075.1000306@redhat.com>
To: Florian Weimer <fweimer@redhat.com>
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: <20141114171113.072DC1AFD0@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SyDhOqlz5XGlZFhkCTMeGL1iWBI
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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. -Martin
- [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-0… internet-drafts
- [TLS] Protocol version for inappropriate_fallback… Florian Weimer
- Re: [TLS] Protocol version for inappropriate_fall… Bodo Moeller
- Re: [TLS] Protocol version for inappropriate_fall… Florian Weimer
- Re: [TLS] Protocol version for inappropriate_fall… Martin Thomson
- Re: [TLS] Protocol version for inappropriate_fall… Bodo Moeller
- Re: [TLS] Protocol version for inappropriate_fall… Martin Rex
- Re: [TLS] Protocol version for inappropriate_fall… Martin Thomson
- Re: [TLS] Protocol version for inappropriate_fall… Bodo Moeller
- Re: [TLS] Protocol version for inappropriate_fall… Martin Rex
- Re: [TLS] Protocol version for inappropriate_fall… Bodo Moeller
- Re: [TLS] Protocol version for inappropriate_fall… Martin Rex
- Re: [TLS] Protocol version for inappropriate_fall… Bodo Moeller
- Re: [TLS] Protocol version for inappropriate_fall… Bodo Moeller
- Re: [TLS] Protocol version for inappropriate_fall… Florian Weimer
- Re: [TLS] Protocol version for inappropriate_fall… Bodo Moeller
- Re: [TLS] Protocol version for inappropriate_fall… Florian Weimer
- Re: [TLS] Protocol version for inappropriate_fall… Martin Rex
- Re: [TLS] Protocol version for inappropriate_fall… Ben Laurie
- Re: [TLS] Protocol version for inappropriate_fall… Martin Rex
- Re: [TLS] Protocol version for inappropriate_fall… Watson Ladd
- Re: [TLS] Protocol version for inappropriate_fall… Martin Rex
- Re: [TLS] Protocol version for inappropriate_fall… Bodo Moeller
- Re: [TLS] Protocol version for inappropriate_fall… Martin Rex