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

Ryan Sleevi <> Tue, 10 November 2020 22:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04FEF3A1196 for <>; Tue, 10 Nov 2020 14:38:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.395
X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v-j56-Uqo7H1 for <>; Tue, 10 Nov 2020 14:38:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 720083A1191 for <>; Tue, 10 Nov 2020 14:38:40 -0800 (PST)
Received: by with SMTP id y7so177886pfq.11 for <>; Tue, 10 Nov 2020 14:38:40 -0800 (PST)
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=YvbMYAkovLgWPdjAK4zTmiSFfziFhxPYqQMHsANP4FI=; b=KOSBwFuF+qEOaMV8gS52jnlVtQQ/dBFgw2L61Ju1qb+95YW5l4tDAkp9ybIkthpoEL MPsBGurny+gLHBjAfxCbr0etWkCHTbPFedIOVVB6nzisZ3AG6dZlU6ZodLhpTgcuzw6z BFu2xCOoplhjyV+gFBNl+RdxVFILjy3k5B51uZBAuM5UDsfBrtJDcb2lstLzVxnaNvQy 21Gob9F9IW90v8bay4u1oC/foI+6e1nVD1r4Cp9B2ac+zDVjsvpLT7K/HlMq1kltcxIx r8VkuN/wATPNHVVelzWm4xqkLIqLw1uEQUpl/+1OU0Nbu1ATr1xtxrkBgGVUuadoa3li U2zg==
X-Gm-Message-State: AOAM530RBGCwUHz6L9whmJKyCvxwrNF9PM9tMUsqxt/8Usg8iDuyGG+l 9nVoxk4Q9wmD6xb4/RguII22HKolSaA=
X-Google-Smtp-Source: ABdhPJze7y9+t+i1oMekZMlfylx3QXR6RtWmewvyFdtV4+eoW1pWQ6Z4kLJzdCRyihDRRMLkXMP5Qw==
X-Received: by 2002:a17:90b:3111:: with SMTP id gc17mr388162pjb.41.1605047919478; Tue, 10 Nov 2020 14:38:39 -0800 (PST)
Received: from ( []) by with ESMTPSA id v13sm35233pgl.6.2020. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Nov 2020 14:38:39 -0800 (PST)
Received: by with SMTP id e7so172335pfn.12 for <>; Tue, 10 Nov 2020 14:38:39 -0800 (PST)
X-Received: by 2002:a63:5b63:: with SMTP id l35mr19631226pgm.70.1605047918822; Tue, 10 Nov 2020 14:38:38 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Ryan Sleevi <>
Date: Tue, 10 Nov 2020 17:38:27 -0500
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Victor Vasiliev <>
Cc: Martin Thomson <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000000c89fe05b3c857eb"
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 22:38:42 -0000

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.

> 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).