Re: [TLS] Requiring that (EC)DHE public values be fresh
Brian Smith <brian@briansmith.org> Fri, 30 December 2016 00:29 UTC
Return-Path: <brian@briansmith.org>
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 6BB9F129562 for <tls@ietfa.amsl.com>; Thu, 29 Dec 2016 16:29:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.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 FNyZiVcRwjl7 for <tls@ietfa.amsl.com>; Thu, 29 Dec 2016 16:29:08 -0800 (PST)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 0A08F129486 for <tls@ietf.org>; Thu, 29 Dec 2016 16:29:08 -0800 (PST)
Received: by mail-it0-x22a.google.com with SMTP id x2so222823908itf.1 for <tls@ietf.org>; Thu, 29 Dec 2016 16:29:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IwVvtKT3dBDTCkH/sFG9i5HN3CW2O2FLiyiSzkY48BU=; b=u+kIPbdzdoYjOCp5xiLJ6CcFgMWh83Q13VuHZAaJ0cKLtVZ56qrD6LNPLMVqS/PFuI Kc46Ep8qxrPL5+/ITjTSi+zuSf1wiWHyxlKtGzb871SWuUvmetWfftHEdZTXp4L/1Y0k Op08RLyo5D1XyTKIV+YTmlSyxJrX878B/6HHtM4bniHL+SalWpNzXoWuRb/WJ9wvd/9w GHCy83xRWF/0kl0uZUuVxEVVJfHXLP7iV5vMBQhik5z+EhloBQVNMWI77glcl6uxqKHM I7XpeJYRt3oD38Lvb+9c82vWAQ72FMBM1WwZ8sAMiAH3WndB8xCVOVW50R030qM2A+2A HAiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=IwVvtKT3dBDTCkH/sFG9i5HN3CW2O2FLiyiSzkY48BU=; b=egrFdLBP5ByMOUfyH3ou9k+c+lHtkSU1qXWTdYr/GcpFdSAtjiOBwtzPKgdGjVduMw SkRTAp97+OEaieOGhtM/6F/GcIBOEJAAR8Mnl7IoARD04c/x2E66NsrOW6J5bUT/QeJP iqI3bew3zZE2CRuln9F5Yu3QfKLY9hFFEVW+WYZ9I6mR4sgyCVFybge39ypJiiey4qIe 1FaZzASaSsCmAfHhvnGlwqdabClJj8ZMlfbn8kDlC8WY2qDJa+ckrTqtolExcXy80Egj wkypjJK3Jsrs8R1etwLfy8nWZoHn962Wv1fHmUVlAIVvu/n0dWd065k4xCR92bi2N5Vc OOTQ==
X-Gm-Message-State: AIkVDXJYnFKcPbmtqUqEd/hbQj/VcJjrDI2qc4w8pHUQKRCA7aOAIn8KfHkNF/k6dPvLnS1NrMZ6wB1TByBi7w==
X-Received: by 10.36.54.135 with SMTP id l129mr35496101itl.58.1483057747315; Thu, 29 Dec 2016 16:29:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.36.108.137 with HTTP; Thu, 29 Dec 2016 16:29:06 -0800 (PST)
In-Reply-To: <CAMfhd9Urd1DWF9yhMdhvx1AcKyB4-E7Qy+tzqz_-1RpXR+Wp1w@mail.gmail.com>
References: <CAMfhd9Urd1DWF9yhMdhvx1AcKyB4-E7Qy+tzqz_-1RpXR+Wp1w@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
Date: Thu, 29 Dec 2016 14:29:06 -1000
Message-ID: <CAFewVt44xm3rgm=n8PpEcqbTvC-Ei2EvoJciL=+m2UnQ-fUm2A@mail.gmail.com>
To: Adam Langley <agl@imperialviolet.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IqBoOCIxHLywaLawhKjzwQMCm1I>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Requiring that (EC)DHE public values be fresh
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 30 Dec 2016 00:29:09 -0000
Adam Langley <agl@imperialviolet.org> wrote: > Since this defeats forward security, and is clearly something that > implementations of previous versions have done, this change > specifically calls it out as a MUST NOT. Implementations would then be > free to detect and reject violations of this. > > This does have a cost because it also excludes the reasonable practice > of amortising public value generation over all connections for a few > seconds. The draft could attempt to specify a precise, maximum > duration for reuse but that is more complex and no value is clearly > optimal. We should brainstorm the unintended negative consequences of this. It would make self-hosting a small that can survive a spike in traffic ("slashdot effect") more difficult, thus encouraging sites to use CDNs, which decrease the integrity, confidentiality, and privacy properties of all connections between the client and the origin server. Unfortunately I don't know how to quantify that. Another unintended consequence is that it makes the PSK modes relatively more attractive. For some very small devices doing ECDH agreement on every connection and only doing a occasionally doing a ECDH keygen could be at the edge of their performance/power limits, and needing to do the ECDH keygen for every connection could easily make using ECDH prohibitive. OTOH, we don't want these devices to use have a fixed ECDH key burned into their ROM, or similar, either. Another unintended consequence is that it makes resumption (formulated as a sort of server-generated PSK in TLS 1.3) more necessary. Although many implementations will probably implement resumption, I think there are a lot of cases where one might prefer to avoid implementing and/or enabling it. Also, even when it is enabled, making ECDH more expensive relative to PSK/resumption would encourage building more complex server software to distribute PSKs across machines. And/or the server may choose to reuse PSKs longer. And/or the server may choose to use the non-ECDHE form of PSK-based resumption (IIUC). Again, though, I can't quantify the effect here. > Also, this cost doesn't seem too high: 85.6% of servers /don't/ reuse > values and manage fine today. The generation of (EC)DH public values > is also a fixed-based operation and thus can be much faster than DH > key-agreement. According to the paper, a large majority of servers in the Alexa top 1M are reusing keys. That 14.4% number is a fraction of the 80% servers consistently in the Alexa top 1M that use browser-trusted certificates and that use ECDHE. IIUC, approximately 20% of servers in the Alexa top 1M that use browser-trusted certificates are using RSA key exchange, which means they are also reusing the same key for every connection. Also, according to the paper, more than half of servers aren't using TLS or aren't using browser-trusted certificates, which means that web browser connections to them are likely using the same NULL key. Also, the Alexa top 1M isn't representative of every use of TLS, but rather only one kind of application. > Lastly, some have proposed[2] (EC)DH reuse as a mechanism for enabling > TLS connections to be decrypted and monitored by a middlebox. TLS is > not designed to be decrypted by third-parties—that's kind of the > point. Thus anyone doing this should not be surprised to hit a few > MUST NOTs and, potentially, to have to configure implementations to > allow such a deployment. The (presumably) accidental reuse of keys for long periods of time is bad, and this MitM idea is even worse. But, if reuse were made a MUST NOT, wouldn't such systems just use a different, perhaps worse, more complex, and undetectable mechanism, like the one Dan Brown suggested in the earlier thread? I think we should assume that while we may be able to help prevent the former accidental badness with such a rule, such a mechanism probably isn't going to have much effect on the latter intentional badness. With all this in mind, absent other information. In the case of servers hosting websites, I do think a limit of less than a minute is reasonable. However, I think for the small device (IoT) case, the limit should be longer, perhaps even hours. Cheers, Brian -- https://briansmith.org/
- Re: [TLS] Requiring that (EC)DHE public values be… Martin Rex
- [TLS] Requiring that (EC)DHE public values be fre… Adam Langley
- Re: [TLS] Requiring that (EC)DHE public values be… Stephen Farrell
- Re: [TLS] Requiring that (EC)DHE public values be… Eric Rescorla
- [TLS] cross-domain cache sharing and 0rtt (was: R… Stephen Farrell
- Re: [TLS] cross-domain cache sharing and 0rtt (wa… Eric Rescorla
- Re: [TLS] Requiring that (EC)DHE public values be… Adam Langley
- Re: [TLS] cross-domain cache sharing and 0rtt (wa… Adam Langley
- Re: [TLS] Requiring that (EC)DHE public values be… Brian Smith
- Re: [TLS] cross-domain cache sharing and 0rtt (wa… Ilari Liusvaara
- Re: [TLS] cross-domain cache sharing and 0rtt (wa… Richard Barnes
- Re: [TLS] cross-domain cache sharing and 0rtt Stephen Farrell
- Re: [TLS] cross-domain cache sharing and 0rtt Eric Rescorla
- Re: [TLS] cross-domain cache sharing and 0rtt Stephen Farrell
- Re: [TLS] cross-domain cache sharing and 0rtt Ilari Liusvaara
- Re: [TLS] cross-domain cache sharing and 0rtt Eric Rescorla
- Re: [TLS] cross-domain cache sharing and 0rtt Bill Frantz
- Re: [TLS] cross-domain cache sharing and 0rtt Stephen Farrell
- Re: [TLS] Requiring that (EC)DHE public values be… Scott Schmit
- Re: [TLS] Requiring that (EC)DHE public values be… Adam Langley
- Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)… Hugo Krawczyk
- Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)… Dan Brown
- Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)… Ilari Liusvaara
- Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)… Peter Gutmann
- Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)… Hugo Krawczyk
- Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)… Yoav Nir
- Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)… Eric Rescorla
- Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)… Ilari Liusvaara
- Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)… Eric Rescorla
- Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)… Yoav Nir
- Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)… Colm MacCárthaigh
- Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)… Adam Langley
- Re: [TLS] cross-domain cache sharing and 0rtt Benjamin Kaduk
- Re: [TLS] cross-domain cache sharing and 0rtt Ilari Liusvaara
- Re: [TLS] cross-domain cache sharing and 0rtt Martin Thomson
- Re: [TLS] cross-domain cache sharing and 0rtt Benjamin Kaduk
- Re: [TLS] cross-domain cache sharing and 0rtt Ilari Liusvaara
- Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)… Adam Langley
- Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)… Kurt Roeckx