Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP

Bodo Moeller <bmoeller@acm.org> Fri, 05 September 2014 13:31 UTC

Return-Path: <SRS0=3ycO=56=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 BDF331A06B8 for <tls@ietfa.amsl.com>; Fri, 5 Sep 2014 06:31:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.196
X-Spam-Level:
X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, 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 yrSQDIoyXDtl for <tls@ietfa.amsl.com>; Fri, 5 Sep 2014 06:31:01 -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 AE4721A06B4 for <tls@ietf.org>; Fri, 5 Sep 2014 06:31:00 -0700 (PDT)
Received: from mail-yh0-f43.google.com (mail-yh0-f43.google.com [209.85.213.43]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0Lz2g4-1YTlw110Oe-014Eta; Fri, 05 Sep 2014 15:30:57 +0200
Received: by mail-yh0-f43.google.com with SMTP id f73so7487273yha.30 for <tls@ietf.org>; Fri, 05 Sep 2014 06:30:56 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.0.136 with SMTP id 8mr14874702yhb.27.1409923856027; Fri, 05 Sep 2014 06:30:56 -0700 (PDT)
Received: by 10.170.129.17 with HTTP; Fri, 5 Sep 2014 06:30:55 -0700 (PDT)
In-Reply-To: <5409B592.7070801@fifthhorseman.net>
References: <r422Ps-1075i-64A8CB473A3A4501BBB2C3138C71A13E@Williams-MacBook-Pro.local> <5409B592.7070801@fifthhorseman.net>
Date: Fri, 05 Sep 2014 15:30:55 +0200
Message-ID: <CADMpkcKa-A-qGYLnZpFVtFcXVnbBkkBAu0V8zcfk+M03Mm1_AQ@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="089e01635062995a1b0502517a56"
X-Provags-ID: V02:K0:mVLVAqlsnElJ+xTPwhaqC+j+Huxy09uT9kT6X03H93L 8GSutdwEtkkXA1ElZYS/SY6Te7dksZrydJ/8lnWHMYtShhVxsc CQ2vLTR91lbTzRakd/y/VzQTfiWnqYt3eOA9xln3e4FN98CrjT lepTHPsQ89pd+g0HuTcmf8F98QUiHXzI8+Y7QFTL4VbWdjCMhr OU4kUgnJd6IwgGb736TA3V39fbn7igvJwcXUukwRyokCqlezip 5tyI4re3SyAAq/giOh7IGBTNE5ZDZfs76WgupR62ibWjbhIPai I4MJrWNpQU6fINEkLrN8bSDClEme/4YZq+gpHgl7F0z8ATZuvY 65T3c8jg4B3LtCkNk/EUy+wD4EJS9Jkjhvt3G7lk3d3ZwRrySx FcGPlZXKCawG3ZIMf2hM8BH44qganeJwgmPrAr7gh69mmzP5un eXJLf
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8xCKMEsaEmV9EXDgHp1WK5r2MGA
Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP
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, 05 Sep 2014 13:31:01 -0000

Daniel Kahn Gillmor <dkg@fifthhorseman.net>:

Are there any objections to including Victor's suggestion in the draft?


I actually think it would be more appropriate for the UTA BCP to expressly
confine itself to making recommendations for applications that *do* have a
desire for confidentiality, rather than trying to also regulate the wider
area of applications with more esoteric needs.

If NULL encryption cipher suites can't be enabled together with non-NULL
encryption cipher suites, you'd break any server that attempts to allow
NULL encryption for clients that decide they don't need encryption (e.g.,
because they're connecting to localhost) while supporting non-NULL ciphers
for clients that don't offer NULL encryption for whatever reason (e.g.,
because the implementor just doesn't like NULL encryption, which I think is
a position worthy of support).  Same for clients.  I'd rather prefer for
the BCP to avoid this quagmire entirely.

Bodo