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

Alyssa Rowan <akr@akr.io> Thu, 02 October 2014 11:41 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 D84E91A1A66 for <tls@ietfa.amsl.com>; Thu, 2 Oct 2014 04:41:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level:
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 s4apOiemlJu5 for <tls@ietfa.amsl.com>; Thu, 2 Oct 2014 04:41:05 -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 385BC1A1A4E for <tls@ietf.org>; Thu, 2 Oct 2014 04:41:05 -0700 (PDT)
In-Reply-To: <CADMpkc+j5kL1G=NA9phQy=nLAEUA1u8jfnNT=2wDp_S=kOTjNQ@mail.gmail.com>
References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <BA2DFF33-7B0C-4E87-9C0E-215933AED88F@akr.io> <CADMpkc+j5kL1G=NA9phQy=nLAEUA1u8jfnNT=2wDp_S=kOTjNQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
From: Alyssa Rowan <akr@akr.io>
Date: Thu, 02 Oct 2014 12:40:57 +0100
To: "tls@ietf.org" <tls@ietf.org>
Message-ID: <A3F7FDF7-F7C3-4704-8FDD-C1198C6EE1A9@akr.io>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gRypqY9M9r32x-suN88c9kksFL4
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 11:41:07 -0000

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

On 2 October 2014 11:44:06 BST, Bodo Moeller <bmoeller@acm.org> wrote:
>NULL is not currently a MUST NOT ... of course, having a cipher suite that intently and expressly does not encrypt is clearer than having a cipher suite that offers weak encryption, so it could make sense to have a MUST NOT for RC4 even as NULL remains around for use cases that need it.

Good point. I think that's clearer, although I also think use cases that need NULL are either poorly addressed by TLS or looking at it the wrong way as they own endpoints and can monitor traffic safely there, so keeping NULL around is IMHO more trouble than it's worth in TLS 1.3.

>Translated from prose, I think you're saying SHOULD NOT.

Except that I honestly do not think any "valid" reason exists to use RC4 at this point - which equates to MUST NOT.

Let's go through possible justifications for why I think that, and alternatives:

• Backwards compatibility with rusty legacy implementations? Fine, begrudgingly, choose 3DES, if you *really* must, but you probably SHOULD NOT (implementations that legacy are either out of support so you have bigger problems or can be security patched to use strong ciphersuites instead). It's too weak? (What, and you think RC4's better?) It's affected by BEAST? (Countermeasures against active attacks, disable scripting and Java, and 1,(n-1) splitting.) Bad performance? (There's plenty of 3DES hardware.)

• High performance? AES-GCM (in the presence of hardware support) or ChaCha20-Poly1305. Both faster than RC4 unless you're packing an 8-bit, and quite reasonable even if you are.

• A special deployment where both sides don't care about confidentiality? NULL, then (and repent at leisure when an attacker breaches your trusted network and you've egg all over your face).

Nope, I'm drawing a blank here. Like the 40-bit ciphers, it just doesn't make any sense to me. I can think of no valid reason to use RC4 where something else doesn't work better. Of course I can't force others into that viewpoint, but I can and will say anyone still using it after this RFC is published were warned about the dangers, and of better alternatives, and chose to ignore them to everyone's detriment.

- --
/akr
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI3BAEBCgAhBQJULTnIGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
jtkWi2t6ju8P/1fVlVOHR4GlaFKo1iLj14XzN0d3CzmfkJ97Mxp2qbqt9O0PxEth
gV8OADR1L/YOb5ihzDRczV04R5n3F0Var2mW1SX1bqFIHY6pODAJtqWKL3DzBjR+
B1FQPSCzX/eAxArDusoztdklxfNAWxoHSDWodQXtb2J+Zwuu2vUg9ucFP/oJiB9U
BYQw9VfpnsdkJNUXeEIEkMmWL1RpJlTUgepZIuD3YWRjDBHDpxJokyZYEu7wJHV/
d9mC9yEaJmncU5fMqHHupqitIfGzR3aPqDkjYaL/DrRXg+NXIue8EjqgV3wuqDAx
eL/lHzSxFNoCryF3upsfER1G+UHD9Alf6YOk2YXSes3yMaXCeGzpMrOq6qnigHAV
pc7zhRGkGUF1YCbdhN6PGNYzi/iLeSNtCowTSLbOdhENTvMNRxsObDTDeC7IAdgL
afo+BRwTPbh/4qHhA2hm1uQ4A6W+0LIQfYSKPKTS+EZ5Gmh4PmTstl27SJsjRPPr
AQs3aP3mMQg797Lc31zbTX3amtWOn5RAf3qCjmbBR6naJRLbP6tWb90d9Py+lS6V
k0z0yTJRQQIBteBr2PkYYXmHl9sVpfSx5kI8ub2+UQBykl/iNZeVq41rOA0i4fLx
gWv6KjUURN/aLlEFRYKs3ygt1jyTwrGZ4NydssLtJfc4e8YyhrvI+mi1
=lZx0
-----END PGP SIGNATURE-----