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

Yoav Nir <ynir.ietf@gmail.com> Tue, 11 July 2017 21:10 UTC

Return-Path: <ynir.ietf@gmail.com>
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 D2043129B36 for <tls@ietfa.amsl.com>; Tue, 11 Jul 2017 14:10:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 SrA__9JwMEWF for <tls@ietfa.amsl.com>; Tue, 11 Jul 2017 14:10:53 -0700 (PDT)
Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0998B129A97 for <tls@ietf.org>; Tue, 11 Jul 2017 14:10:53 -0700 (PDT)
Received: by mail-lf0-x244.google.com with SMTP id g21so484360lfk.1 for <tls@ietf.org>; Tue, 11 Jul 2017 14:10:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xFHjv19PeuzyPdm5u46vZ6kg6YvQRWm592z1h7X5BN4=; b=B1rBjLen0qQzzMcLcMKZIqXRU5IQj6+IdJrinTce+Ii8Ya/R3nnMUyain7Ce1n7bm0 Wk+ulrTaqJ9KpLHqRaD4vqmy7E0I/+0Sf4k46RUpJFZstDIwdBLkc3NcXpvVrBA5upFw qivqu7a7c2JHdbHMdyEipKAxQCkLlr3Yo784NwG/OSmnHL0A8RNrWDQIkfAEeRpmtCrR qz//gIkiCDm4q4JrdUs9bEBkC5MRnbEgSan+vEZPIIYeBfIrrwwzx1/U6Akb7K1gI4K5 43MfXW4XEhyowHd/0X6+WyQoXrDQX/kSXnZ4fR+Fe+zfONcrzp0yXtAMu4l/aFD0wnZe BEyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xFHjv19PeuzyPdm5u46vZ6kg6YvQRWm592z1h7X5BN4=; b=bJYG5OyjsO+6Q4JLHRmZcKLGNl9Iz4fCjdf8BWfJr/QKyjvxssKM0x8B21pXIiioSv ft8SRV9lJH0Kw8QdXqYSlV9ZXsx96wyqmMde04hbmJUBUgN6FpG6yxTav3bDC8sikvkc 41ZQ18zqX0HcyFVFUhZyRSFRPVpzZsPQXPIeBYw6+F05PNjo+Us73LrJmN9Iht8ZeRkX PfU9XcazdfbZMNf/wiqOz+eZI9bufSpuWlQ8rYYf8oQspAnBW+TO2OWDhiNBNMVplkIu HUkWoS/CB+IPA2DtMC9EDRC+zS4ux4S/VYoUsTwSpPmjf3z4JblNplwpO+jcGJ8sufYJ EM0A==
X-Gm-Message-State: AIVw113npMlz2asEPPAOuVb0WmbnW6RDCadIuUDMsW7+td0rzvqBUxzA RAO3C/of52G0GiuTETg=
X-Received: by 10.80.218.135 with SMTP id q7mr3808815edj.85.1499807451271; Tue, 11 Jul 2017 14:10:51 -0700 (PDT)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id g38sm197914edc.7.2017.07.11.14.10.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 14:10:50 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <ACB8BAC5-3560-43EF-B1FB-98F16B5B72B5@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_F1E128EB-14D9-4200-98EC-AD2F36FE17C2"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 12 Jul 2017 00:10:47 +0300
In-Reply-To: <eadd52ec-3f72-7483-864b-8a5251d94bfc@huitema.net>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Ted Lemon <mellon@fugue.com>, tls@ietf.org
To: Christian Huitema <huitema@huitema.net>
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> <eadd52ec-3f72-7483-864b-8a5251d94bfc@huitema.net>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/9Qs4A_KohuxIo2X5XUJ9uRkd6MM>
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 21:10:55 -0000

> On 11 Jul 2017, at 23:54, Christian Huitema <huitema@huitema.net>; wrote:
> 
> 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 don’t think the number of times (within reason) a key is used matters that much. It only matters whether or not it is exportable. If a server implementations generates a fresh key for every session and then stores it in a database that maps public key to private key, then that database can trivially be used to decrypt all traffic. Conversely, an implementation could generate a key in memory and use it until reboot and as long as it’s not exported, nothing happens.

I once implemented an ECDHE TLS server with an in-memory key that was rotated every 10 seconds. Since it was never written to disk (or even paged out) this practice did not compromise forward secrecy.

The draft also recommends rotating the keys, but I guess that would be far less often than once every 10 seconds. But that is not the crucial difference. The crucial difference is that these keys get exported.

Note, however, that the reason RSA ciphersuites were deprecated is that we are afraid that a stolen or coerced private key will compromise past sessions. If the session between us is recorded today and someone steals or demands my private key tomorrow, than they can decrypt our conversation from today.

This is not the case in (EC)DHE  ciphersuites in TLS 1.2 or 1.3. Any session that happens before this mechanism is turned on, is safe. Sessions can only be compromised after the server has enabled this feature, which is equivalent to handing over the RSA private key in RSA ciphersuites. That is not the forward secrecy issue that we wanted to solve by removing RSA ciphersuites.  If one of the parties to a conversation cooperates with the wiretap, this isn’t an attack.

Yoav