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

Hubert Kario <> Fri, 03 October 2014 11:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 486CF1AD035 for <>; Fri, 3 Oct 2014 04:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.687
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3zjAh-vEyIRk for <>; Fri, 3 Oct 2014 04:15:15 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4DC841A02D6 for <>; Fri, 3 Oct 2014 04:15:15 -0700 (PDT)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id s93BFEqK008056 for <>; Fri, 3 Oct 2014 07:15:14 -0400
Date: Fri, 3 Oct 2014 07:15:14 -0400 (EDT)
From: Hubert Kario <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
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==
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: Fri, 03 Oct 2014 11:15:17 -0000

----- Original Message -----
> From: "Viktor Dukhovni" <>
> To:
> 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 -

Hubert Kario