Re: [TLS] chairs - please shutdown wiretapping discussion...

Stephen Farrell <> Tue, 11 July 2017 19:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A73512EC29 for <>; Tue, 11 Jul 2017 12:41:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fx_lVQdSvJeu for <>; Tue, 11 Jul 2017 12:41:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6DA7112EC0B for <>; Tue, 11 Jul 2017 12:41:00 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1225FBE38; Tue, 11 Jul 2017 20:40:59 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zhd8Wt8VvcdP; Tue, 11 Jul 2017 20:40:57 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id B6737BE2F; Tue, 11 Jul 2017 20:40:57 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1499802057; bh=gB7Bw7PVDvO29XzO370DVexwSQBv+bUAt2TRHf7zBVE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=HmjtqybD2rviksyasweoIlROVoxSZbpcLqVvYTuLKrIexySYiEPU3tAq6zk6YG+xa 7uMpU7QwyLB4sDrdOeCuJbqhs0zC/4nvAZ6FvIfpgKKOsaXz2bjtcsveZxjmZYM1w1 O/m1mTJUdoa6xUFaOKypOE0JnnLJWo5tI/wi3dfs=
To: Christian Huitema <>,
References: <> <> <> <> <> <> <> <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Tue, 11 Jul 2017 20:40:57 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="L77iVtv85SjDtxD4BAFmiOfgnSN2xTbdg"
Archived-At: <>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Jul 2017 19:41:02 -0000

On 11/07/17 20:11, Christian Huitema wrote:
> For various reasons, some implementations may be tempted to use static
> (EC) DH private key. Using such keys lowers the security guarantees of
> TLS 1.3. Adversaries that get access to the static (EC) DH private key
> can now get access to the content of the communication. Adversaries that
> acquire the key in real-time can compromise the confidentiality of the
> conversation. Adversaries that acquire the key later can use it to
> access the content of recorded sessions, thus breaking the forward
> secrecy promise of the protocol. TLS 1.3 clients should detect the use
> of static (EC)DH keys by corresponding servers, and should treat servers
> using such keys as compromised. Clients can perform this detection by
> comparing keys proposed by servers at different time, or by cooperating
> with other clients to compare the keys proposed to them by servers.

I generally like the idea of such text but I'm not at all
sure client detection is really feasible in the general
case. It'd seem possible for a server to hold a rather long
list of re-used static DH values and unlikely for normal
clients to detect those. And it also seems like an arms race
too, e.g. if a special zmap-like survey was used to detect
this kind of bad crypto. Still worth testing for no doubt,
(it'd make for a nice academic publication) but I'm not sure
detection could be sufficiently probable that we could make
the statement above.

Speaking of text changes though, if this wiretapping scheme
were to be adopted in any sense, there would be a load of
tweaks to text in tls1.3 needed as a result - starting with
the abstract to -21 for example as we could no longer say
that TLS is "designed to prevent eavesdropping" without a
highly embarrassing qualifier. (Hence my request to not have
this discussion until after DTLS1.3 is done - and chairs if
you're reading this please do reconsider.)