Re: [secdir] secdir review of draft-ietf-tls-prohibiting-rc4-01

Andrei Popov <Andrei.Popov@microsoft.com> Wed, 10 December 2014 00:52 UTC

Return-Path: <Andrei.Popov@microsoft.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFFC1A1B7C; Tue, 9 Dec 2014 16:52:50 -0800 (PST)
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 0HMRnPc2rGJK; Tue, 9 Dec 2014 16:52:48 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:782]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71D571A0396; Tue, 9 Dec 2014 16:52:48 -0800 (PST)
Received: from BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) by BN3PR0301MB1188.namprd03.prod.outlook.com (25.160.156.15) with Microsoft SMTP Server (TLS) id 15.1.31.17; Wed, 10 Dec 2014 00:52:26 +0000
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) with Microsoft SMTP Server (TLS) id 15.1.31.17; Wed, 10 Dec 2014 00:52:25 +0000
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0031.000; Wed, 10 Dec 2014 00:52:25 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Tom Yu <tlyu@mit.edu>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-tls-prohibiting-rc4.all@tools.ietf.org" <draft-ietf-tls-prohibiting-rc4.all@tools.ietf.org>
Thread-Topic: secdir review of draft-ietf-tls-prohibiting-rc4-01
Thread-Index: AQHQFA8/R5nH5Nf+j02x4a9+JAqd9ZyH+/EA
Date: Wed, 10 Dec 2014 00:52:25 +0000
Message-ID: <BN3PR0301MB12505184349164AC4E4C0F9C8C620@BN3PR0301MB1250.namprd03.prod.outlook.com>
References: <ldviohks6bq.fsf@sarnath.mit.edu>
In-Reply-To: <ldviohks6bq.fsf@sarnath.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:ed31::2]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1251;UriScan:;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1251;
x-forefront-prvs: 0421BF7135
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(46034005)(189002)(13464003)(377454003)(199003)(51914003)(99286002)(54356999)(76176999)(101416001)(50986999)(54606007)(21056001)(106356001)(106116001)(105586002)(86612001)(99396003)(87936001)(2171001)(120916001)(2656002)(2201001)(86362001)(107886001)(92566001)(107046002)(102836002)(68736005)(40100003)(33656002)(230783001)(74316001)(122556002)(97736003)(54206007)(76576001)(2501002)(77156002)(62966003)(31966008)(4396001)(20776003)(19580405001)(64706001)(19580395003)(46102003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1251; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1188;
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/T5DlFoyATMuSTooVsN4OG6cymRg
X-Mailman-Approved-At: Tue, 09 Dec 2014 16:55:55 -0800
Subject: Re: [secdir] secdir review of draft-ietf-tls-prohibiting-rc4-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Dec 2014 00:52:50 -0000

Thanks for the review Tom,

There are definitely other weak cipher suites defined for TLS: EXPORT, NULL, MD5, DES to name a few. It was not easy to reach consensus on deprecating just one algorithm (RC4). Bundling other weak crypto into the same I-D would probably have caused even more opposition, so my preference would be to tackle those in separate I-D(s).

> On the other hand, I am wondering if an unintended consequence of sites or implementations disabling RC4 cipher suites is falling back to single-DES.  What prevents this fallback from happening?
Unlike RC4 (which is widely supported and preferred by multiple TLS clients and servers), single-DES is already disabled by default in those TLS clients and servers that receive regular updates. Publishing an IETF document prohibiting single-DES is probably still worthwhile, just less impactful in terms of providing guidance to the industry.

Cheers,

Andrei

-----Original Message-----
From: Tom Yu [mailto:tlyu@mit.edu] 
Sent: Tuesday, December 9, 2014 4:21 PM
To: iesg@ietf.org; secdir@ietf.org; draft-ietf-tls-prohibiting-rc4.all@tools.ietf.org
Subject: secdir review of draft-ietf-tls-prohibiting-rc4-01

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Summary: ready with minor issues

This document deprecates RC4 cipher suites in TLS due to attacks that can recover repeated plaintexts given about 2^26 sessions.  Accordingly, it says that TLS implementations MUST NOT use RC4 cipher suites.

However, I noticed that RFC 5469 specifies only "SHOULD NOT" for single-DES cipher suites in TLS.  I don't know whether a 2^56 offline exhaustive key search that reveals an initial plaintext is directly comparable to a 2^26 online attack that reveals the entire plaintext, but it seems odd that single-DES is only "SHOULD NOT" while RC4 is "MUST NOT".  Perhaps this document is not the right place to fix that discrepancy.

On the other hand, I am wondering if an unintended consequence of sites or implementations disabling RC4 cipher suites is falling back to single-DES.  What prevents this fallback from happening?  I don't have a lot of the relevant information about TLS implementations as deployed.