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

Eric Rescorla <ekr@rtfm.com> Thu, 03 December 2020 20:05 UTC

Return-Path: <ekr@rtfm.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 4602D3A0BF2 for <tls@ietfa.amsl.com>; Thu, 3 Dec 2020 12:05:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 6iEhxu877XT6 for <tls@ietfa.amsl.com>; Thu, 3 Dec 2020 12:05:54 -0800 (PST)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 56C153A0C21 for <tls@ietf.org>; Thu, 3 Dec 2020 12:05:54 -0800 (PST)
Received: by mail-lf1-x134.google.com with SMTP id z21so4520579lfe.12 for <tls@ietf.org>; Thu, 03 Dec 2020 12:05:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; 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; d=1e100.net; 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: <CAOgPGoATi+jFy53x5W4T6ai=xjH4VufhWaoABT5g_w=_72N8HA@mail.gmail.com> <CAOgPGoDJP8RNxjyrYWvPzvWOrkmDs9ssqFxvF1+mqtWg9BMF=w@mail.gmail.com> <24904640-192F-4557-98B6-094455D88CF5@akamai.com> <CABcZeBOvCXKfu=ENLfPyutgbDem7KuXBQPrju-B9_YuogFEXBg@mail.gmail.com> <CAF8qwaCn+8b2K=R5AvjrELeRvFCb82QBOCvPfOMtDgsao0nJOw@mail.gmail.com>
In-Reply-To: <CAF8qwaCn+8b2K=R5AvjrELeRvFCb82QBOCvPfOMtDgsao0nJOw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 3 Dec 2020 12:05:13 -0800
Message-ID: <CABcZeBM4A7-u+7q3Q2ruc78mL6n1MOapnBek3i-qAP3wNTAwCg@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Cc: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000b5cbc05b594e32d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VXuGNQKVCqhiwdg6T0Z1XOHs_JU>
Subject: Re: [TLS] Call for adoption of draft-vvv-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: Thu, 03 Dec 2020 20:06:04 -0000

On Thu, Dec 3, 2020 at 11:12 AM David Benjamin <davidben@chromium.org>
wrote:

> On Thu, Dec 3, 2020 at 1:16 PM Eric Rescorla <ekr@rtfm.com> 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.

-Ekr

David
>