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

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 03 September 2014 18:52 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 7F1EF1A04F8 for <tls@ietfa.amsl.com>; Wed, 3 Sep 2014 11:52:50 -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 3z_iZtxeYqXj for <tls@ietfa.amsl.com>; Wed, 3 Sep 2014 11:52:45 -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 ADDA51A04C5 for <tls@ietf.org>; Wed, 3 Sep 2014 11:52:45 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B7FFC2AAFE5; Wed, 3 Sep 2014 18:52:44 +0000 (UTC)
Date: Wed, 03 Sep 2014 18:52:44 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20140903185244.GV14392@mournblade.imrryr.org>
References: <54048985.1020005@net.in.tum.de> <CAMeZVwtQ09B6Ero2C=75m5JdAYnEAENNcESd_gg_Ro2UhA9dyA@mail.gmail.com> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5407574B.5060708@net.in.tum.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/a8mZWJaqW2K7kDkjFAN5qdHLdBk
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: Wed, 03 Sep 2014 18:52:50 -0000

On Wed, Sep 03, 2014 at 08:00:43PM +0200, Ralph Holz wrote:

> > This is still too strong.  Local MTA to Mail-Store LMTP is an
> > application protocol.  It is a fine use-case for NULL ciphers.
> 
> I hear you (and the others), but balancing the purpose of the BCP with
> such requirements as you mention leads me to believe we should favour
> the solution I proposed. I added one more thing, though:
> 
> "Note: TLS implementations MAY retain code for the NULL cipher to allow
> specialised purposes like debugging, custom solutions, etc."

I can probably live with that.

> That "custom solution" - to me - seems to address what you describe. I
> see no other way to balance the requirements.
> 
> If the vote were black/white between dropping and keeping, I'd favour
> dropping, by the way. I'd rather protect the many.

While probably not an issue in this case, we need to be careful
when trying to "raise the bar" to "protect the many".  If the bar
is raised too high, the obvious operator solution is to switch to
cleartext, no security impediments there. :-(

Don't let the perfect be the enemy of the good. Ciao.

-- 
	Viktor.