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

Bodo Moeller <bmoeller@acm.org> Thu, 02 October 2014 10:56 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 7A5EF1A02F4 for <tls@ietfa.amsl.com>; Thu, 2 Oct 2014 03:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.586
X-Spam-Level:
X-Spam-Status: No, score=0.586 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MANGLED_BACK=2.3, 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 3WGDqTtkiU0U for <tls@ietfa.amsl.com>; Thu, 2 Oct 2014 03:56:19 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (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 220EF1A01F9 for <tls@ietf.org>; Thu, 2 Oct 2014 03:56:19 -0700 (PDT)
Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) by mrelayeu.kundenserver.de (node=mreue001) with ESMTP (Nemesis) id 0M5CrX-1YS1Yl2QQx-00za3G; Thu, 02 Oct 2014 12:56:16 +0200
Received: by mail-yk0-f174.google.com with SMTP id 142so834316ykq.19 for <tls@ietf.org>; Thu, 02 Oct 2014 03:56:14 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.2.164 with SMTP id 24mr3797432yhf.126.1412247374527; Thu, 02 Oct 2014 03:56:14 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Thu, 2 Oct 2014 03:56:14 -0700 (PDT)
In-Reply-To: <20141002102602.3651570f@hboeck.de>
References: <20141001231254.5238.71176.idtracker@ietfa.amsl.com> <20141002102602.3651570f@hboeck.de>
Date: Thu, 2 Oct 2014 12:56:14 +0200
Message-ID: <CADMpkcLd6WWFrxcC72vtVrLrDikt3s2KEUfYROmUxm_wAptg6Q@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=089e011823aa18042605046e77a0
X-Provags-ID: V02:K0:M68/gowJ/TUhc2m8YiWs02sWQc1fH6G3Zy6VfoVUm/C DVjK0BD/XCilZpOcDSQtP7OhCpOIE67+JphH0Qh3JoiNUwB9lU UqbGD8evKGUJhBiqA9R9tnQz3rWfddNrXHfzOzNa9S1YhdPcOZ 6aTL3tNkHWB0j5vK9qGUGgo18j4+0/3CAw/m4IP6QaSpp7uZQX 16/9fNNKUL/l1WHqalrU/Xdx31nsf/PE6gJIl6BGAIT9On58CN BEj7Gk+U62b2WCWgn7TVdBROEyG4wFuo4Rzs+FSsOrAxxJEFD/ NuME+8osdT9txQAy3R7tjDERrWQSMBLrx0Mf6yZUbTnsjV2lD+ ZQXnWY3vzgoNBxzofXxUkm6UJ89r7tYzeTVGXidgl5Ef6TurXe PseU5tpf/cq4Z8+eASQsrs3aluyMsERipXn1A+7JtiW8zh8AsN JksDQ
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MlsxVcxTM2PR0T3sS4Ik_4Loz5w
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:00:22 -0000

Hanno Böck <hanno@hboeck.de>de>:


> There is currently no such RFC for RC2 or DES. Both are - considering
> current RFCs - perfectly valid ciphers according to RFC 2246.
>

Should we change this to "forbid RC2, DES and RC4" ?


The reasons that this spec talks only about RC4 presumably are that

(1)  only RC4 made it into the TLS 1.2 spec, and
(2)  RC4 currently has much more widespread implementation support (and
practical deployment).

The I-D, however, says "This applies to all TLS versions, and updates
[RFC5246], [RFC4346], and [RFC2246]", so (1) is not a good reason (it would
seem cleaner to say something about the other ciphers too, for the older
protocol versions); and (2) isn't a good reason either (the spec should
stand for itself, not just provide the delta on top of current folklore
knowledge that certain ciphers are out).

So I think a more comprehensive cipher suites MUST NOT / SHOULD NOT
document would be appropriate. (40-bit encryption already is an explicit
MUST NOT for TLS 1.1, but is there any spec that clearly speaks against
using it with TLS 1.0?)

Bodo