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

Ryan Sleevi <ryan-ietftls@sleevi.com> Mon, 19 July 2021 15:22 UTC

Return-Path: <ryan.sleevi@gmail.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 041A33A3756 for <tls@ietfa.amsl.com>; Mon, 19 Jul 2021 08:22:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.644
X-Spam-Level:
X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 DARUKrlwT8HZ for <tls@ietfa.amsl.com>; Mon, 19 Jul 2021 08:22:02 -0700 (PDT)
Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) (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 01FF23A3754 for <TLS@ietf.org>; Mon, 19 Jul 2021 08:21:56 -0700 (PDT)
Received: by mail-pg1-f178.google.com with SMTP id o4so14702499pgs.6 for <TLS@ietf.org>; Mon, 19 Jul 2021 08:21:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Kn/qSazfr0CzsaWNRejH2daTRe48ez4lU1NIGy3xQr8=; b=AhA7/qike7Hr4UUlcZlAD40c8+Mfl4a+arEe6Ra1hHqR5OJ3VovpGNCY5xDCiObKTA NWrcb+pNn4G2/jrf1KX0rb7MmUtyjSzcCBjWLkd6aHB0t7cRA+kxjxutVRusIF52KWiM D9GUrLODwiIen8FkXE4lhN/EVBIa+QSBS3yYKi7YeMdsjHKquON5sNZ+wCTcqK6sP6iV TyRSAmh6UT5645iDGPAlGdyNi+Ca5nO8QfVeNb8/zZFKZ6g+a1xewtv2JiO5MXr7qwrP CKAk0mpi61tROVpxs3KCmHn6dL6OZW70VHxhyzVqxwfv7SLRbnQEChVZvMGWNHAt1SMn gwHg==
X-Gm-Message-State: AOAM530HEXPD8Jp/dvjmZbpYQz5LdNePGiR99sNNSKGNuVX4dkTBVKHV LQVYyiwI/0Br5fzpJ8OvnQ9SUw0eZb0=
X-Google-Smtp-Source: ABdhPJwbKi407JsT0OF+mlr5viemn07DLs3FCgkwEO3ejkqfUy2UHYF2VkBJCR+UWWJ4Ql/JpuLWww==
X-Received: by 2002:a63:e303:: with SMTP id f3mr26349046pgh.182.1626708115055; Mon, 19 Jul 2021 08:21:55 -0700 (PDT)
Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com. [209.85.216.51]) by smtp.gmail.com with ESMTPSA id a4sm16573643pfk.5.2021.07.19.08.21.54 for <TLS@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jul 2021 08:21:54 -0700 (PDT)
Received: by mail-pj1-f51.google.com with SMTP id cu14so11673917pjb.0 for <TLS@ietf.org>; Mon, 19 Jul 2021 08:21:54 -0700 (PDT)
X-Received: by 2002:a17:902:c214:b029:12b:32c5:2ab0 with SMTP id 20-20020a170902c214b029012b32c52ab0mr20018882pll.29.1626708114704; Mon, 19 Jul 2021 08:21:54 -0700 (PDT)
MIME-Version: 1.0
References: <0ad354da-5300-4b48-8925-f7ab18cdf235@www.fastmail.com> <5D834B58-7A0C-4701-96EB-31663BC0C2DE@akamai.com> <2c7c53a8-cf47-f51d-f97b-f6cd5a712024@cs.tcd.ie>
In-Reply-To: <2c7c53a8-cf47-f51d-f97b-f6cd5a712024@cs.tcd.ie>
From: Ryan Sleevi <ryan-ietftls@sleevi.com>
Date: Mon, 19 Jul 2021 11:21:43 -0400
X-Gmail-Original-Message-ID: <CAErg=HE92wz3-aLDSfNWk_qJA35+V-euUvtW07HKA=B7CVB3iA@mail.gmail.com>
Message-ID: <CAErg=HE92wz3-aLDSfNWk_qJA35+V-euUvtW07HKA=B7CVB3iA@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Christopher Wood <caw@heapingbits.net>, "TLS@ietf.org" <TLS@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000548f2a05c77b7f1c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/DgcVcVYlVA97JMz99QnMRhJJce0>
Subject: Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption
X-BeenThere: tls@ietf.org
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." <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: Mon, 19 Jul 2021 15:22:07 -0000

On Mon, Jul 19, 2021 at 11:02 AM Stephen Farrell <stephen.farrell@cs.tcd.ie>
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:
https://fetch.spec.whatwg.org/#network-partition-key

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?