Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

Andrei Popov <Andrei.Popov@microsoft.com> Thu, 02 October 2014 17:54 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 A12AD1A86ED for <tls@ietfa.amsl.com>; Thu, 2 Oct 2014 10:54:13 -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 8cpcshfZz5f9 for <tls@ietfa.amsl.com>; Thu, 2 Oct 2014 10:54:09 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0113.outbound.protection.outlook.com [65.55.169.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4B41A03A9 for <tls@ietf.org>; Thu, 2 Oct 2014 10:54:09 -0700 (PDT)
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.1044.10; Thu, 2 Oct 2014 17:54:07 +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.1039.011; Thu, 2 Oct 2014 17:54:07 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Thread-Index: AQHP3c1Ub4FUPtdXakGIHJMHMTXmG5wb/DwAgAB2TYCAAGpcgIAABkeAgAAmaQCAAAbnYA==
Date: Thu, 2 Oct 2014 17:54:07 +0000
Message-ID: <64cfd9c21a3f430287b7a0d30908b007@BL2PR03MB419.namprd03.prod.outlook.com>
References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <BA2DFF33-7B0C-4E87-9C0E-215933AED88F@akr.io> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <CADMpkcJEt4e7LJAY+FsFcbyQE2x3SXsaOW3bffV4U2oN9EUKrg@mail.gmail.com> <542D850E.2060900@akr.io>
In-Reply-To: <542D850E.2060900@akr.io>
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:BL2PR03MB417;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 03524FBD26
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(3905003)(189002)(69224002)(199003)(377454003)(106356001)(64706001)(107046002)(2351001)(107886001)(4396001)(105586002)(74316001)(99396003)(76482002)(20776003)(10300001)(120916001)(80022003)(46102003)(106116001)(95666004)(21056001)(99286002)(85852003)(86612001)(87936001)(33646002)(230783001)(76576001)(2501002)(15975445006)(31966008)(93886004)(85306004)(19580405001)(19580395003)(108616004)(50986999)(97736003)(86362001)(575784001)(2656002)(101416001)(76176999)(54356999)(110136001)(92566001)(24736002)(3826002)(19627235001); 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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kONgTbdUv-FSdEjOLz2S-mzxjP4
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
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: Thu, 02 Oct 2014 17:54:13 -0000

Thanks for all the comments; I've noticed 3 recurring themes of discussion on this thread so far:

1. Add IANA code points for RC4 cipher suites listed in the Appendix.
I have no objection to this; will do since a lot of people seem to find it helpful.

2. "TLS servers MUST NOT select an RC4 cipher suite" is too strict/constraining/hard to deploy/etc. 
If we removed this MUST NOT, this would not be a prohibiting-rc4 draft, but a best practice recommendation. We have TLS-BCP for recommendations. The idea of prohibiting-rc4 is to completely remove a weak cipher suite.

3. But there are other weak cipher suites: EXPORT, DES, RC2, MD5... 
Totally agree; these need to be removed as well. However, we've been discussing prohibiting-rc4 for over a year now. I think we should let this draft proceed so that we can make some progress. I don't mind authoring a new I-D (or I-Ds) prohibiting EXPORT, DES, RC2, MD5 ciphers.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Alyssa Rowan
Sent: Thursday, October 2, 2014 10:02 AM
To: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2 October 2014 15:44:37 BST, Bodo Moeller <bmoeller@acm.org> wrote:
> It seems to me that having a bit of a gray area then is unavoidable 
> ... and often you *do* need some latitude in backwards-compatible 
> cases, assuming you support these to achieve backwards-compatibility.

As I've pointed out, if you're forced into backwards compatibility with rusty legacy, 3DES is, though crappy, a less crappy choice than RC4.

As Rich points out, just because legacy devices are indeed out there doesn't mean that they do TLS safely, and doesn't mean we shouldn't prohibit unsafe practice like using weak ciphers.

> (www.microsoft.com, for example, does allow RC4 cipher suites when 
> using TLS 1.0, which would be incompatible with that MUST NOT, since 
> it expressly applies to TLS 1.0 too.)

This draft is a warning to implementers and deployers of TLS that they MUST change their allowed ciphersuites to completely exclude RC4, because RC4 isn't safe enough to use in TLS (or really for any purpose anymore).

Pointing to examples of RC4 still being allowed in the wild only further demonstrates the need for this draft as-is.

> If the spec isn't aligned with reality, that's a bit of a problem. 
> You shouldn't have to interpret a MUST NOT as a SHOULD NOT.

Reality is, unfortunately, that RC4 should have obsoleted years ago.
That is indeed a bit of a problem - one we now need to fix rapidly.

> Maybe the spec should have strict MUST NOT requirements for TLS 1.2, 
> but make mere recommendations for the legacy protocols?

No, not sure I follow your reasoning here: RC4 is no less weak when used with SSLv3 or TLS 1.0 than with TLS 1.2. Might even be weaker, if there's a way to trick a server into selecting it (hence the fallback SCSV draft). I see no reason the prohibition ought not be absolute.

Regarding obsolete ciphers such as RC2 and DES, I don't think the need to prohibit them is quite as urgent, because people aren't actually using them in the wild. (Well, not _many_ people, anyway.)

I would indeed support their deprecation - but perhaps in a separate document, as I'm concerned that any unnecessary delay with this one is another day that RC4's still actively being used by many, even when better alternatives are available - which is another day of traffic Eve can record - and, I fear, break, now or any time later at their leisure.

The sooner we can proceed, the sooner we can start working to fix that.

- --
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJULYUNAAoJEOyEjtkWi2t6cZYQAK/LJRHi9BjIDkyQgTGiSRrl
D7tawBqIyR/0IErV+bz1UrIvCifx4Lrn99qscMEfuklRjEmJ0QJa2qAYYB51LPOi
+zxphHrXwSA3iofgTqawPLq3A+N6mHM38TBKhhxRW8oF8Y7zcNtvIAFRAWZ3f5zM
vAN9GW4MJLbDYpbu4mxsJ1qLhZ8+Ojo3IIcJnhhhZYJ6pdlwoQzWlUOzd9itdbbo
Nn1DnZUvJBIHS8uGclFamZDlg+f4b4Djy6msQH1C2VdQkgaZxAHr/E+gaU/whpTY
Qfc9FooyaEH5tpAiKDfcTjyhhgWatsJQhx39I+Mt/t9Ht+H7FR3kxHB4XRCgiSyg
ASvobV/ATo3aSflqeUrO7myS7cJWXH2gHCVKCXIw0JxIT40j5q08VtUsd9b1Db9Z
HaXWibvBYcngkGvpHC5CW+P7vNDP0x4wUPNaa/w8KBO7dZcqwFKC7BHpcekIKt4A
yQjiPAG2tXDmqd5Y9GykcJU0kFZucPbulcGnNW1KeAoZhgBmUzsDVq0gw6U+VQ/J
1vFcwG2DlCl1ICBxHEjCcNAiJ3K0MX5Dz6wMD2NaQ1CvlqU3g7HWHJha0VbMsQns
P1SLllT8Kjmm/KpJyqiYE0hbuYfWnUPv5BeKW5eVuBzZA2D8maHSBilIZIvPbv8K
a1qiinNciHhRIs14X8kV
=GfyS
-----END PGP SIGNATURE-----

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls