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

Hubert Kario <hkario@redhat.com> Fri, 03 October 2014 11:15 UTC

Return-Path: <hkario@redhat.com>
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 486CF1AD035 for <tls@ietfa.amsl.com>; Fri, 3 Oct 2014 04:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.687
X-Spam-Level:
X-Spam-Status: No, score=-7.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_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 3zjAh-vEyIRk for <tls@ietfa.amsl.com>; Fri, 3 Oct 2014 04:15:15 -0700 (PDT)
Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC841A02D6 for <tls@ietf.org>; Fri, 3 Oct 2014 04:15:15 -0700 (PDT)
Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s93BFEqK008056 for <tls@ietf.org>; Fri, 3 Oct 2014 07:15:14 -0400
Date: Fri, 3 Oct 2014 07:15:14 -0400 (EDT)
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Message-ID: <1878200851.5790803.1412334914571.JavaMail.zimbra@redhat.com>
In-Reply-To: <20141003042418.GS13254@mournblade.imrryr.org>
References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <BA2DFF33-7B0C-4E87-9C0E-215933AED88F@akr.io> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <CADMpkcJEt4e7LJAY+FsFcbyQE2x3SXsaOW3bffV4U2oN9EUKrg@mail.gmail.com> <542D850E.2060900@akr.io> <CADMpkc+Zbu64wek2HayW2tCf+d1ZYLocMp2PzXncyS=fHPDwsg@mail.gmail.com> <542DB1D4.4020601@akr.io> <20141003042418.GS13254@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.5.82.7]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF32 (Linux)/8.0.6_GA_5922)
Thread-Topic: I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Thread-Index: 2eY6vjuQd3w7ZQi9paqkgSL+ObxqPA==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YYDAjFEcsZBcFIQ-AXtHB4EPzZM
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
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: Fri, 03 Oct 2014 11:15:17 -0000

----- Original Message -----
> From: "Viktor Dukhovni" <ietf-dane@dukhovni.org>
> To: tls@ietf.org
> Sent: Friday, 3 October, 2014 6:24:18 AM
> Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
> 
> On Thu, Oct 02, 2014 at 09:13:08PM +0100, Alyssa Rowan wrote:
> 
> > RC4 is not sort of acceptable.
> 
> While we're debating this, Google (for example) is still today
> blithely ignoring the RC4 deprecation.  Their outbound SMTP client
> prefers RC4 over all other bulk crypto algorithms:

This is also the case for youtube video servers.

Doesn't make it a good idea because it makes it impossible for web clients
to drop RC4...

> Recall that most applications are choosing RC4 over stronger options
> through explicit operator configuration that no application or
> SSL/TLS toolkit can reasonably override.

This is not the case.

Only about 1% of servers support only RC4 cipher, 1.5% if you're
using Firefox[1].

On the other hand, over 21% of servers will negotiate a RC4 cipher
in case you're using Firefox (and nearly 18% if you're using
OpenSSL-like supported cipher list).

So by dropping RC4 from your first ClientHello (in case you do use
fallback) may as well cut your RC4 usage by over 20%!

> So in the final analysis, the same degree of operator indifference
> will follow from either a MUST or a SHOULD.  Solving the problem
> in practice, rather than in theory, means server software and
> perhaps hardware upgrades (on systems with no AESNI or similar
> support).  Various BCP documents, product tutorials, ... will need
> to be updated to discourage preference for the previously popular
> RC4.

Being able to point PHB to a RFC explicitly disallowing RC4 is a
step in this direction.

> It is of course far more reasonable for toolkits to disable RC4
> and similarly weak or weaker ciphers with TLS >= 1.2 and negotiate
> only lower protocol versions when this leaves no ciphers available.
> Presumably with TLS 1.2 both client and server can employ AES-GCM
> to avoid both CBC and RC4 issues.

 1). AES-128-CBC-SHA1 is faster than AES-GCM if you don't have
     hardware crypto acceleration, consequently RC4 is faster still
 2). People still configure TLS1.1+ capable servers to prefer RC4 
     (over 12% to be exact[1])

We've been asking server operators not to do it for quite some time
already. We need stronger arguments as they simply are not changing
those configurations quickly enough.

 1 - https://securitypitfalls.wordpress.com/2014/09/29/scan-results-for-september-2014/

-- 
Regards,
Hubert Kario