Re: [TLS] The risk of misconfiguration

Manuel Pégourié-Gonnard <mpg@polarssl.org> Thu, 08 May 2014 08:28 UTC

Return-Path: <mpg@polarssl.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 1F5441A04A3 for <tls@ietfa.amsl.com>; Thu, 8 May 2014 01:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.394
X-Spam-Level:
X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, 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 kT80r-EjwqjG for <tls@ietfa.amsl.com>; Thu, 8 May 2014 01:28:25 -0700 (PDT)
Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 864FA1A04A2 for <tls@ietf.org>; Thu, 8 May 2014 01:28:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=sZoInYBZrTb6gYOY8VBPUFyNGpnO12JfPYRGs5VcAvg=; b=j1L+5pngW6loWAD9mQUkthCbIh5UGxY6+jCf3oIAiO5I+fWfxtIXlTZDu4eaq6bVDB2ONvSfar/BQTlQwecvz3sdqtVNTnL+e6rDP0Gp6ilyC32ESMIeQerAlvA2hKNPgg5/Xsfc59HbljGGOSnRp7Am82/JxU8K/XntjfQY660=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1WiJfz-00058O-MN; Thu, 08 May 2014 10:27:37 +0200
Message-ID: <536B401E.8070502@polarssl.org>
Date: Thu, 08 May 2014 10:28:14 +0200
From: Manuel Pégourié-Gonnard <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Alyssa Rowan <akr@akr.io>, tls@ietf.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>
In-Reply-To: <536A6F8C.7020702@akr.io>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/m9k5jEgLHASxtbJNrEYnW3_RJ8s
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: Thu, 08 May 2014 08:28:27 -0000

On 07/05/2014 19:38, Alyssa Rowan wrote:
> Meanwhile aDH denies us that option, and broadcasts our MITM
> susceptibility to Mallory.
> [...]
> So, what use of anon_DH ciphersuites aren't addressed better by this
> method, especially given the very clear additional perpass risk of
> keeping them in TLS v1.3 that we've outlined here? How can we do better?
> 
Side note: it seems to me that perpass is short for pervasive passive
(surveillance). Would you say the MitM risk you're describing here qualifies as
passive? (It might still be cheap enough to be implemented at a large scale by
some organisations doing pervasive surveillance, which is a serious problem indeed.)

Anyway, I'm not sure an adversary needs aDH as a marker to rather efficiently
guess which clients are going perform some kind of server authentication: for
example, if the server's cert is self-signed, and the client doesn't perform a
TLSA lookup, and the client and the server don't belong to the same
organisation, it's quite likely that the client isn't validating. I don't think
an adversary needs to be 100% sure here. They can probably also just try to MitM
clients and remember for which ones it worked.

Manuel.