Re: [TLS] cross-domain cache sharing and 0rtt (was: Re: Requiring that (EC)DHE public values be fresh)
Eric Rescorla <ekr@rtfm.com> Thu, 29 December 2016 19:09 UTC
Return-Path: <ekr@rtfm.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 A22EB12961A for <tls@ietfa.amsl.com>; Thu, 29 Dec 2016 11:09:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 Grgs5WD5iOqw for <tls@ietfa.amsl.com>; Thu, 29 Dec 2016 11:09:13 -0800 (PST)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 1DE1F129444 for <tls@ietf.org>; Thu, 29 Dec 2016 11:09:13 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id r204so212872497ywb.0 for <tls@ietf.org>; Thu, 29 Dec 2016 11:09:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QoG0BfGq5hQSj8bRLaDa1+j/6V2Rnt7+x5BmyJQDZ9g=; b=rKAO9VwJosI9b5hoJjXTodFMTdDKZDYOLl41eCzGVzvptp7CElbFOGS5SitRZOTi+U 8IESeJp/Yz0wa0zMNARyM/FhRec7+J2LRWPWCtZ97NYfXGMms2V9BYKA23qT9S6lVSnW DPyt4WUR3xChGM2CGrboi26GtEntVq5QWeDj0855WQ4iOlUX1CsTkA+F0t0KwE+kbSfJ BaWp4dwBZLYETBHkIozSv74m/MgwFPR6k3WSEt12I4tdbOwwAqtIEuYZjHhBKZPhJT1H Er7km00qp7cWXIANgNKsStZHAfUjm6n8Z6EPPTmMJ48dT4t0E1cC2g/T/34EBVczSZI1 SByQ==
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; bh=QoG0BfGq5hQSj8bRLaDa1+j/6V2Rnt7+x5BmyJQDZ9g=; b=SUJT8U+g630jc8xX3T2NnhltJuPd1IIICeG1EFEl8tXpWy+aweIebSygpWW7olU7Sm cGg1K1KO9jth3i2uK+BOMJV9Z7WwfMHPO9yLbQwXZeihcYNrq3kPkX3ytyC11zg5RHVs OqzEVyLteRcFrMSNjYwYhpXS7Vtawk7tWTj7vdNn22nvJUxhjENSe+NceSfkBGtvzWkh IYzkoh4fZtxLkqCtWGDHbbQpm8MDCAqt7t30g3iZ+QapFT/xMSoUex8QGNa14mhXNac7 3jygtm7wpMYNHMjHryFUA+P9qkMWrVlBf7jvmAnV9VUOhxQnt17Z6giofDk7DIuJiIoP jtig==
X-Gm-Message-State: AIkVDXK8gb41dRtN8lwS5rqvOaDB5JZ3fYKIzowuRsXBu0Nyd3kfDo4KM7DVCYsvsaHUowWtPnKwrF7QKcRmWA==
X-Received: by 10.129.110.66 with SMTP id j63mr29844522ywc.52.1483038551627; Thu, 29 Dec 2016 11:09:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.164.210 with HTTP; Thu, 29 Dec 2016 11:08:31 -0800 (PST)
In-Reply-To: <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie>
References: <CAMfhd9Urd1DWF9yhMdhvx1AcKyB4-E7Qy+tzqz_-1RpXR+Wp1w@mail.gmail.com> <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie> <CABcZeBObcWUjdHhysLG1K0TbJfiqN+XCERn6WaMjWzgU0XC65A@mail.gmail.com> <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 29 Dec 2016 11:08:31 -0800
Message-ID: <CABcZeBMx3zJ07pbj0bPBMrAcrK_Q4HVDcbCx_2B1DnyCOJeE-g@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="001a114929fc0f138d0544d0d21f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/o2UqAzpaPhlMxTGUaXGSKaXO4D8>
Cc: Adam Langley <agl@imperialviolet.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] cross-domain cache sharing and 0rtt (was: Re: 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: Thu, 29 Dec 2016 19:09:14 -0000
On Thu, Dec 29, 2016 at 10:50 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie > wrote: > > > On 29/12/16 18:38, Eric Rescorla wrote: > > On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie > >> wrote: > > > >> > >> Hiya, > >> > >> On 29/12/16 17:37, Adam Langley wrote: > >>> https://github.com/tlswg/tls13-spec/pull/840 is a pull request that > >>> specifies that (EC)DH values must be fresh for both parties in TLS > >>> 1.3. > >>> > >>> For clients, this is standard practice (as far as I'm aware) so should > >>> make no difference. For servers, this is not always the case: > >>> > >>> Springall, Durumeric & Halderman note[1] that with TLS 1.2: > >>> ∙ 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so for more > >>> than a day. > >>> ∙ 14.4% of the Top 1M reuse ECDHE values, 3.4% for more than a day. > >> ... > >> > >> As an individual, I'd be in favour of this change but reading > >> over [1], section 5, I wondered if we'd analysed the effects of > >> 0rtt/replayable-data with that kind of cross-domain re-use in mind? > >> The situation being where session ID based caches or session ticket > >> equivalents in tls1.3 are shared over multiple domains. > >> > >> I don't recall this being explicitly considered, but maybe that's > >> just me forgetting. And hopefully the analysis is that such re-use > >> doesn't enable broader replay of early data, but there may be > >> something worth a mention in the tls1.3 spec, e.g. that there may > >> be linkages between the duration for which entries are maintained > >> in resumption and replay detection caches. > >> > > > > This question seems essentially orthogonal to the question of ECDHE key > > reuse > > because even if you use the same ECDHE key in perpetuity you get unique > > traffic keying material for each connection. > > Fair enough, I probably should've started a new thread so have > done that now. > Currently TLS 1.3 forbids *both* 0-RTT and resumption if the SNI changes: https://tlswg.github.io/tls13-spec/#NewSessionTicket "Any ticket MUST only be resumed with a cipher suite that has the same KDF hash as that used to establish the original connection, and only if the client provides the same SNI value as in the original connection, as described in Section 3 of [RFC6066] <https://tlswg.github.io/tls13-spec/#RFC6066>." We have discussed relaxing that restriction, specifically to allow the following case: - Client connects to server with SNI=A and the server supplies a cert with SNI=A, B - Client reconnects to server and tries to resume with SNI=B See PR: https://github.com/tlswg/tls13-spec/pull/777. However, the general consensus was to leave this out of the base spec, though we might supply an enhancement for that later (and potentially slightly soften the above language to foreshadow such an enhancement). -Ekr > S > > > > > -Ekr > > > > > >> Cheers, > >> S. > >> > >>> > >>> [1] “Measuring the Security Harm of TLS Crypto Shortcuts”, IMC 2016, > >>> pages 33–47, section 4.4. https://dl.acm.org/citation.cfm?id=2987480 > >>> [2] https://datatracker.ietf.org/doc/draft-green-tls-static-dh- > in-tls13/ > >>> > >>> > >>> Cheers > >>> > >>> AGL > >>> > >> > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > >> > >> > > > >
- 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