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:58 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 140CC1A0024 for <tls@ietfa.amsl.com>; Fri, 26 Sep 2014 11:58:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 vo6Yyzw4P7Ls for <tls@ietfa.amsl.com>; Fri, 26 Sep 2014 11:58:29 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0130.outbound.protection.outlook.com [207.46.100.130]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FD961A3BA7 for <tls@ietf.org>; Fri, 26 Sep 2014 11:58:29 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Fri, 26 Sep 2014 18:58:28 +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:58:28 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Bodo Moeller <bmoeller@acm.org>
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
Thread-Index: AQHP2T5a8EAtsaADg0ykrefiCf9Yj5wTq6MwgAAKvgCAAAKHEIAACt+AgAAALYA=
Date: Fri, 26 Sep 2014 18:58:28 +0000
Message-ID: <3217718b166c44b887feaab052335509@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> <CADMpkcJPdWemzB6ZFvBEGqTCKzM=mh2-j5gTt_NY+9uVg8prbQ@mail.gmail.com>
In-Reply-To: <CADMpkcJPdWemzB6ZFvBEGqTCKzM=mh2-j5gTt_NY+9uVg8prbQ@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:BL2PR03MB419;
x-forefront-prvs: 03468CBA43
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(377454003)(33646002)(74502003)(2656002)(105586002)(83072002)(86362001)(74316001)(21056001)(76576001)(74662003)(81342003)(92566001)(110136001)(108616004)(86612001)(95666004)(50986999)(16236675004)(79102003)(4396001)(83322001)(97736003)(85852003)(76482002)(99286002)(230783001)(93886004)(20776003)(80022003)(85306004)(106116001)(54356999)(81542003)(76176999)(101416001)(19580395003)(120916001)(19625215002)(19580405001)(64706001)(107046002)(46102003)(15975445006)(15202345003)(87936001)(10300001)(106356001)(19300405004)(31966008)(77982003)(90102001)(99396003)(24736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB419; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_3217718b166c44b887feaab052335509BL2PR03MB419namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/G_dwPyA2pcybbEAJLclnGvXiKak
Cc: Adam Langley <agl@imperialviolet.org>, "<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:58:32 -0000

Ø  If you really see a good reason to support this (which I don't) and are concerned about latency, you'd already need some TLS extension to send this information from the client to the server. I've never seen anyone propose this, and would be skeptical about it.
I think all that needs to be done is for the client to signal the previously attempted version, via extension or SCSV. Rather than just saying “I’ve tried a higher version before”, which is what the draft allows now.


Ø  I'd rather say that the client is forced not to skip versions when sending the SCSV (and that this is a feature).
I agree that the client app is forced, but disagree that this is a feature☺.

From: Bodo Moeller [mailto:bmoeller@acm.org]
Sent: Friday, September 26, 2014 11:53 AM
To: Andrei Popov
Cc: Adam Langley; <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

Andrei Popov <Andrei.Popov@microsoft.com<mailto:Andrei.Popov@microsoft.com>>:

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.

That's not supported with normal TLS version negotiation either -- if the client offers version X, the server may pick Y (< X) without having any way of knowing that Y is disabled in the client whereas some other version Z (< Y) is not.

If you really see a good reason to support this (which I don't) and are concerned about latency, you'd already need some TLS extension to send this information from the client to the server. I've never seen anyone propose this, and would be skeptical about it.

I am pointing out that, with the current draft, the browser is forced to not send the SCSV when skipping versions.

I'd rather say that the client is forced not to skip versions when sending the SCSV (and that this is a feature).

Bodo

v2.45.0 | Report a Bug | By Email | System Status