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

Andrei Popov <> Thu, 02 October 2014 17:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A12AD1A86ED for <>; Thu, 2 Oct 2014 10:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8cpcshfZz5f9 for <>; Thu, 2 Oct 2014 10:54:09 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2D4B41A03A9 for <>; Thu, 2 Oct 2014 10:54:09 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1044.10; Thu, 2 Oct 2014 17:54:07 +0000
Received: from ([]) by ([]) with mapi id 15.00.1039.011; Thu, 2 Oct 2014 17:54:07 +0000
From: Andrei Popov <>
To: "" <>
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Date: Thu, 2 Oct 2014 17:54:07 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
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;; 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
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.



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

Hash: SHA512

On 2 October 2014 15:44:37 BST, Bodo Moeller <> 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.

> (, 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.

- --


TLS mailing list