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

Watson Ladd <watsonbladd@gmail.com> Fri, 03 October 2014 14:28 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 A8B171A0023 for <tls@ietfa.amsl.com>; Fri, 3 Oct 2014 07:28:56 -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 dZy0YIkLt_hV for <tls@ietfa.amsl.com>; Fri, 3 Oct 2014 07:28:54 -0700 (PDT)
Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5681A000C for <tls@ietf.org>; Fri, 3 Oct 2014 07:28:54 -0700 (PDT)
Received: by mail-qc0-f173.google.com with SMTP id x13so1059010qcv.4 for <tls@ietf.org>; Fri, 03 Oct 2014 07:28:53 -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=nAP9lolVT3zL93/95ogIPmgjO9MPCp+z2WuzHE0l9PY=; b=Q+PoTcSZsAyUT/59GxR4P0DUug7A2feJd92DI0vuOviCMgzgbiXtBHvoB9nZMDHQ7Y /IofR4nKYiiCpgNgr9QtIBpiUDgh8jH602COi27DWmZdcGVQbnx8jGj7IENdUg0f7bKw sI1FlmoP8Kxds0esyjBRvhkZrP4AVu7DwcsGlVNR3VQ6m1Hf67JOFQ1bf5+/nz6/6Jgj rzcVsWdzRUxmwvo+pPTcw/9PmO+VekO+oHvf0DymO1sbihVzXG+3hrAbzoD/0CXeIhXG 0BSVRBJXKsij9aForkBaBpgKQwZNv3GjpMDRVSw4Bam1QB97iqRdM+tb4jd/MMLYAerG S/KA==
MIME-Version: 1.0
X-Received: by 10.224.80.131 with SMTP id t3mr7431982qak.35.1412346533848; Fri, 03 Oct 2014 07:28:53 -0700 (PDT)
Received: by 10.140.20.199 with HTTP; Fri, 3 Oct 2014 07:28:53 -0700 (PDT)
In-Reply-To: <20141003133043.GV13254@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> <CACsn0cnr49RHoNDhy=x7+Da=v4X=6rSMWKazA-ZObPTsuZnsGA@mail.gmail.com> <20141003133043.GV13254@mournblade.imrryr.org>
Date: Fri, 3 Oct 2014 07:28:53 -0700
Message-ID: <CACsn0cmiosrq_eSs8x3NF2semioXUVvgh_s9JkcALVN0gJ3veQ@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/LCHqX05u7dFvnNj5eWldYCsVego
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 14:28:56 -0000

On Fri, Oct 3, 2014 at 6:30 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> On Fri, Oct 03, 2014 at 12:02:02AM -0700, Watson Ladd wrote:
>
>> > 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.
>
> In theory, but in practice it is.
>
>> 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.
>
> A MUST NOT prefer RC4 is something one can realistically implement.
> A MUST NOT offer is something that many will be forced to ignore.
> An auditor can just as easily write findings about SHOULD NOT as
> MUST NOT.
>
> Documents that don't match operational reality are I think
> counter-productive.  They eat away at the credibility of the
> standards body publishing the document.
>
> Before RC4 becomes MUST NOT, it needs to first become a low priority
> algorithm that is used when nothing better is available.

<snip>
What advice do you want to give them, and how will it end the use of
RC4? The advice given is to not offer RC4 cipher suites on the client
side, and not to pick them on the server side: are we only debating
the third point? Or are you saying that clients should feel free to
offer RC4, and servers should be configured to pick it last?

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