Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path)

Alyssa Rowan <> Sat, 19 April 2014 22:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CF2D51A0090 for <>; Sat, 19 Apr 2014 15:41:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EcMn4xUA0dMm for <>; Sat, 19 Apr 2014 15:41:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4692C1A0102 for <>; Sat, 19 Apr 2014 15:41:18 -0700 (PDT)
Message-ID: <>
Date: Sat, 19 Apr 2014 23:41:14 +0100
From: Alyssa Rowan <>
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path)
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: Sat, 19 Apr 2014 22:41:21 -0000

Hash: SHA512

On 19/04/2014 21:50, Yoav Nir wrote:

> I can probably do it, as long as I provide a configuration to 
> re-enable it. But that’s me.

Great. A good start. (Suggestion: Put a big fat warning on that config
option so no-one who re-enables it can say they didn't know what they
were getting into?)

> Check out the survey that Kurt posted a link to.

I'm well aware. Sorry state of affairs: so, what can we do here to
make it better? Maybe a little.

> 1.56% or TLS servers support only RC4.

Partly because of PCI compliance testers making noise about BEAST, I'm

An RFC strongly deprecating RC4 can only help reduce that number:
those same PCI compliance testers can be pointed towards that as 'best
industry practice' - and may fail them for that? Their remaining
solution? Probably TLSv1.2 AES-GCM.

It _could_ work? I'm not saying it will, but it's the best option I
can come up with.

> they can’t afford the bad publicity that comes with “some sites 
> don’t work with this browser”.

What I'm suggesting is: Don't blame the browser. Blame the site. It's
the site that only wants to use a bad cipher. A warning lets you place
blame where it belongs, depending on how you frame it....

   "! The site uses insecure ciphers!

    You attempted to reach %s but the server only offered to use
    an insecure cipher, RC4. [RFCabcd, 2014] specifically warns that
    the RC4 cipher MUST NOT be used anymore, because it is dangerously

    You should not proceed. If you proceed, an attacker could capture
    data that you send and read it in the future, including passwords
    and credit card numbers."

...blah blah, evil hackers will eat your babies etc. The point is, the
impression you want to give to the user is not "browser X throws up
errors with this site, shouldn't X fix it?", but "I'm seeing warnings
that site Y is insecure, shouldn't Y fix it?".

Of course, I'm being thoroughly idealistic here, assuming anyone ever
reads anything, no matter the colour or font size, and users won't
click through agreements for their mortal soul and give up their
passwords on the street to a woman with a clipboard for a Mars bar. <g>

The cynical side of me is more aware that browser veterans are
pragmatic, headdesk about this issue regularly and are used to
whatever changed most recently getting the blame for whatever happens,
no matter what.

That's why I'm suggesting a warning with an option to retry insecurely
rather than fail, or something kind of like that, but I'm broadly
aware of the difficulties they face. That's more a matter for them, of

What we can do here is, well, what we _are_ doing. What we can.

- --