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

Geoffrey Keating <geoffk@geoffk.org> Fri, 03 October 2014 02:05 UTC

Return-Path: <geoffk@geoffk.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 D00441ACFD8 for <tls@ietfa.amsl.com>; Thu, 2 Oct 2014 19:05:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 S6EAOOuoENXF for <tls@ietfa.amsl.com>; Thu, 2 Oct 2014 19:05:52 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22EE01ACFD7 for <tls@ietf.org>; Thu, 2 Oct 2014 19:05:52 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 0368033D08C; Fri, 3 Oct 2014 02:05:50 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Andrei Popov <Andrei.Popov@microsoft.com>
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> <64cfd9c21a3f430287b7a0d30908b007@BL2PR03MB419.namprd03.prod.outlook.com>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: 02 Oct 2014 19:05:50 -0700
In-Reply-To: <64cfd9c21a3f430287b7a0d30908b007@BL2PR03MB419.namprd03.prod.outlook.com>
Message-ID: <m2tx3lsy9t.fsf@localhost.localdomain>
Lines: 44
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/o5jOhhHNB2V3iWucohQHkhZh4gE
Cc: "tls@ietf.org" <tls@ietf.org>
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 02:05:55 -0000

Andrei Popov <Andrei.Popov@microsoft.com> writes:

> 2. "TLS servers MUST NOT select an RC4 cipher suite" is too
> strict/constraining/hard to deploy/etc.
> If we removed this MUST NOT, this would not be a prohibiting-rc4
> draft, but a best practice recommendation. We have TLS-BCP for
> recommendations. The idea of prohibiting-rc4 is to completely remove
> a weak cipher suite.

I support this, and especially the logic behind it.

> 3. But there are other weak cipher suites: EXPORT, DES, RC2, MD5... 
> Totally agree; these need to be removed as well. However, we've been
> discussing prohibiting-rc4 for over a year now. I think we should
> let this draft proceed so that we can make some progress. I don't
> mind authoring a new I-D (or I-Ds) prohibiting EXPORT, DES, RC2, MD5
> ciphers.

I support this and the logic behind it too.

I would also support creating a new I-D.  TLS 1.1 already says about
the EXPORT ciphersuites:

   TLS 1.1 implementations MUST NOT negotiate
   these [EXPORT] cipher suites in TLS 1.1 mode.  However, for backward
   compatibility they may be offered in the ClientHello for use with TLS
   1.0 or SSLv3-only servers.  TLS 1.1 clients MUST check that the
   server did not choose one of these cipher suites during the
   handshake.  

RFC 5469 says that for DES and IDEA,

   If a TLS library implements these cipher suites, it
   SHOULD NOT enable them by default.  Experience has also shown that
   rarely used code is a source of security and interoperability
   problems, so existing implementations SHOULD consider removing these
   cipher suites.

which is a bit less then the absolute prohibition I'd like, and not
all implementations have actually disabled these ciphers---indeed some
servers in the wild will still negotiate these ciphersuites,
particularly TLS_RSA_WITH_DES_CBC_SHA.

We don't seem to have anything about MD5.