IETF Logo Mail Archive

Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

Andrei Popov <Andrei.Popov@microsoft.com> Fri, 26 September 2014 18:51 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 133EA1A0342 for <tls@ietfa.amsl.com>; Fri, 26 Sep 2014 11:51:49 -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, 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 uMq3X_NiYVIg for <tls@ietfa.amsl.com>; Fri, 26 Sep 2014 11:51:42 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0753.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::753]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE131A0327 for <tls@ietf.org>; Fri, 26 Sep 2014 11:51:42 -0700 (PDT)
Received: from BL2PR03MB417.namprd03.prod.outlook.com (10.141.92.12) by BL2PR03MB132.namprd03.prod.outlook.com (10.255.230.24) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Fri, 26 Sep 2014 18:51:19 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB417.namprd03.prod.outlook.com (10.141.92.12) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Fri, 26 Sep 2014 18:51:18 +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.1034.003; Fri, 26 Sep 2014 18:51:18 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Adam Langley <agl@imperialviolet.org>
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: AQHP2T5a8EAtsaADg0ykrefiCf9Yj5wTq6MwgAAKvgCAAAKHEIAABmoAgAAATHA=
Date: Fri, 26 Sep 2014 18:51:18 +0000
Message-ID: <4362f4b71cb44ebd80629d52dd791437@BL2PR03MB419.namprd03.prod.outlook.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <e2ae0847d4ef49c48fe972adead9bbcc@BL2PR03MB419.namprd03.prod.outlook.com> <CAMfhd9UQ1wHFMJpLcxX6o3YDcLn_Az_vy7PfB9QUwyjHrrPaJQ@mail.gmail.com> <ceda19c3fdee4b488cff118d34f44afe@BL2PR03MB419.namprd03.prod.outlook.com> <CAMfhd9XuPBQ1ohNO1Yj1TTQdMCnDg-uUrtvwWA=q74D2gSOPVA@mail.gmail.com>
In-Reply-To: <CAMfhd9XuPBQ1ohNO1Yj1TTQdMCnDg-uUrtvwWA=q74D2gSOPVA@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::2]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB417;UriScan:;
x-forefront-prvs: 03468CBA43
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(51704005)(377454003)(13464003)(199003)(24454002)(2656002)(230783001)(110136001)(76482002)(87936001)(20776003)(85306004)(86362001)(90102001)(31966008)(93886004)(106356001)(99286002)(106116001)(50986999)(101416001)(95666004)(15975445006)(83322001)(81342003)(54356999)(21056001)(80022003)(85852003)(74662003)(79102003)(46102003)(74316001)(120916001)(77982003)(81542003)(108616004)(74502003)(76176999)(97736003)(4396001)(83072002)(99396003)(19580395003)(33646002)(64706001)(92566001)(19580405001)(10300001)(76576001)(86612001)(107046002)(105586002)(3826002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB417; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB132;
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QrTSAxCUuYckgwZLXcC9qWWpPWY
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] 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: Fri, 26 Sep 2014 18:51:49 -0000

> If an administrator is worried that version x is too weak, then all versions <= x need to be disabled too I believe? I can't think of a security concern that is not monotonic with respect to TLS versions.

This may be true for the issues we know about today, and only taking into consideration protocol-level vulnerabilities. There are sometimes implementation-level bugs that affect a specific protocol version, and these are quickly worked around by temporarily disabling this protocol version.

In any case, the client app has a workaround (which is to not send the downgrade SCSV when skipping TLS versions). This workaround is far from perfect, but I can live with the current downgrade-scsv draft if I have to. In this case, the fix is pretty trivial, so I thought it was worth bringing this up.

-----Original Message-----
From: alangley@gmail.com [mailto:alangley@gmail.com] On Behalf Of Adam Langley
Sent: Friday, September 26, 2014 11:37 AM
To: Andrei Popov
Cc: Joseph Salowey (jsalowey); <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

On Fri, Sep 26, 2014 at 11:32 AM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
>> But stepping down is a good idea because you want to lose as few features as possible.
> This may well be, but arguably the TLS protocol should not be creating new constraints on the upper SW layers, where it's possible to avoid doing so.
>
> Regardless of what the browser wants to do, the system admin will sometimes disable a specific TLS version machine-wide (or enterprise-wide), e.g. due to version-specific security concerns. I am pointing out that, with the current draft, the browser is forced to not send the SCSV when skipping versions.

If an administrator is worried that version x is too weak, then all versions <= x need to be disabled too I believe? I can't think of a security concern that is not monotonic with respect to TLS versions.


Cheers

AGL

--
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org

v2.23.0 | Report a Bug | By Email