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

Stephen Farrell <> Wed, 10 December 2014 00:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EAB541A6EF0; Tue, 9 Dec 2014 16:50:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HIbUL4clVye4; Tue, 9 Dec 2014 16:50:04 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 518321A1B7C; Tue, 9 Dec 2014 16:50:02 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CD7BBDD8; Wed, 10 Dec 2014 00:50:00 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pqNzROyiyFq5; Wed, 10 Dec 2014 00:49:59 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 0D3ADBDFB; Wed, 10 Dec 2014 00:49:59 +0000 (GMT)
Message-ID: <>
Date: Wed, 10 Dec 2014 00:49:55 +0000
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Tom Yu <>,,,
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] secdir review of draft-ietf-tls-prohibiting-rc4-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Dec 2014 00:50:11 -0000

Hi Tom,

On 10/12/14 00:21, Tom Yu wrote:
> 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.

That point was debated at length by the WG, which eventually
did reach a relatively strong consensus on the MUST NOT
despite the knowledge that some people might need to keep
RC4 around even after this is published.

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

No, single-DES doesn't feature. Triple-DES is implemented but
slow. AES as a h/w instruction on various chips (incl. many
intel processors and others) is relatively widely available
and is faster and better than RC4. For those without AES h/w
the likely evolution will be to chacha20 which is also being
worked between the TLS WG and CFRG and which is actually
already deployed in some browsers. (And which has good lineage
via the eStream crypto competition. Well, good enough according
to CFRG, which is why they're involved.)


> _______________________________________________
> secdir mailing list
> wiki: