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

Alyssa Rowan <akr@akr.io> Thu, 02 October 2014 17:02 UTC

Return-Path: <akr@akr.io>
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 F14431A893B for <tls@ietfa.amsl.com>; Thu, 2 Oct 2014 10:02:13 -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 AyyfgSt20z26 for <tls@ietfa.amsl.com>; Thu, 2 Oct 2014 10:02:12 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 496DB1A893F for <tls@ietf.org>; Thu, 2 Oct 2014 10:02:07 -0700 (PDT)
Message-ID: <542D850E.2060900@akr.io>
Date: Thu, 02 Oct 2014 18:02:06 +0100
From: Alyssa Rowan <akr@akr.io>
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.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>
In-Reply-To: <CADMpkcJEt4e7LJAY+FsFcbyQE2x3SXsaOW3bffV4U2oN9EUKrg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CCJ-Tq0-5r7NebLI935wKsnijUg
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: Thu, 02 Oct 2014 17:02:14 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2 October 2014 15:44:37 BST, Bodo Moeller <bmoeller@acm.org> wrote:
> It seems to me that having a bit of a gray area then is
> unavoidable ... and often you *do* need some latitude in
> backwards-compatible cases, assuming you support these to achieve
> backwards-compatibility.

As I've pointed out, if you're forced into backwards compatibility
with rusty legacy, 3DES is, though crappy, a less crappy choice than RC4.

As Rich points out, just because legacy devices are indeed out there
doesn't mean that they do TLS safely, and doesn't mean we shouldn't
prohibit unsafe practice like using weak ciphers.

> (www.microsoft.com, for example, does allow RC4 cipher suites when 
> using TLS 1.0, which would be incompatible with that MUST NOT,
> since it expressly applies to TLS 1.0 too.)

This draft is a warning to implementers and deployers of TLS that they
MUST change their allowed ciphersuites to completely exclude RC4,
because RC4 isn't safe enough to use in TLS (or really for any purpose
anymore).

Pointing to examples of RC4 still being allowed in the wild only
further demonstrates the need for this draft as-is.

> If the spec isn't aligned with reality, that's a bit of a problem. 
> You shouldn't have to interpret a MUST NOT as a SHOULD NOT.

Reality is, unfortunately, that RC4 should have obsoleted years ago.
That is indeed a bit of a problem - one we now need to fix rapidly.

> Maybe the spec should have strict MUST NOT requirements for TLS
> 1.2, but make mere recommendations for the legacy protocols?

No, not sure I follow your reasoning here: RC4 is no less weak when
used with SSLv3 or TLS 1.0 than with TLS 1.2. Might even be weaker, if
there's a way to trick a server into selecting it (hence the fallback
SCSV draft). I see no reason the prohibition ought not be absolute.

Regarding obsolete ciphers such as RC2 and DES, I don't think the need
to prohibit them is quite as urgent, because people aren't actually
using them in the wild. (Well, not _many_ people, anyway.)

I would indeed support their deprecation - but perhaps in a separate
document, as I'm concerned that any unnecessary delay with this one is
another day that RC4's still actively being used by many, even when
better alternatives are available - which is another day of traffic
Eve can record - and, I fear, break, now or any time later at their
leisure.

The sooner we can proceed, the sooner we can start working to fix that.

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJULYUNAAoJEOyEjtkWi2t6cZYQAK/LJRHi9BjIDkyQgTGiSRrl
D7tawBqIyR/0IErV+bz1UrIvCifx4Lrn99qscMEfuklRjEmJ0QJa2qAYYB51LPOi
+zxphHrXwSA3iofgTqawPLq3A+N6mHM38TBKhhxRW8oF8Y7zcNtvIAFRAWZ3f5zM
vAN9GW4MJLbDYpbu4mxsJ1qLhZ8+Ojo3IIcJnhhhZYJ6pdlwoQzWlUOzd9itdbbo
Nn1DnZUvJBIHS8uGclFamZDlg+f4b4Djy6msQH1C2VdQkgaZxAHr/E+gaU/whpTY
Qfc9FooyaEH5tpAiKDfcTjyhhgWatsJQhx39I+Mt/t9Ht+H7FR3kxHB4XRCgiSyg
ASvobV/ATo3aSflqeUrO7myS7cJWXH2gHCVKCXIw0JxIT40j5q08VtUsd9b1Db9Z
HaXWibvBYcngkGvpHC5CW+P7vNDP0x4wUPNaa/w8KBO7dZcqwFKC7BHpcekIKt4A
yQjiPAG2tXDmqd5Y9GykcJU0kFZucPbulcGnNW1KeAoZhgBmUzsDVq0gw6U+VQ/J
1vFcwG2DlCl1ICBxHEjCcNAiJ3K0MX5Dz6wMD2NaQ1CvlqU3g7HWHJha0VbMsQns
P1SLllT8Kjmm/KpJyqiYE0hbuYfWnUPv5BeKW5eVuBzZA2D8maHSBilIZIvPbv8K
a1qiinNciHhRIs14X8kV
=GfyS
-----END PGP SIGNATURE-----