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

Alyssa Rowan <> Thu, 02 October 2014 17:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F14431A893B for <>; Thu, 2 Oct 2014 10:02: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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AyyfgSt20z26 for <>; Thu, 2 Oct 2014 10:02:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 496DB1A893F for <>; Thu, 2 Oct 2014 10:02:07 -0700 (PDT)
Message-ID: <>
Date: Thu, 02 Oct 2014 18:02:06 +0100
From: Alyssa Rowan <>
MIME-Version: 1.0
To: "" <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
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:02:14 -0000

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

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

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

- --