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-----
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Bill Frantz
- [TLS] RC4 depreciation path (Re: Deprecating more… Watson Ladd
- Re: [TLS] RC4 depreciation path (Re: Deprecating … Kurt Roeckx
- Re: [TLS] RC4 depreciation path (Re: Deprecating … Ilari Liusvaara
- Re: [TLS] RC4 deprecation path (Re: Deprecating m… Michael D'Errico
- Re: [TLS] RC4 deprecation path (Re: Deprecating m… Kurt Roeckx
- Re: [TLS] RC4 deprecation path (Re: Deprecating m… Yoav Nir
- Re: [TLS] RC4 depreciation path (Re: Deprecating … Fabrice
- Re: [TLS] RC4 depreciation path (Re: Deprecating … Yoav Nir
- Re: [TLS] RC4 depreciation path (Re: Deprecating … Kurt Roeckx
- Re: [TLS] RC4 depreciation path (Re: Deprecating … Watson Ladd
- [TLS] RC4 Considered Harmful (Was: RC4 deprecatio… Alyssa Rowan
- Re: [TLS] RC4 depreciation path (Re: Deprecating … Yoav Nir
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Yoav Nir
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Watson Ladd
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Alyssa Rowan
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Jacob Appelbaum
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… David Holmes
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Martin Rex
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Watson Ladd
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Alyssa Rowan
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Martin Rex
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Martin Rex
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Watson Ladd
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Paterson, Kenny
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Paterson, Kenny
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Salz, Rich
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Paterson, Kenny
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Yoav Nir
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Geoffrey Keating
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Martin Rex
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Paterson, Kenny
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Marsh Ray
- Re: [TLS] RC4 Considered Harmful (Was: RC4 deprec… Martin Rex
- Re: [TLS] RC4 depreciation path (Re: Deprecating … Kurt Roeckx