Re: [TLS] Fwd: New Version Notification for draft-bmoeller-tls-downgrade-scsv-00.txt
mrex@sap.com (Martin Rex) Mon, 30 September 2013 17:17 UTC
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34A921F9AD5 for <tls@ietfa.amsl.com>; Mon, 30 Sep 2013 10:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.178
X-Spam-Level:
X-Spam-Status: No, score=-10.178 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPpCS9f64naw for <tls@ietfa.amsl.com>; Mon, 30 Sep 2013 10:17:14 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 356BF21F960D for <tls@ietf.org>; Mon, 30 Sep 2013 10:17:02 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r8UHGvpV011101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Sep 2013 19:16:58 +0200 (MEST)
In-Reply-To: <CADMpkc+vidEbfLfNK5QYCiry9tP7pQfvDx6oJ8hxhhHNXQa3MQ@mail.gmail.com>
To: Bodo Moeller <bmoeller@acm.org>
Date: Mon, 30 Sep 2013 19:16:57 +0200
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: <20130930171657.C8BE01A9C2@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Fwd: New Version Notification for draft-bmoeller-tls-downgrade-scsv-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 30 Sep 2013 17:17:19 -0000
Bodo Moeller wrote: > > > > https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-00#section-3 > > > > This section specifies server behavior when receiving the > > TLS_DOWNGRADE_SCSV cipher suite from a client in > > ClientHello.cipher_suites. > > [...] > > > > To me, this part of your document places two requirements on the _server_ > > to abort the handshake. > > Yes. My point is that there's no server-side guesswork involved -- no > "flawed or unjustified" assumptions. This is entirely client-directed > behavior! To me, these two requirements amount to an unnecessary knee-jerk reaction, while we are fully aware that most TLS version interop problems are non-malicious, i.e. _not_ caused by an active attacker. I really see harm in increasing the amount of TLS handshake failures with new "abort" requirements of the TLS protocol itself. Any new/additional handshake failures ought to be left purely and entirely to the calling applications and their security trade-offs / policies, which may or may not involve the decision of an interactive user. Our concern in TLS WG ought to be reducing handshake failures, and getting rid of the reconnect fallback entirely. TLS version negotiation is royally broken (throughout the installed base), and has been a well known fact since before TLSv1.1 (rfc4346) was published in 2006. And it doesn't look like time is helping to improve the situation. Actually, by shipping a defective RSA premaster client_version check in Windows7/2008R2 the situation has become more challenging today than it was in 2006. Maybe you remember that there was a change to OpenSSL in order to *improve* interoperability (=less failed TLS handshakes) in face of this defective RSA premaster client_version check: http://www.ietf.org/mail-archive/web/tls/current/msg09417.html Relevant OpenSSL ChangeLog: Changes between 1.0.0h and 1.0.1 [14 Mar 2012] [...] *) Some servers which support TLS 1.0 can choke if we initially indicate support for TLS 1.2 and later renegotiate using TLS 1.0 in the RSA encrypted premaster secret. As a workaround use the maximum pemitted client version in client hello, this should keep such servers happy and still work with previous versions of OpenSSL. [Steve Henson] Another example for TLS version challenges are defective middle-boxes (Bluecoat seems popular for internet access from company networks): https://kb.bluecoat.com/index?page=content&id=KB5493&actp=search&viewlocale=en_US&searchid=1380557656642 Yet another example would be the upgrade path for an installed server-farm, where you would get yourself into trouble if the existing server-farm causes clients to perform reconnect-fallbacks and trying to test a new implementation of the kind you suggest would cause occasional handshake failures for handshake where the first request went to an old server, and the reconnect fallback to the updated server. So for such a setup, this kind of feature would require a "flag day". There is similar serious breakage in the TLS cipher suite documents that describe AES in counter mode: http://tools.ietf.org/html/rfc5288#section-4 http://tools.ietf.org/html/rfc6655#section-5 Implementing AEAD for TLSv1.0 or TLSv1.1 would be simple and straight- forward, and the cipher suites (themselves) would exhibit the same security properties. But this breakage prohibits clients from even proposing these cipher suites when they're doing a fallback, independent of what is causing the fallback. Consumers will typically (have to) limit the TLS version that their client offers upfront to obtain robust behaviour. And such a configured limitation will typically be used for years (for as long as the hardware is used and the software only upgraded). To really improve the situation, new protocol features (including TLS protocol versions >1.1) ought to be negotiated in a fashion that increases the amount of successful TLS handshakes for the entire installed base, and avoids the necessity for reconnect fallbacks-- something that the majority of programmtic TLS clients do not even have. -Martin
- [TLS] Fwd: New Version Notification for draft-bmo… Bodo Moeller
- Re: [TLS] Fwd: New Version Notification for draft… Yngve N. Pettersen
- Re: [TLS] Fwd: New Version Notification for draft… Bodo Moeller
- Re: [TLS] Fwd: New Version Notification for draft… Martin Rex
- Re: [TLS] Fwd: New Version Notification for draft… Bodo Moeller
- Re: [TLS] Fwd: New Version Notification for draft… Martin Rex
- Re: [TLS] Fwd: New Version Notification for draft… Bodo Moeller