Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

David Benjamin <> Mon, 19 July 2021 16:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30D003A38F7 for <>; Mon, 19 Jul 2021 09:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.949
X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vj9hHdUa3K-1 for <>; Mon, 19 Jul 2021 09:17:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B0633A38FA for <>; Mon, 19 Jul 2021 09:17:34 -0700 (PDT)
Received: by with SMTP id i14so4884075pfd.5 for <>; Mon, 19 Jul 2021 09:17:34 -0700 (PDT)
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=on/xG4fQrev6v25V/o4mmpD8T7roGFURDfaMuyBrkv0=; b=Z2CFHzXIqA1+TSLAr40qoyQiJ9TRkJtIwi4nMYmekRuoLSwcvqaMQA6OizVHhhyj6i yILOIUoyTLqrCaoL05AUCQNqALrUpuchQ6DaddY32m2Vu8yfgoELdgY8ZJlnNvJLZ9Op GtrLfNzQ10XNCoyZ5ruOJ1lHm/ZAKxB1qRAEQ=
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=on/xG4fQrev6v25V/o4mmpD8T7roGFURDfaMuyBrkv0=; b=bU1mv5BPxAb7LAvsd0dGTw+kivn4ZpyocUZw613uppIVUSaxGu6jTMFcq/WHsoxMwN 1XG50PXVJYeh6CSvLELNo6D+1aN5D2qrlrm8HEJDtH0Bja88cRGL8Dm45mwOdeFv9Sd+ d4/3Ycf8+Z22/S3juVx4w2JIrFzBpBGPiUTLOXfBbjBPJWvltSUoK+kYxplWaEDgjMpb HCi4Y0coRpwPopGqt//P3/6AlDpbpHzNpxKsvsysWb35y1QHRRVpgOznZFbIl3x5Dz3m ZUxLMucbgyGZljJSu2x5JUJaTFOylfQhxmVUQMZlIz6bCmpq2GNP9ZKsCSyE3tyM7a/h 4qZQ==
X-Gm-Message-State: AOAM531PxeYgq21zl8PADlx+ipsdOfKKud1MPsIDgmPf9dppSAtl8Jxs wSNlYgKBjp6Jtw8irxcrby9I951wCIDKehvAQTeHmW2/og==
X-Google-Smtp-Source: ABdhPJwpFUpK22OXPqqB/+tnkQDU/gQf9BLflu8vHuJ2V/GnCe7XBT7GQeeXXngRXRrL9Odlq4Q9suhEhNGrM4Pq1BM=
X-Received: by 2002:a63:210b:: with SMTP id h11mr6169389pgh.6.1626711453061; Mon, 19 Jul 2021 09:17:33 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Mon, 19 Jul 2021 12:17:16 -0400
Message-ID: <>
To: Ryan Sleevi <>
Cc: Stephen Farrell <>, "Salz, Rich" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000508d9b05c77c468b"
Archived-At: <>
Subject: Re: [TLS] WGLC for draft-ietf-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: Mon, 19 Jul 2021 16:17:44 -0000

I'll add that, in the context of cross-domain tracking on the web, this
draft is a red herring. Remember that web pages have subresources. That
means looking at the destination domain isn't useful because two different
pages can embed a common destination domain. So the same concerns exist
with RFC8446 (TLS resumption), RFC7540 (connection-reuse, same- and
cross-domain), and RFC7230 (connection reuse). That's why we need a
holistic answer like network partition keys from [FETCH], that apply to
*all* network state. That answer applies equally to plain resumption and
this draft.

Of course, [FETCH] doesn't apply to other applications, just the web. But I
think the above should demonstrate that correlation boundaries are
necessarily a whole-application question. That's why the [FETCH] citation
is only an example. The general guidance is this:

> Client applications should partition the session cache between
connections that are meant to be uncorrelated.

This applies to all application protocols. Do you believe your correlation
boundary is an individual email? Well, you shouldn't reuse any state across
those and probably will end up not doing any resumption at all. Do you have
multiple contexts in your application, like different profiles, that are
meant to be separate? Well, you shouldn't reuse state across those
profiles. Does your application not have correlation boundaries? Well, then
you can resume whatever. Are you a non-web application where partitioning
by just the destination domain is meaningful? Well, then you should
partition your session cache accordingly, which no-ops this extension and
parts of RFC7540.

Indeed, since this is a general problem with TLS resumption, we're really
talking about an omission in RFC8446 itself. For rfc8446bis, I landed this
PR, which corrects the omission.
Were publication orders different, there would be no need to include the
same text in draft-ietf-tls-cross-sni-resumption, but so it goes.

On Mon, Jul 19, 2021 at 11:22 AM Ryan Sleevi <>

> On Mon, Jul 19, 2021 at 11:02 AM Stephen Farrell <
>> wrote:
>> I don't find the reference to [FETCH] explains how that
>> problem can be mitigated by browsers. (IIRC, adding that
>> was the result of earlier discussion of this point?)
> I'm not sure I'm parsing this correctly.
> Are you saying that you don't believe network isolation keys are
> sufficient? That is, this is the current language from the draft:
> > For example, the Web use case uses network partition keys to separate
> cache lookups [FETCH].
> And the term there ("network partition keys") is a defined term in the
> FETCH spec that forms the basis of cross-domain tracking prevention:
> It's unclear whether you're saying that the spec should diverge from FETCH
> and impose additional requirements, or whether you're saying you don't
> believe the current FETCH spec is robust enough there.
> It's unclear that there's any benefit to having the Cross-SNI spec impose
> additional requirements: you have to consider the Web application in its
> entire context, which is precisely what network partition keys do.
> Similarly, if the concern is that FETCH isn't sufficient for your concerns,
> is that a concern with this spec, or with FETCH, and can/should they be
> articulated there (and the related issue mentioned)
> <snip>
>> I think both of those are indicators that this mechanism
>> could be used at scale for tracking.
> You opened by talking about MTAs, but it's unclear if this is meant to be
> a general statement or specific to mail. In the context of the Web, then we
> have to consider the holistic platform, and ask whether this hooks into the
> same appropriate points - it does, as the partition keys are based on the
> same cross-origin tracking protection mechanisms (e.g. the determination of
> "first party" vs "third party" contexts is implicitly handled here). If
> this is for mail, then isn't the point that this remains an
> application-/protocol-specific consideration?
> _______________________________________________
> TLS mailing list