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

Ryan Carboni <> Wed, 22 October 2014 17:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 65A861ACE59 for <>; Wed, 22 Oct 2014 10:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WRITs0_s7sjc for <>; Wed, 22 Oct 2014 10:29:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 73D971ACE84 for <>; Wed, 22 Oct 2014 10:29:35 -0700 (PDT)
Received: by with SMTP id n3so1543381wiv.3 for <>; Wed, 22 Oct 2014 10:29:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=MBdohFc5hpUC4Cm2k0SO4nivgf7yf8eKXRUl6qF4Q3o=; b=QlQgw6pgkPUjRuaWhCPBKyVrWgaAW/51Fjleui19TsJ60w2DGu1qfM2YFF2c/zMZGv aHI6aAzmYnuMdiqadDCm2yo/vcSnZL80/6KI1jRPPe38zxapUUKHz+h/KlYf+XGDVj4O DeG4Nm04HtHAswVnONnf+TFHra5wWlZRlYz9YB6wq5mvBGoIhhYoT+/u0J8OyVddT9As aKP7Y5jqyuMaWUafbvJp46KmYHvFcOtOi6CE4G7w83vW6Emh1rzEMnZMde7m2SnYYlLY BY9EcHEtsUpFkSyfQZBrnFHp7YliHLyRzHno5Rtpw0o1fFBt5IymqHUzGoUvT3WZB07G ag6w==
X-Received: by with SMTP id ga7mr7300326wib.1.1413998974142; Wed, 22 Oct 2014 10:29:34 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 22 Oct 2014 10:28:54 -0700 (PDT)
From: Ryan Carboni <>
Date: Wed, 22 Oct 2014 10:28:54 -0700
Message-ID: <>
To: "" <>
Content-Type: multipart/alternative; boundary=f46d04427186910dc50506064a93
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 17:29:38 -0000

> The main concern that I have with this approach is that attacks against
> RC4 will only get better and while the attacks may be currently impractical
> against HTTP cookies perhaps there are other usages where the problem may
> be greater.
> Pragmatically, implementers will do what is necessary to interoperate, so
> I think something along the lines of what Chris recommends below may be the
> best way forward.    I'm a bit reluctant to bring opportunistic security
> into the discussion at this point, but I think the rest is OK.
> Do folks think this is an acceptable way forward?
> Thanks,
> Joe

This is a common misconception. Cryptography isn't a linear effort. As
knowledge of cryptography improves through research, that knowledge is
applied through the design of future ciphers. This is why MD5 was easily
broken, but only after knowledge had improved. After theoretical attacks on
SHA-1 emerged, people used the trendline of how quickly md5 failed to
determine that SHA-256 will fall in about 5 to 15 years. Thus there was a
SHA-3 hash competition, but it turned out that the trendline failed, the
knowledge on which SHA-256 was built was superior to md5.

This is why SHA-256 will never have a malicious collision, and why RC4 will
never be broken. RC4 is a primitive design and Rivest got lucky in
designing a good cipher when knowledge of cryptography was so poor.
Preimaging the internal state of RC4 based on it's output will be
difficult, partly why the best attack from that direction is around 2^700.

RC4 shouldn't be used in new protocols much like md5, ChaCha8 128-bit
should probably replace RC4, but there aren't many fast ciphers currently
implemented in clients right now. And it will take years for
implementations to spread. It isn't practical to remove RC4 based on using
trendlines of past events when they don't apply in the same situation.

The number of possible permutations that could lead to a given RC4 output
is staggering, once again, the best attack on RC4's output is 2^700.
Attacks do not improve linearly, that is RC4 does not become 2^-10 less
secure each year.

On a minor note, after disabling RC4 and non-forward secrecy cipher suites,
I find my firefox browser negotiates Triple DES with servers with some old
set of cipher suites. I really do wish client side prioritization was

If you guys really want to disable RC4, why not disable Triple DES? It's
horribly insecure and is certainly "closer" to a break than RC4. It's 2^90
(despite a 168 bit key) at best, particularly with some precomputation