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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 02 September 2014 15:23 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 62F4D1A0424 for <tls@ietfa.amsl.com>; Tue, 2 Sep 2014 08:23:12 -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 equel1M5_X92 for <tls@ietfa.amsl.com>; Tue, 2 Sep 2014 08:23:10 -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 6AB9B1A0385 for <tls@ietf.org>; Tue, 2 Sep 2014 08:23:10 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8BCC22AB2B7; Tue, 2 Sep 2014 15:23:08 +0000 (UTC)
Date: Tue, 02 Sep 2014 15:23:08 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20140902152308.GB14392@mournblade.imrryr.org>
References: <54048985.1020005@net.in.tum.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <54048985.1020005@net.in.tum.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HQ7jVQXbDRMcxJ05lFO_6wfKtKQ
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: Tue, 02 Sep 2014 15:23:12 -0000

On Mon, Sep 01, 2014 at 04:58:13PM +0200, Ralph Holz wrote:

> Practices "Recommendations for Secure Use of TLS and DTLS"
> 
> 	http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-02
> 
> => "Implementations MUST NOT negotiate the NULL cipher suites"
> 
> This may lead to implementations dropping NULL (or making it hard to
> enable).
> 
> My personal take as one of the authors of the BCP is that the UTA WG
> should process UNLESS someone has a use case that is relevant on the
> same scale, or thinks the above statement does not hold in general.

Postfix supports authenticated NULL ciphers for communication
between an MTA and local (127.0.0.1 or ::1) LMTP server.  Encrypting
local IPC is just a waste of CPU.  Yes, this is a specialized use-case.

This can also be useful for access-controlled hand-off between
reverse HTTP proxies, and web applications that support client
certificates.  These are sometimes used to implement GSSAPI SPNEGO
support in front of application that don't support GSSAPI.  The
application is configured to listen on 127.0.0.1, but is then
vulnerable to impersonation attacks from anything running on the
host.  With authenticated NULL ciphers, the connection can be
restricted to just the front-end reverse proxy.

-- 
	Viktor.