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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D6E73A09AA for <>; Mon, 19 Jul 2021 09:51:01 -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 Slk2kaXntKl3 for <>; Mon, 19 Jul 2021 09:50:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 791B83A09BC for <>; Mon, 19 Jul 2021 09:50:56 -0700 (PDT)
Received: by with SMTP id d9so5799215pfv.4 for <>; Mon, 19 Jul 2021 09:50:56 -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=NLLfo6gMZJru/qf3syFlxi/W3/dVYRVguO12ktTyVo4=; b=TpLkp5PVP1qp4LJuIT60fwalu+thd1/TNgXEAmNr5tcqWZom6c/NBwWnzAzps4BE5l 0kkzKU5Y29vlo99OkESwIMyMqjCScufy3Rc0yeWuJvet1L5zrlLoQjymhsFwNEW9INoc lv0b6aNXjoPBX4+/enYP1VMrd7y8+ltr/JDYQ=
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=NLLfo6gMZJru/qf3syFlxi/W3/dVYRVguO12ktTyVo4=; b=aqJ+XoxmC48MpPD5YOLRrqpRy7HgfVQ5HSlFvPEvWJrb6Wzx/hfHb4xMgtiD9W37wQ fEjkxg+XFM76LmSQ9UdFBNU41xS9To84DQryFmoJW9v7q/uXrlcZZiNCt1DRnHWioZBN GFMpIaa1/Uj/2LL76ijD2Tga1HxhoCg+1NQpzwNgp7tvp2iA8uqcJpbUJ45qjsLgsbFP Lpyqi3eWC8ftmVX4pQ1jTnIKCP1o4olrid5kepp0nZME3GNQVZGZ0lpRnd3RPrErxivp UK7/e8fRUzeJOSEJi8soDhVndq94ycL31SiXJ5HGfqjdEuaZUM2n9UUV46+CK1uNkW9R xcRg==
X-Gm-Message-State: AOAM5311RJrbLSF5qI4hszLtzWB5FzqNsT2fmhBgNYZ7UkIiBwlNS/ne YdEv4PO13MxmZsc2iS7rGhJn735P9CONwcDzhHFE48ybLKkO
X-Google-Smtp-Source: ABdhPJzPBOLCvBAZkvH8EnUaPCse/o/2sAQRrrjzC8d/5KR+dxVLpbxoJZVSiKRRO9wHEkpExxWVZs7uQJ6fmDiZtT4=
X-Received: by 2002:a05:6a00:cd1:b029:346:8678:ce1b with SMTP id b17-20020a056a000cd1b02903468678ce1bmr7692430pfv.41.1626713453641; Mon, 19 Jul 2021 09:50:53 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Mon, 19 Jul 2021 12:50:37 -0400
Message-ID: <>
To: Stephen Farrell <>
Cc: Ryan Sleevi <>, "Salz, Rich" <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000008ee6e105c77cbd0d"
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:51:02 -0000

On Mon, Jul 19, 2021 at 12:38 PM Stephen Farrell <>

> Hiya,
> On 19/07/2021 17:35, David Benjamin wrote:
> > We need to*both*  not add new tracking vectors*and*  mitigate the
> existing
> > ones. Doing either one on its own is not useful. That means if the
> existing
> > mitigation for the existing vector applies just as well to this new
> > feature, we have not added a new vector.
> I think that clarifies where we disagree, thanks - i'm
> not convinced that our existing mitigations for tracking
> via the web, or otherwise, are anywhere near sufficient.

I think you're still misunderstanding me. Let me try to phrase this better.
By "existing" I mean "already written down in Fetch", and just talking
about the TLS resumption component. I certainly don't mean to suggest the
problem is done. Tracking via the web overall is a complex, evolving topic,
with lots of folks working on it across the stack. Most of it is not
relevant to low-level TLS state, except in recognizing that, because
correlation is transitive, you can only solve it looking at the application
as a whole.

To bring this back to resumption, there is really only a single question to
answer here: do you offer a session, negotiated in context A, over this new
connection being established in context B? If you say yes, you potentially
get a performance improvement, but you also allow contexts A and B to be
correlated. Whether you are okay with that depends on the application, and
is not something TLS can answer.

What TLS needs to do is translate this TLS-level notion into things the
application is worrying about. In this case, the deciding question is: do
you mean for those two contexts to be correlated? If not, don't offer
resumption. That is what this draft says, and it is what rfc8446 needed to
say, but omitted. That omission has been corrected in rfc8446bis.

Do you have other text in mind? There doesn't seem to be any other possible
answer here, since there is only one decision to make in resumption. It's
also one that clearly will continue working as we evolve and strengthen
applications' privacy goals, including that of the web, since everything
boils down to what contexts can and cannot be correlated.