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

Eric Rescorla <> Thu, 03 December 2020 20:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4602D3A0BF2 for <>; Thu, 3 Dec 2020 12:05:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6iEhxu877XT6 for <>; Thu, 3 Dec 2020 12:05:54 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56C153A0C21 for <>; Thu, 3 Dec 2020 12:05:54 -0800 (PST)
Received: by with SMTP id z21so4520579lfe.12 for <>; Thu, 03 Dec 2020 12:05:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bdWfU5S2Goqmt9FJ0EY9hiqNoKMO5GBxjnYO/bsFrrs=; b=u0CAgKiggTI7CKeh7pDQCC6SV+uz1rYt+Sz72jgrWEFtiH7JDvPSt1Mg6MT9pEPrzX XSET9W89dw7lSsmBtwrMGdPVzU4CM+KeHLXgApcy3K9fRXiKPF6yolSyB4FxaNDGFVG4 iAI4jGJev1GpSx56ve1vn89gW4kcQmDXMvna9dmnIVzMtF7k1fZwwo3WzAxyigJULVCI 9MwisYiX9T0nqi2g8UEY8to+Bt7VRxjztnMQEAq36PdRdd6lR5t5iz41ud03WtLJbV8z ZQtDTeyYsDdklzqIxhw9EhA22sJNr2mxzLTeUxwR9JJbeF6guOmKKEpKGSC1N9xyY8zJ utBA==
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=bdWfU5S2Goqmt9FJ0EY9hiqNoKMO5GBxjnYO/bsFrrs=; b=RHjD9TpNYkOtyVMkn8gd7w3dvCX7+kNKHI/YfRGQXDgu35H/BTvBK16KF8lqqV4nXz YaD+IRRd4izeCMaYufBc58lPutFkzwG9FqP1WtqH9brWf+1zDrD3fUJeNG6Fcr8omr1o b68dIvlerDhRJSr++gvIO1g0z55c3S+kbnj+LKf452soleFxn5uzoMQZpUMMTUryW6kD pY731CLAiIE/0JF9TNypZYEjlCCbM/bYNzT+/I2Ks9yiUo9H7fLJWqXXpqoILx1Xk+fm 9Qj+tFI1LGJ0kjSlHFXFn5BsFQ5pkYXi9Z+0eM5+I1kcemWBQIM+a8p3RyvMt1grnflA cNuw==
X-Gm-Message-State: AOAM533DEfK3VkPwXOdyAWy/toNc1PMY3F6ugZD/AV19x5huwqhpIzuJ c7786fy7ilEPUCj43TJ2ox4ogpBpA5Dv811gnIj/5A==
X-Google-Smtp-Source: ABdhPJwsQFmchOlcmeP2ZeWHZZt9GGAlw+l71xUuR6ZSr1ukmqJXkIAPKo7T1U6IXSRsS0ayn7qMBpW8DVE+aK+eK5k=
X-Received: by 2002:a19:c3cd:: with SMTP id t196mr2051575lff.26.1607025952506; Thu, 03 Dec 2020 12:05:52 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Thu, 3 Dec 2020 12:05:13 -0800
Message-ID: <>
To: David Benjamin <>
Cc: "Salz, Rich" <>, "<>" <>
Content-Type: multipart/alternative; boundary="0000000000000b5cbc05b594e32d"
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: Thu, 03 Dec 2020 20:06:04 -0000

On Thu, Dec 3, 2020 at 11:12 AM David Benjamin <>

> On Thu, Dec 3, 2020 at 1:16 PM Eric Rescorla <> wrote:
>>    If a client certificate has been associated with the session, the
>>    client MUST use the same policy on whether to present said
>>    certificate to the server as if it were a new TLS session.  For
>>    instance, if the client would show a certificate choice prompt for
>>    every individual domain it connects to, it MUST show that prompt for
>>    the new host when performing cross-domain resumption.
>> This seems like it only applies with post-handshake auth, right, given
>> that you can't do resumption + client auth.
>  I'm not sure if it's ever been written down anywhere (probably should
> be...), but I think resumption is pretty much universally interpreted as
> authenticating as the identities presented over the original connection,
> client and server. That means that, independent of this draft, the client
> should only offer a session if it is okay with both accepting the original
> server identity, and presenting the original client identity. (Analogously,
> HTTP connection reuse reuses TLS handshake-level decisions, so you have to
> be okay with that decision to reuse the connection.)
> It's common to key client certificate preferences by server domain, so
> this text is saying you should offer cross-domain sessions consistent with
> that. (Analogously, HTTP/2 cross-domain connection reuse has the same
> effect and you have to be okay with that decision. In Chrome, we don't do
> cross-domain connection reuse on connections with a client certificate,
> since the user was only prompted for the original domain. I expect we'd
> apply a similar rule to resumption.)

Yes, this seems reasonable, but I didn't get it from the text, so maybe if
this is adopted we could file an issue.