IETF Logo Mail Archive

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

Bodo Moeller <bmoeller@acm.org> Thu, 02 October 2014 14:44 UTC

Return-Path: <SRS0=9UCi=6Z=acm.org=bmoeller@srs.kundenserver.de>
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 7E3381A044F for <tls@ietfa.amsl.com>; Thu, 2 Oct 2014 07:44:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.714
X-Spam-Level:
X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no
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 BNW5AZXlB-K7 for <tls@ietfa.amsl.com>; Thu, 2 Oct 2014 07:44:55 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F111A046F for <tls@ietf.org>; Thu, 2 Oct 2014 07:44:41 -0700 (PDT)
Received: from mail-yh0-f50.google.com (mail-yh0-f50.google.com [209.85.213.50]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0Lba15-1XyI4j2vmt-00lI4X; Thu, 02 Oct 2014 16:44:39 +0200
Received: by mail-yh0-f50.google.com with SMTP id a41so275210yho.23 for <tls@ietf.org>; Thu, 02 Oct 2014 07:44:37 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.140.97 with SMTP id d61mr3554120yhj.164.1412261077610; Thu, 02 Oct 2014 07:44:37 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Thu, 2 Oct 2014 07:44:37 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com>
References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <BA2DFF33-7B0C-4E87-9C0E-215933AED88F@akr.io> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com>
Date: Thu, 02 Oct 2014 16:44:37 +0200
Message-ID: <CADMpkcJEt4e7LJAY+FsFcbyQE2x3SXsaOW3bffV4U2oN9EUKrg@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="20cf303ea810dc788f050471a7fd"
X-Provags-ID: V02:K0:AkBBEsk3DJYbeBb0N88nJtZzJhsyjDxiSFXdUlYTPf3 ZYvmfvHLFgluBJoFgrW4BMO1ZRWCUo48XcacpU3xUg6GY6X6DF ytYPcmhyQF44C+xttBfr+fHyqymcOu/ZEy7Vxx6EB4zJ/LM9Tx uiRAcdK5FQkoa3K0Pytu3U634kLyAvb/gf7k9w0yKOwWhtkss3 HzJDNTLd5i5LxKK0WolV0xDY30try9VEMyQX+qw8wxxy/LBsWM +iPoFt4eYUGGJjCscQsz8wiFnSRLkVdX3VfjrW5sK2AhloMabR KdNs5RnmySRBDQABtfxD6XWNgJ/UZNqmhJXO+zpKziQURskaad sRmo5bPH93cd4XQ9GUzO6+7g4oWzrb6AFM9JdaSJIajSDcKic0 hozlDQhqLKzVSU+QL4YhOrXaBAzbgtfy8NM8OZ7Nv5PD3DbsVL t37oA
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7qf7xBFO1qXt7sJYfyEihyI1hOE
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 14:44:57 -0000

One technical issue here is that we keep updating specs that are also
(supposedly) "obsolete". I.e., "If you do that thing that you're not
supposed to do, here's how". 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.

(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.)

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.

Maybe the spec should have strict MUST NOT requirements for TLS 1.2, but
make mere recommendations for the legacy protocols? (As mentioned before,
it would be good to also document that various other ciphers like RC2 also
aren't a good idea to use, even which TLS 1.1 which has them in the spec.)

Bodo

v2.23.0 | Report a Bug | By Email