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

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 03 October 2014 13:30 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 BD3951A0AF1 for <tls@ietfa.amsl.com>; Fri, 3 Oct 2014 06:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 INisJzrY43PD for <tls@ietfa.amsl.com>; Fri, 3 Oct 2014 06:30:46 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808121A1A2D for <tls@ietf.org>; Fri, 3 Oct 2014 06:30:45 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BCCE32AB2A7; Fri, 3 Oct 2014 13:30:43 +0000 (UTC)
Date: Fri, 3 Oct 2014 13:30:43 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACsn0cnr49RHoNDhy=x7+Da=v4X=6rSMWKazA-ZObPTsuZnsGA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qEVxDXrGEKj8LF9W28DxOtLDf0Q
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
Reply-To: tls@ietf.org
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 13:30:47 -0000

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.

With Exchange 2003 email servers that are still operating at some
domains the only working ciphersuites are RC4-MD5 and RC4-SHA.
Operators will ignore the IETF and leave RC4 enabled so that mail
can continue to be sent to these domains.

Note also that MTA to MTA mail transactions generally don't carry
fixed sensitive text at a fixed position in the first 256 bytes of
the client or server TLS stream.  This is only an issue with
submission when the client is using "AUTH PLAIN" or "AUTH LOGIN".

I am strongly in favour of educating operators about the weakness
of RC4, provided we give them operationally realistic advice.
I don't see how MUST NOT is such advice.

-- 
	Viktor.