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

[Viktor Dukhovni <[e-mail]>]

On Thu, Oct 02, 2014 at 09:13:08PM +0100, Alyssa Rowan wrote:

> RC4 is not sort of acceptable.

When draft becomes an RFC, it will be widely ignored.  For
interoperability reasons, many applications will sensibly continue
to support RC4 ciphers.  The MUST will have no more effect than a
SHOULD, the latter is all that can be justified at this time.

Mostly all we need is an end to servers preferring RC4 and overriding
the client ciphersuite preference order, and an end to clients
preferring RC4 over stronger options.  Which leaves RC4 in use only
when no stronger options are available.

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:

    Oct  2 02:12:30 ... TLS connection established from mail-oi0-f63.google.com[209.85.218.63]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct  2 15:14:52 ... TLS connection established from mail-ie0-f180.google.com[209.85.223.180]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct  2 15:21:49 ... TLS connection established from mail-lb0-f192.google.com[209.85.217.192]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct  2 15:28:26 ... TLS connection established from mail-ig0-f192.google.com[209.85.213.192]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct  2 15:46:09 ... TLS connection established from mail-qc0-f187.google.com[209.85.216.187]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct  2 22:29:06 ... TLS connection established from mail-qc0-f178.google.com[209.85.216.178]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct  3 00:10:20 ... TLS connection established from mail-lb0-f180.google.com[209.85.217.180]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct  3 01:44:04 ... TLS connection established from mail-pa0-f53.google.com[209.85.220.53]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct  3 03:41:55 ... TLS connection established from mail-pd0-f178.google.com[209.85.192.178]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits)

Many others are likely to continue ignoring impractical advice.
A more realistic document is I think likely to see greater adoption.

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

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.

So documents that mandate disabling RC4 in TLS 1.0 and/or SSL 3.0
are mere security theatre.  The theatre piece that comes to mind
is the Mikado:

    Ko-Ko: When Your Majesty says "Let a thing be done", it's as
    good as done, practically it is done, because Your Majesty's
    will is law. Your Majesty says "Kill a gentleman", and the
    gentleman is to be killed, consequently that gentleman is as
    good as dead, practically he is dead, and if he is dead, why
    not say so?

    The Mikado: I see. (Dramatic Pause) Nothing could possibly be
    more...satisfactory!

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.

Such a strategy would actually mean that RC4 begins to disappear
sooner, because this could be implemented in toolkits, and could
reasonably trump server policy.

Or we can pretend that operators will care that some RFC says MUST
NOT use RC4.

-- 
	Viktor.