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

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 05 September 2014 21:49 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 2416E1A02E7 for <tls@ietfa.amsl.com>; Fri, 5 Sep 2014 14:49:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 YNDLI9NfzlPQ for <tls@ietfa.amsl.com>; Fri, 5 Sep 2014 14:49:12 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41ED41A0144 for <tls@ietf.org>; Fri, 5 Sep 2014 14:49:12 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 857BF2AB2C0; Fri, 5 Sep 2014 21:49:09 +0000 (UTC)
Date: Fri, 05 Sep 2014 21:49:09 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20140905214909.GZ26920@mournblade.imrryr.org>
References: <r422Ps-1075i-64A8CB473A3A4501BBB2C3138C71A13E@Williams-MacBook-Pro.local> <5409B592.7070801@fifthhorseman.net> <CADMpkcKa-A-qGYLnZpFVtFcXVnbBkkBAu0V8zcfk+M03Mm1_AQ@mail.gmail.com> <20140905134948.GK26920@mournblade.imrryr.org> <CADMpkc+Jw=C1=15KPt9eO1Er+JZEvXWtbGwzu1869y4nq30kFQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADMpkc+Jw=C1=15KPt9eO1Er+JZEvXWtbGwzu1869y4nq30kFQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FFPkDZD_I6_YqzBAinn9uNiwrgo
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
Reply-To: tls@ietf.org
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 21:49:14 -0000

On Fri, Sep 05, 2014 at 11:27:27PM +0200, Bodo Moeller wrote:

> > This is why my suggestion was specifically about the initiator
> > (client):
> >
> >     What is much more reasonable is that initiators (clients) should
> >     refuse to negotiate (should suppress any configured) NULL cipher
> >     suites when any non NULL cipher suite is enabled.  This prevents
> >     accidents, without breaking carefully considered NULL to NULL
> >     deployments.
> >
> > It leaves room for dual-purpose servers.
> >
> 
> Thanks for the clarification -- so I should have expanded the very terse "Same
> for clients": A client content with NULL encryption may want to offer
> non-NULL cipher suites in the same ClientHello in case the server doesn't
> accept NULL encryption for whatever reason (e.g., because the implementor
> doesn't like NULL encryption).

My thinking is that clients SHOULD NOT offer NULL, unless they
explicitly want NULL and know that it will be excepted.  Clients
that are laissez-faire about whether they get no encryption or not
seem negligent to me.  If they don't need whatever performance or
transparency for troubleshoots they might get from NULL, they should
just always go with non-NULL.

This is not a proof that the mixed case has no compelling scenarios,
just can't think of any as yet.

> As noted before, I think the BCP doesn't have to deal with issues like
> this, and instead should provide recommendations just for applications that
> want to achieve confidentiality.

That's fine too.  I was mostly trying to non-destructively accommodate
the impulse to do something normative along the lines of the original
proposal.

-- 
	Viktor.