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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 24 October 2014 14:01 UTC

Return-Path: <dkg@fifthhorseman.net>
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 BFA1B1A0158 for <tls@ietfa.amsl.com>; Fri, 24 Oct 2014 07:01:40 -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 UtqoGONRMnj2 for <tls@ietfa.amsl.com>; Fri, 24 Oct 2014 07:01:38 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 558021A014A for <tls@ietf.org>; Fri, 24 Oct 2014 07:01:38 -0700 (PDT)
Received: from [10.70.10.51] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 3D09DF984 for <tls@ietf.org>; Fri, 24 Oct 2014 10:01:35 -0400 (EDT)
Message-ID: <544A5BB3.4000506@fifthhorseman.net>
Date: Fri, 24 Oct 2014 10:01:23 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Icedove/32.0
MIME-Version: 1.0
To: tls@ietf.org
References: <CAO7N=i3gC=+qcgHU=aMKtRyT7tZV5fm=9gJii-=yOpcNECOEvA@mail.gmail.com> <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF651E4@USMBX1.msg.corp.akamai.com> <5449A667.9040105@cs.tcd.ie> <20141024133728.GI19158@mournblade.imrryr.org>
In-Reply-To: <20141024133728.GI19158@mournblade.imrryr.org>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="p2Xc0FPPHGjRLSNm0WovbuA8c9v9L4ol5"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fKlQGGyxIa_7pnD_zTK948gNs7Q
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, 24 Oct 2014 14:01:41 -0000

On 10/24/2014 09:37 AM, Viktor Dukhovni wrote:

> Leaving a cipher suite out is only practical once it is no longer
> the best shared cipher with any peers.  Thus we can if we wish
> disable EXPORT cipher suites since they are now never used, but it
> serves no purpose to do so (they are never used) beyond perhaps
> preventing accidents in which a grossly misconfigured peer selects
> EXPORT despite having better options.  I have never observed such
> an accident.

arguably, there are many such "grossly-misconfigured peers" right now
with respect to RC4 (usually because of misguided attempts to protect
against BEAST, aiui).  These are servers that support something other
than RC4, but select RC4 if a client offers it (even if it was the
client's lowest priority).

So the safest OS approach in the context of a strongly-deprecated cipher
$WEAK_CIPHER, for a client that is willing to ultimately fall back to
cleartext would be, for any given peer P:

 * connect to P and offer TLS without $WEAK_CIPHER
 * if that fails with "no cipher overlap", then:
    * reconnect to P and offer TLS with $WEAK_CIPHER
    * if that fails for any reason, then:
        * reconnect to P with cleartext.

This could probably be further improved by remembering which level of
fallback succeeded on previous attempts, and refusing to fallback further.

I don't think that any of this needs to go in the current draft, though.
 We should be explicitly and unambiguously rejecting RC4, and people
doing TLS-that-is-willing-to-fall-back-to-cleartext can just muddle
along violating the RFC, since they're not even claiming to make the TLS
communications property guarantees to their users anyway.

	--dkg