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

[Watson Ladd <[e-mail]>]

On Thu, Oct 2, 2014 at 9:24 PM, Viktor Dukhovni <[e-mail]> wrote:
> 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.

Let's be 100% clear here: RC4 is not required for interoperability, as
TLS 1.0, 1.1, and 1.2 all specify other MTI suites for interop.
Disabling RC4 is possible. It needs to be disabled, whether by no
longer offering it or administrator action. The Lucky 13 and BEAST
attacks require either client "features" and are mostly patched
anyway.

>
> 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:

Aren't these the documents that will precisely "discourage preference
for the previously popular RC4"?

It seems to me that you are arguing for SHOULD so that RC4 can
continue to be used, having conceded it shouldn't be. Every complaint
you make that MUST will end the use of RC4 is exactly a reason to do
it. I don't see how a SHOULD is more likely to lead to action than a
MUST.
>
>     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.

Why is this more reasonable than disabling RC4 for all protocol
versions where an alternative cipher exists/is offered and patching
Lucky13+BEAST? (There is also the alternative of enabling the new
extensions: I think we should ask what the path forward for TLS 1.1
is: migration or maintain forever?)

Why can this trump server policy, but preferring AES in all version can't?

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

They will care when the pentester points it out to their boss.

Sincerely,
Watson Ladd

>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin