IETF Logo Mail Archive

Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)

Andrei Popov <Andrei.Popov@microsoft.com> Sat, 18 October 2014 01:08 UTC

Return-Path: <Andrei.Popov@microsoft.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 18C151A00E4 for <tls@ietfa.amsl.com>; Fri, 17 Oct 2014 18:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 HZa61U816rb2 for <tls@ietfa.amsl.com>; Fri, 17 Oct 2014 18:08:23 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0136.outbound.protection.outlook.com [65.55.169.136]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3DCD1A0087 for <tls@ietf.org>; Fri, 17 Oct 2014 18:08:22 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB548.namprd03.prod.outlook.com (10.141.91.140) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Sat, 18 Oct 2014 01:08:21 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1054.004; Sat, 18 Oct 2014 01:08:21 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Martin Thomson <martin.thomson@gmail.com>
Thread-Topic: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
Thread-Index: AQHP6g/vkqpMmvBKoUCxL3G2jHnzlpw0TqsAgABoBICAAAgfwIAACI2AgAAH2aCAACaKgIAAAF8ggAAHRICAAAleYA==
Date: Sat, 18 Oct 2014 01:08:20 +0000
Message-ID: <8f805ba832b645e680bb5aba5b878265@BL2PR03MB419.namprd03.prod.outlook.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <543F9893.806@redhat.com> <543FA0A0.1030205@polarssl.org> <543FCAED.50502@redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D39ECECB4@USMBX1.msg.corp.akamai.com> <5440E005.6000607@redhat.com> <180027849.13041583.1413544466157.JavaMail.zimbra@redhat.com> <CADMpkcL2mntDd0dOruziqF0F=xURnqGgd_YkpF+ONzz8v-wQ9Q@mail.gmail.com> <1354095824.13104897.1413553221955.JavaMail.zimbra@redhat.com> <CADMpkcLRCsfQSr0=f97kXJw3RwHN5A79MYQ2j7XaxPxUy2MCLg@mail.gmail.com> <CABkgnnUBYtWUY-CZDDzFiDpMWYbca74o6kejh2Q3L+FHVaHoOA@mail.gmail.com> <d8ce6c7437404bcbbea3a17e5c0b1582@BL2PR03MB419.namprd03.prod.outlook.com> <CABkgnnVJZhr3sD5iobbyLu-Vw3_i477zcbLFr-P+YB7RiKUtfg@mail.gmail.com> <7fe248e5b4374fbd8d04ff460bc3ace8@BL2PR03MB419.namprd03.prod.outlook.com> <76533ab02b644597a170cb5b76a42a99@BY2PR03MB554.namprd03.prod.outlook.com> <f00b602de88f42b1b0c8ff9f2e77f652@BL2PR03MB419.namprd03.prod.outlook.com> <CABkgnnVAZmXmA3xt8NqYw0t9kyeKr4G1cRm_PX5nmY5Qg_sogQ@mail.gmail.com>
In-Reply-To: <CABkgnnVAZmXmA3xt8NqYw0t9kyeKr4G1cRm_PX5nmY5Qg_sogQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ed31::3]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB548;
x-forefront-prvs: 0368E78B5B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(199003)(377454003)(189002)(86612001)(92566001)(86362001)(4396001)(19580405001)(64706001)(19580395003)(46102003)(20776003)(80022003)(95666004)(106116001)(107046002)(105586002)(99286002)(110100005)(101416001)(106356001)(76482002)(31966008)(21056001)(54356999)(76176999)(50986999)(76576001)(99396003)(97736003)(120916001)(40100003)(85852003)(33646002)(110136001)(122556002)(85306004)(93886004)(2656002)(87936001)(230783001)(108616004)(74316001)(24736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB548; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Sxjd_IxDG1NYz8rNb3B0eUe-l00
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
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." <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: Sat, 18 Oct 2014 01:08:32 -0000

Certainly a lot of implementations will keep SSL3 code around for a while, just disabled by default.

On the client side, SCSV (not extension) is only needed if fallback to SSL3 is allowed, correct? This is the very fallback that browser vendors are disabling right now. So the only browsers that fall back to SSL3 will be the ones without the Downgrade-SCSV support.

On the server side, SCSV (not extension) is only needed if a) SSL3 is enabled, and b) the server tries to protect clients that offer TLS1.0 (not 1.1 or 1.2) at the first connection attempt. Am I missing something? However, a browser that implements a shiny new Downgrade-something RFC is unlikely to offer TLS1.0 on the first connection attempt.

This is why I think the case for SCSV not extension is very weak, and getting weaker by the day.

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Friday, October 17, 2014 5:16 PM
To: Andrei Popov
Cc: Marsh Ray; tls@ietf.org
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)

On 17 October 2014 16:54, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
> Correct; however thanks to POODLE, these auto-downgrading client applications are rapidly removing SSL3 from the fallback sequence. So the reason for having SCSV (instead of a proper TLS extension) is disappearing.

I think on balance it's worth leaving this.  I expect NSS will maintain SSLv3 for some time to come for various reasons that I don't like, but am willing to tolerate.  The SCSV is going to provide a measure of protection to those people who are forced to allow it to live.

v2.23.0 | Report a Bug | By Email