Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
mrex@sap.com (Martin Rex) Fri, 16 January 2015 23:08 UTC
Return-Path: <mrex@sap.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E6B1A8987; Fri, 16 Jan 2015 15:08:16 -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 T2i27-zVEPb8; Fri, 16 Jan 2015 15:08:13 -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 7CB631A897C; Fri, 16 Jan 2015 15:08:13 -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 E604C3A564; Sat, 17 Jan 2015 00:08:10 +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 D4A7442219; Sat, 17 Jan 2015 00:08:10 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id CA2D91B0FA; Sat, 17 Jan 2015 00:08:10 +0100 (CET)
Subject: Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
In-Reply-To: <CAFewVt6EOf7VVfuavqccsz_0CDjPXbsG=qWPZQ61=2pk4XVKmw@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Date: Sat, 17 Jan 2015 00:08:10 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20150116230810.CA2D91B0FA@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/aoROaJvP7cu1eU6ceUlPl3OsCEQ>
Cc: Hanno Böck <hanno@hboeck.de>, "tls@ietf.org" <tls@ietf.org>, Adam Langley <agl@google.com>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Jan 2015 23:08:16 -0000
Brian Smith wrote: > Adam Langley <agl@google.com> wrote: >> On Fri, Jan 16, 2015 at 12:03 PM, Hanno Böck <hanno@hboeck.de> wrote: >>> Recently Mozilla has disabled the now so-called protocol dance, which >>> makes adding another workaround (SCSV) pretty much obsolete: >> >> Until they add TLS 1.3 support, when they'll need it again. > > I don't think so, because we can change the way versions are > negotiated for TLS 1.3, so that the issue doesn't arise. In > particular, we can keep ClientHello.client_version as 0x0303 (TLS 1.2) > and negotiate TLS 1.3 with an extension. > > Also, the rate of TLS 1.3 intolerance might be significantly lower > than projected. Ivan's numbers are based on a ClientHello with 0x0304 > (TLS 1.3) as the record-layer version number. We know from past > experience working on NSS that 0x0301 (TLS 1.0) is a more compatible > record-layer version number. I think it was established that many > servers work fine when ClientHello.client_version = 0x0304 (TLS 1.3) > as long as the record-layer version number is 0x0301 (TLS 1.0) but > break when then record-layer vsion is 0x0304 (TLS 1.3). Sending { 0x03, 0x04 } at the record layer for the ClientHello at the beginning of a new connection MUST be expected to get unconditionally rejected by pre-TLSv1.2 servers. It puzzles me to why so many implementers get this wrong. Adding the aggressive automatic silent fallback reconnects (the "downgrade dance") to browser was not very smart. The problems such fallbacks create was extensively discussed in the TLS WG in late 2009 (renegotiation issue that resulted in rfc5746). But what was a really bad idea was neither offering a user an opt-in for individual downgrades, nor allowing the user to disable the downgrade dance. Also not attempt was made to count how often downgrades happened, nor to limit how often browsers would perform automatic silen downgrades. This gross negligence was one of the reasons why the brittle connection management in Firefox, that regularly caused downgrades all by itself, was (a) unnoticed by the responsible developers and (b) was ignored for almost 6 years after reported as an easily reproducible FF bug... Making repetitive/frequent downgrades (e.g. more than 1 full handshake per host per hour) an interactive user opt-in, rather than the automatic silent can-not-be-disabled-by-user nuisance and security problem that it currently is, would immediately provide significant protection -- and entirely without server-side changes. As a bonus, this would also help in identifying/reminding on server software/devices that should probably be updated. -Martin
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Stephen Farrell
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Stephen Farrell
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Bodo Moeller
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Nikos Mavrogiannopoulos
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Nikos Mavrogiannopoulos
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Nikos Mavrogiannopoulos
- RE: Last Call: <draft-ietf-tls-downgrade-scsv-03.… Salz, Rich
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Brian Smith
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Martin Rex
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Martin Rex
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Yoav Nir
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Eric Rescorla
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Adam Langley
- RE: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Andrei Popov
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Bodo Moeller
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Bodo Moeller
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Colm MacCárthaigh
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Hanno Böck
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Jeffrey Walton
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Watson Ladd
- RE: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Yuhong Bao
- RE: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Yuhong Bao
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Henrik Grubbström
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Hubert Kario
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Michael D'Errico
- Re: Last Call: <draft-ietf-tls-downgrade-scsv-03.… Stephen Farrell
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Martin Rex
- Re: [TLS] Last Call: <draft-ietf-tls-downgrade-sc… Bodo Moeller