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

Alyssa Rowan <> Thu, 02 October 2014 11:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D84E91A1A66 for <>; Thu, 2 Oct 2014 04:41:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s4apOiemlJu5 for <>; Thu, 2 Oct 2014 04:41:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 385BC1A1A4E for <>; Thu, 2 Oct 2014 04:41:05 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
From: Alyssa Rowan <>
Date: Thu, 02 Oct 2014 12:40:57 +0100
To: "" <>
Message-ID: <>
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 11:41:07 -0000

Hash: SHA512

On 2 October 2014 11:44:06 BST, Bodo Moeller <> wrote:
>NULL is not currently a MUST NOT ... of course, having a cipher suite that intently and expressly does not encrypt is clearer than having a cipher suite that offers weak encryption, so it could make sense to have a MUST NOT for RC4 even as NULL remains around for use cases that need it.

Good point. I think that's clearer, although I also think use cases that need NULL are either poorly addressed by TLS or looking at it the wrong way as they own endpoints and can monitor traffic safely there, so keeping NULL around is IMHO more trouble than it's worth in TLS 1.3.

>Translated from prose, I think you're saying SHOULD NOT.

Except that I honestly do not think any "valid" reason exists to use RC4 at this point - which equates to MUST NOT.

Let's go through possible justifications for why I think that, and alternatives:

• Backwards compatibility with rusty legacy implementations? Fine, begrudgingly, choose 3DES, if you *really* must, but you probably SHOULD NOT (implementations that legacy are either out of support so you have bigger problems or can be security patched to use strong ciphersuites instead). It's too weak? (What, and you think RC4's better?) It's affected by BEAST? (Countermeasures against active attacks, disable scripting and Java, and 1,(n-1) splitting.) Bad performance? (There's plenty of 3DES hardware.)

• High performance? AES-GCM (in the presence of hardware support) or ChaCha20-Poly1305. Both faster than RC4 unless you're packing an 8-bit, and quite reasonable even if you are.

• A special deployment where both sides don't care about confidentiality? NULL, then (and repent at leisure when an attacker breaches your trusted network and you've egg all over your face).

Nope, I'm drawing a blank here. Like the 40-bit ciphers, it just doesn't make any sense to me. I can think of no valid reason to use RC4 where something else doesn't work better. Of course I can't force others into that viewpoint, but I can and will say anyone still using it after this RFC is published were warned about the dangers, and of better alternatives, and chose to ignore them to everyone's detriment.

- --
Version: APG v1.1.1