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

[Hubert Kario <[e-mail]>]

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