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

Christian Huitema <huitema@huitema.net> Tue, 11 July 2017 20:55 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9DBD129A97 for <tls@ietfa.amsl.com>; Tue, 11 Jul 2017 13:55:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 LkjNJrk0-X1m for <tls@ietfa.amsl.com>; Tue, 11 Jul 2017 13:55:41 -0700 (PDT)
Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36BF6127869 for <tls@ietf.org>; Tue, 11 Jul 2017 13:55:41 -0700 (PDT)
Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1dV2C3-0001I8-CK for tls@ietf.org; Tue, 11 Jul 2017 22:55:40 +0200
Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1dV2BT-0007IW-St for tls@ietf.org; Tue, 11 Jul 2017 16:55:38 -0400
Received: (qmail 12921 invoked from network); 11 Jul 2017 20:55:02 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.115]) (envelope-sender <huitema@huitema.net>) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 11 Jul 2017 20:55:01 -0000
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Ted Lemon <mellon@fugue.com>
References: <E9640B43-B3AD-48D7-910D-F284030B5466@nist.gov> <CY4PR14MB13688370E0544C9B84BB52A3D7A90@CY4PR14MB1368.namprd14.prod.outlook.com> <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <CY4PR14MB1368BA01881DD9495FE86DF0D7A90@CY4PR14MB1368.namprd14.prod.outlook.com> <d806a69c-af30-c963-a361-91075332a61b@cs.tcd.ie> <F87D7646-DC53-4EF8-A2D8-D0939A0FB351@vigilsec.com> <b9001044-83d7-805c-2a49-c2780401bbf8@cs.tcd.ie> <C4125902-CA3A-4EA8-989B-8B1CE41598FB@fugue.com> <0c87999c-9d84-9eac-c2c4-0f1fc8a70bdb@cs.tcd.ie> <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com> <fa6e64a2-b1c8-9c55-799b-b687b830a246@huitema.net> <26848de4-ce08-8ebd-bd67-ed3af3417166@cs.tcd.ie> <CD0E0745-EA72-41D9-87F6-B40369ED6A70@fugue.com> <bcda4dab-3590-9162-5f5c-c453f7a610ac@cs.tcd.ie> <2500C1F7-480E-44C9-BDB0-7307EB3AF6C2@fugue.com> <d9870cd0-476c-b255-16bd-594e24cd91f0@cs.tcd.ie>
Cc: tls@ietf.org
From: Christian Huitema <huitema@huitema.net>
Message-ID: <eadd52ec-3f72-7483-864b-8a5251d94bfc@huitema.net>
Date: Tue, 11 Jul 2017 13:54:40 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <d9870cd0-476c-b255-16bd-594e24cd91f0@cs.tcd.ie>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="BJ2dSchcRNGe5sVOdQDDFOBmlNIT8VQXk"
X-Originating-IP: 168.144.250.230
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.26)
X-Recommended-Action: accept
X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJZYP2pkjqshrWYL747BjInHND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23rWrWuqcVlBWkg/OVacUArIryRN09Lit7hjFm LHo/TaVdoeXz5DeswnB8+wRFZgNkYOEkjsX7F8KmpUaZQHV+SejOO+5k046wqf0SEutzqoO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpOWca0Z0beD6jMx95O4U5K/6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyXNjoTjYggJ9y67VShSDm/neNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj236N2IVdgBdepwvDBBcDOz9LNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxh8XBHmF2hIeyKfJwZiM12egGl1aPxAtivmw 3hSDPS17GFJHu7VqC2lywbop/MU3ZC2wErj03uQL9OSP3oAqkbgmxYRXOZgzdAQCjuYKoBVKyLoA 6S28+bT6JBt5hIe9NsT+zJGLhBRfUiVo7tDfe93qlFit1PvkPF7Ua1AOSWcb0i13zjCiwPgdt77s k1WBMw==
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/llAh4uQIZT7lbvSwEwmsOT3gkhs>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 11 Jul 2017 20:55:43 -0000

On 7/11/2017 1:31 PM, Stephen Farrell wrote:

> PS: There are also genuine performance reasons why the same
> DH public might be re-used in some cases, so there would be
> false positives in a survey to consider as well.

Well, yes. The classic argument is performance. Saving the cost of
exponentiation, computing G^X once for many session instead of once per
session. But you reap most of the benefits of that optimization with a
fairly small number of repetitions. Performance alone is not a good
reason to use the key over extended period, not to share the exact same
key between all servers in a farm. The fact is that wide reuse of the
same (EC)DH private key does compromise the security of TLS -- including
an obvious issue with forward secrecy.

I get your argument that this can turn into a cat and mouse game.
Clients detect a bad behavior, misbehaving servers adapt by tweaking the
behavior to avoid detection, clients get smarter, etc. On the other
hand, documenting the attack clearly marks this key reuse as not
desirable and not supported. The public statement provides an argument
to developers to "just say no" when asked to add the wiretap "feature".
Detection by clients also provides a clear signal to enterprises that
they should really find another way to solve their problem.

In any case, I just submitted PR #1049
(https://github.com/tlswg/tls13-spec/pull/1049).

-- 
Christian Huitema