Re: [TLS] The risk of misconfiguration

Viktor Dukhovni <viktor1dane@dukhovni.org> Wed, 07 May 2014 18:47 UTC

Return-Path: <viktor1dane@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 0496D1A0268 for <tls@ietfa.amsl.com>; Wed, 7 May 2014 11:47:55 -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 lValQDETKf18 for <tls@ietfa.amsl.com>; Wed, 7 May 2014 11:47:53 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEB41A01D7 for <tls@ietf.org>; Wed, 7 May 2014 11:47:53 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3CBF22AA9FF; Wed, 7 May 2014 18:47:48 +0000 (UTC)
Date: Wed, 07 May 2014 18:47:48 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20140507184748.GY27883@mournblade.imrryr.org>
References: <CACsn0cnvV9c5aH5p8cD1fJEzF4dmNXBaEaHCfkX82AZqKOUYaQ@mail.gmail.com> <CAK3OfOgYr7d88iuxhXZcos55ymg0i_Q_GHNcXB+w7GRUaEj0bw@mail.gmail.com> <536A67D9.2070302@pobox.com> <CAK3OfOjTehkbKMg40_ZXGXOVjyHHY7UrxLmpyr7Mz00rRo+RLQ@mail.gmail.com> <536A6F8C.7020702@akr.io> <20140507181651.GX27883@mournblade.imrryr.org> <536A7AAE.9030801@akr.io>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <536A7AAE.9030801@akr.io>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/C-wGDmPppdGH_iiuxsxIHbTGzj0
Subject: Re: [TLS] The risk of misconfiguration
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: Wed, 07 May 2014 18:47:55 -0000

On Wed, May 07, 2014 at 07:25:50PM +0100, Alyssa Rowan wrote:

> > Even though the server has a certificate, it still enables ADH and 
> > AECDH cipher-suites.  Clients that don't authenticate the server 
> > negotiate ADH or AECDH cipher-suites.  If the server happens to 
> > publish TLSA RRs, some *clients* will omit ADH and AECDH from
> > their cipherlist because they are going to authenticate the
> > server's certificate.
> 
> ...and my point is, Mallory can trivially spot the difference and
> knows it can MITM those clients with impunity. That's more dangerous
> for perpass: specifically, ubiquitous surveillance of mail text and
> metadata via GCHQ's project TEMPORA.

This is not a compelling reason to remove protocol capabilities.
I am against banning power tools.  Build them as safely as possible
at reasonable cost.

Both NULL and ADH/AECDH ciphersuites have real use-cases.

  - NULL ciphers should never be offered in combination with non-NULL
    ciphers.

  - ADH/AECDH ciphers are building blocks for using TLS with channel-
    binding to implement non-X.509 authentication systems.  They
    also reduce server work-factor and handshake bloat when
    opportunistic clients don't check certificates.  Cipher-suite
    signalling is just one of many ways that Mallory can determine
    which clients she can attack undetected.

-- 
	Viktor.