Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

David Benjamin <> Tue, 10 November 2020 23:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7923C3A11E5 for <>; Tue, 10 Nov 2020 15:21:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.249
X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3tTThFvr48fw for <>; Tue, 10 Nov 2020 15:21:05 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E0D183A11DE for <>; Tue, 10 Nov 2020 15:21:04 -0800 (PST)
Received: by with SMTP id i26so70429pgl.5 for <>; Tue, 10 Nov 2020 15:21:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w2X0qSDLo8kw4aq5LeDXNQ++89ChfkJGXWojpr1ofxk=; b=VAt6VQ9DILIe2+A7XDgMxKDvNhMZF/INF4REkVAllkheNvpxIvOriB+diAOiR3iT5l kBv2wuHIq9XrDLjnjtkwsB8beXdyS9TrLvKepeSKJRXFkNxPbNokIkGlRtE1nf18joK5 u+WiKAML3wdQ95yg2vy0vAS54pBk4UUEc4kGk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w2X0qSDLo8kw4aq5LeDXNQ++89ChfkJGXWojpr1ofxk=; b=sLaOjjq4Dd6TRrnMdS1AvCiTUcLxbnGovIccK51EaKTyIGXf15ER3fsC7NERwcUFgA i0tmjCwBlf0hMSnyeFzlykmVG5cd3yngafE+hdvVOkDS0OeXOiR1TBGiUTOBNoARvqdn 0weOqc/DB/0CKrhyKSIP1mlbUxg6DYjnaDreNrxRiPMD1/EJo87yGqYvCl36iSVky9cE hzFMt8Tw8bUQCemKW0GtUsg1CuwH87BVTt610/EtIbXNUHvb3e7rvQVzlvh+IL3yQ8x1 1tKfRnTOtdvgSdPRcUBopDsTmIy2J+fOTRXtpAjLUCHDUFa9Y/UaCBBMVsXIMj/LMr1J sd2w==
X-Gm-Message-State: AOAM530JIF6xyC8wECeTH+3VShsUgEt2vlG5sC5Bq3hZa5a/BedDyIq4 A73weAZdOPBn165vO9+nfd6Qyj00PT0Wp5YM2d7ZAiuLjQ==
X-Google-Smtp-Source: ABdhPJyMp0v1XezpzS4sv2mC5BpAs+DOqnAEHxeW23iaUATCYTwOrXaN43+X6SVHAySN7NwL/gAJrfSdRH17Ll42NQc=
X-Received: by 2002:a17:90b:1011:: with SMTP id gm17mr541753pjb.73.1605050464087; Tue, 10 Nov 2020 15:21:04 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Tue, 10 Nov 2020 18:20:48 -0500
Message-ID: <>
To: Ryan Sleevi <>
Cc: Victor Vasiliev <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000c2859505b3c8ee76"
Archived-At: <>
Subject: Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Nov 2020 23:21:09 -0000

I support adopting this draft.

On Tue, Nov 10, 2020 at 5:38 PM Ryan Sleevi <> wrote:

> On Tue, Nov 10, 2020 at 5:29 PM Victor Vasiliev <vasilvv=
>> wrote:
>> On Mon, Nov 9, 2020 at 11:51 PM Martin Thomson <> wrote:
>>> I've no objection to adopting this, though I will note that it is likely
>>> of minimal use in the browser context due to the move to isolated storage
>>> (which includes tickets).  The potential value for cross-origin connections
>>> on the same page exists, but it would be good to understand whether the
>>> advantages seen are significant enough to justify the effort and
>>> complication involved.
>> That's fine, since in most of the cases where this is useful the
>> top-level origin is the same.
> Can you expand on this? You seem to be describing a situation to allow
> resumption when the origins are different (cross-hostname), but then state
> this is fine, because the top-level origin is the same.

Cross-site tracking mitigations in browsers are primarily focused on the
top-level site, and partitioning state, like caches, based on that. That
is, when the user visits https://a.example and separately on
https://b.example, those two pages should not interfere with each other.
The https://a.example and https://b.example loads may themselves make
cross-origin requests, perhaps to the same origin, like
https://common-3p-provider.example. But {common-3p-provider, a}
and {common-3p-provider, b} live in different partitions, so those requests
would not be allowed to share connections or TLS sessions.

Where requests *are* in the same partition, this draft is still useful.
Browsers are generally okay with two parts of the same page talking to each

It's also worth noting that the cross-name resumption and cross-name HTTP/2
connection reuse have the same tracking power. In the browser context, even
same-origin connection reuse has the same issue given cross-origin
subresources. All of these are equally mitigated by top-site partitioning.

Thus, the draft needs to include privacy considerations, particularly
>>> regarding cross-origin tracking.  I am also of the opinion that it should
>>> use flags, but that would depend on changes to the flags draft.
>> I considered that.  This particular attack seems to be fairly
>> web-specific, and since the mitigation (network partition keys
>> <>) relies heavily
>> on Web concepts, I'm not sure a TLS draft would be a good place for
>> describing it (compared to, say, Fetch).
> It's not immediately obvious how this concern is web-specific. Cross-host
> linkability seems relevant regardless of whether the Web is involved, as
> it's fundamentally a question about whether or not two hosts are seen as
> part of the same effective logical group/administrative domain or not, even
> if they might share operational characteristics (e.g. the same certificate,
> the same CDN).

Yeah, it's probably worth some generic sentence just so the layer above
knows to deal with it. Although really this sentence should have been in
RFC8446. Something to fix for rfc8446bis perhaps. Cross-name or not, two
connections that share a TLS session cache can be correlated by the server.
Client applications need to partition their TLS session cache to match
their desired correlation boundaries.