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

Christian Huitema <huitema@huitema.net> Tue, 11 July 2017 19:11 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 664BD12EC44 for <tls@ietfa.amsl.com>; Tue, 11 Jul 2017 12:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 epdzqFcN2yrX for <tls@ietfa.amsl.com>; Tue, 11 Jul 2017 12:11:17 -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 7DFF0129B66 for <tls@ietf.org>; Tue, 11 Jul 2017 12:11:17 -0700 (PDT)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1dV0Z1-0001dF-L9 for tls@ietf.org; Tue, 11 Jul 2017 21:11:16 +0200
Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1dV0Yz-0004Yk-EV for tls@ietf.org; Tue, 11 Jul 2017 15:11:14 -0400
Received: (qmail 908 invoked from network); 11 Jul 2017 19:11:11 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.115]) (envelope-sender <huitema@huitema.net>) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 11 Jul 2017 19:11:11 -0000
To: tls@ietf.org
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>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <fa6e64a2-b1c8-9c55-799b-b687b830a246@huitema.net>
Date: Tue, 11 Jul 2017 12:11:09 -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: <6DA3E09E-5523-4EB2-88F0-2C4429114805@fugue.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: 168.144.250.232
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.40)
X-Recommended-Action: accept
X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJackVDEeh/s63C3hq8BP19aND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23X7am35/7EOtH5rXShxpFWeoI9GlgXFbGvhvB 71hlmrpgFT16N0zEjVhBqciCa6CjYOEkjsX7F8KmpUaZQHV+ST61TfxIvi8LwOTvVrRIhaC2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpIuW2VxLnS94njDgTNmyTXH6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGydJe2aRMEivIROM7I6TwJEDeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj236N2IVdgBdepwvDBBcDOz9LNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxh8XBHmF2hIeyKfJwZiM12egGl1aPxAtivmw 3hSDPS17cFawG5ASbLL3iaPgHmqzBy2wErj03uQL9OSP3oAqkbgmxYRXOZgzdAQCjuYKoBVKyLoA 6S28+bT6JBt5hIe9NsT+zJGLhBRfUiVo7tDfe93qlFit1PvkPF7Ua1AOSWcb0i13zjCiwPgdt77s k1WBMw==
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/FDEKwdLil7P6_WEZNbK-b1d8cWo>
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 19:11:19 -0000


On 7/11/2017 6:11 AM, Ted Lemon wrote:
> What the draft actually says is that you can install a fixed key on the server rather than generating new keys every time, and then that fixed key can also be installed on monitoring software.   This is, I believe, the actual intended use of the proposal.
>
> It’s also true that you can just exfiltrate every key as it’s generated, but that’s not what’s being proposed and would not, I think, suit the needs of the operators who are making this proposal.
>
> I don’t see how you could mitigate against deliberate key exfiltration.   At some point you really are relying on the security of the endpoint.   But being able to detect repeated keys is useful for preventing pervasive monitoring: it requires the monitored either to have access to the key generation stream in realtime, or to request the key for a particular conversation.
To paraphrase what Ted says using my own words, the use of static (EC)DH
shares is an attack against the integrity of the TLS 1.3 protocol. I
think this attack should be documented in the TLS spec, probably in
Appendix E since the attack compromises security properties of the
protocol, or maybe in Appendix C if we want to outline the
implementation issues. Some text like:

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.

-- Christian Huitema



-- 
Christian Huitema