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

Watson Ladd <watsonbladd@gmail.com> Fri, 03 October 2014 07:02 UTC

Return-Path: <watsonbladd@gmail.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 679C51ACF88 for <tls@ietfa.amsl.com>; Fri, 3 Oct 2014 00:02:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 i5Zs6jLcj5UH for <tls@ietfa.amsl.com>; Fri, 3 Oct 2014 00:02:03 -0700 (PDT)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7A11A886D for <tls@ietf.org>; Fri, 3 Oct 2014 00:02:03 -0700 (PDT)
Received: by mail-yk0-f182.google.com with SMTP id 131so166747ykp.27 for <tls@ietf.org>; Fri, 03 Oct 2014 00:02:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Jm42ZNiLd/Tqgvs9bKht2slnPID2glvOvP1fkZhaKoM=; b=cs+nESo3w+iyjOtJ8BThhsLWSl9fMVLA2uVXfWtxivzVqK0pNgH84wd0YlXVODIdTK pY1njLBJIx1zm8QVYpf73TKhlqdm+XvZR1l7dT4k8c1NulDm+ZUvhtx2fsqsfHMXsofz YEJv4jeXOu6t7IvQosl+3NTE96oxr8nqYT/vXG+zwsjpKw+kr6blorwrIJdXufbo4hjs V4aG4Iy1xhjInMg3pONwPxOQrljK0QlobW4uLBQtOdMqGaEo5vfIa506H3X+4UJqkv45 9c2jneeBKlaRmlPyaU72WBAvF8nSPcPiDb53vXkNTGcGopYRcR42nPa1/MnLhRtRkdmK ynaA==
MIME-Version: 1.0
X-Received: by 10.236.231.178 with SMTP id l48mr5141118yhq.143.1412319722616; Fri, 03 Oct 2014 00:02:02 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Fri, 3 Oct 2014 00:02:02 -0700 (PDT)
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>
Date: Fri, 3 Oct 2014 00:02:02 -0700
Message-ID: <CACsn0cnr49RHoNDhy=x7+Da=v4X=6rSMWKazA-ZObPTsuZnsGA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WM-0epqWfDnNlvanQT5htX8YqkM
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 07:02:05 -0000

On Thu, Oct 2, 2014 at 9:24 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> 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
> TLS@ietf.org
> 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