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

Alyssa Rowan <akr@akr.io> Sat, 19 April 2014 22:41 UTC

Return-Path: <akr@akr.io>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2D51A0090 for <tls@ietfa.amsl.com>; Sat, 19 Apr 2014 15:41:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcMn4xUA0dMm for <tls@ietfa.amsl.com>; Sat, 19 Apr 2014 15:41:19 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4692C1A0102 for <tls@ietf.org>; Sat, 19 Apr 2014 15:41:18 -0700 (PDT)
Message-ID: <5352FB8A.3070109@akr.io>
Date: Sat, 19 Apr 2014 23:41:14 +0100
From: Alyssa Rowan <akr@akr.io>
MIME-Version: 1.0
To: tls@ietf.org
References: <CACsn0cnZFScA1WnitpHH--6_Kd0spfLQvmvniyCSnUmvr8xVhg@mail.gmail.com> <20140419131019.GA29561@roeckx.be> <5352B328.1080006@pobox.com> <20140419175352.GA9090@roeckx.be> <238BBDD5-DDE5-4627-AF4D-BC57DC0E61D7@gmail.com> <5352D82C.2030302@akr.io> <2E68BD96-A94F-4965-82AA-E8E6B314F1E7@gmail.com>
In-Reply-To: <2E68BD96-A94F-4965-82AA-E8E6B314F1E7@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/59Ui5ZW-igHNR7z2f5-QWTDYiiE
Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path)
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Apr 2014 22:41:21 -0000

-----BEGIN PGP SIGNED MESSAGE-----
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
thinking.

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

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

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

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTUvuKAAoJEOyEjtkWi2t6uj4QALYYY3+dWiBUiihdoQYVA01S
+S6c4Vgg/+xMRIirruIyQQhXkMRdAKIZk5rFIEv+cpjSm8flx6a5AdXCErcKrCnp
t2GPtk+K8fBjEGBziPsOGTEtOtI7M/rN5r9uoWO+lIeW7yX7tntyYpP1MYd8/GBQ
h4MNZ4ScPYCWJTsrn2h77QFFWxjK0KyhzFj3d7+dB2Z7iaGN44ubz+BijPBxmWuL
OvL7cqduO7hUZ+G9rGTUZH4mlez9b4tDpg99780ekjbBap8GE3iUuM5aDZ/zDk3R
istwUrREfq3VGk+NcecN2Jz1tayC7RIF8puvoi2PFPeTYXXdYXeVozyVtxFZWE45
i9TeU5V4AvSdQpxHzPIqpa+wDc2T7NGBOxfm2vRJI0D/IGt0ADsP9MaF3SCKP1zu
ls8gv/hzwo/fOgoKd4gbzqWhVIUval0HUMmRbNmqwXD+hpoF2FZh7OAvPFl8FRRp
5VU8kYKIZqdrgiCHxV8TxR+A7yPc7nAvO7jaG7MYMCzdYIvBwSSWtNQ0HSlV24Em
8SZBxM653V7YdNHsPGMaBxd0nJ/fIvbktAgcTxxmkQO9tux4XM9ImD9EZfDIxgKJ
LvxQGMIPDAXHPVqvswg/jLtLT3b1ZY16KZk9gxJxKiLkfeo76ev1E28JxJzR26qU
mLgPRjiH/qSKDlsVNsFS
=HsbX
-----END PGP SIGNATURE-----