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

Stephen Farrell <> Wed, 22 October 2014 23:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 624001AD409 for <>; Wed, 22 Oct 2014 16:04:38 -0700 (PDT)
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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OiwJdufz6zeb for <>; Wed, 22 Oct 2014 16:04:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0BA161A8755 for <>; Wed, 22 Oct 2014 16:04:32 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 207E3BE11 for <>; Thu, 23 Oct 2014 00:04:31 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BcMSpVrSKisW for <>; Thu, 23 Oct 2014 00:04:29 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id CE1F7BE10 for <>; Thu, 23 Oct 2014 00:04:29 +0100 (IST)
Message-ID: <>
Date: Thu, 23 Oct 2014 00:04:29 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
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: Wed, 22 Oct 2014 23:04:38 -0000


On 22/10/14 18:52, Viktor Dukhovni wrote:
> On Wed, Oct 22, 2014 at 10:28:54AM -0700, Ryan Carboni wrote:
>> This is why SHA-256 will never have a malicious collision, and why RC4 will
>> never be broken.
> Well, never is a long time, and it is already somewhat broken, in that
> the bias in at least firt 256 bytes of output makes fixed plaintexts
> transmitted repeatedly under varying keys vulnerable to recovery.
> While I would prefer to see RC4 phased out more gradually, I do
> not think we can claim that it has not been broken.
> So I think that it would be nice if there was some wiggle-room for
> opportunistic TLS.  As weak as RC4 might be, it is stronger than
> cleartext.  And the published bias attacks don't apply to MTA to
> MTA SMTP.  There is no (pairwise) fixed sensitive plaintext at a
> fixed offset in every MTA to MTA email transaction.
> I have no objections to banning RC4 for "strict" TLS use-cases.

I think there is a significant difference between the security
(in particular confidentiality) one gets with good and dodgy
algorithms which is sufficient to argue that the OS design
pattern is inappropriate to use with such dodgy algs.

The problem is if the ciphertext is recorded and if the alg
in question is broken in the near future in a ciphertext-only
attack then the result was the same as no confidentiality,
and was (post-facto but still in fact) not "better" security,
as per the OS design pattern. The nearer the "near future" the
more this applies. One might even meet people who might
speculate that the "near future" for academic cryptographers
could be the recent past for some government cryptographers.

So, it is entirely consistent to both promote OS and deprecate
RC4 in TLS if the WG chairs declare this has rough consensus.

I guess questioning the proximity of the "near future" in the
above argument is reasonable, but if, as I believe, the crypto
folk all tell us RC4 is now definitely past its sell-by date
then it's time for an RFC that deprecates that so that the
sensible use-by date hasn't yet again gone flying by with us
having said nothing. (And bear in mind that RFCs and BCPs are
nowhere near as normative as the sell-by date on your local
litre of milk;-)