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

David Benjamin <davidben@chromium.org> Thu, 03 December 2020 19:12 UTC

Return-Path: <davidben@google.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 B613D3A0794 for <tls@ietfa.amsl.com>; Thu, 3 Dec 2020 11:12:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.25
X-Spam-Level:
X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 QS8ZGxPoFtee for <tls@ietfa.amsl.com>; Thu, 3 Dec 2020 11:12:25 -0800 (PST)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 788863A074B for <tls@ietf.org>; Thu, 3 Dec 2020 11:12:25 -0800 (PST)
Received: by mail-pj1-x102b.google.com with SMTP id iq13so1624490pjb.3 for <tls@ietf.org>; Thu, 03 Dec 2020 11:12:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c3dOV5O5Cvb+JouDGNCKI8p3VQczkfzKxa9jeh12W7I=; b=BBtJUG/UJXrujkXnSWE6dGhNjQ6XB0I3dlOUma6QVwA1/fRBN8FSQRrWe/pw759FVo 09H/Yeovxo3j5iVKGSo0gJUK6nnhTqFVlG8pVRY9xnC2FU2uxMKgj95jCJnZ+0h1DSgh vXjcPW55bbgerKQFsgKv4BPt3w+SeXkE2lwLM=
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=c3dOV5O5Cvb+JouDGNCKI8p3VQczkfzKxa9jeh12W7I=; b=llCvhbHbFQwadROs8eJV8Dt6XV7q+D98Pp2OcFcRH3U51WG1Ll/SgB/5xDMucAeOf+ LhCTNo4vbaRHJz3BmWKAU0DOF4qdx4GosKs2NDvEK5mj3T1hKZVtibwxoQ04mTTqVYVE 4hH181gm86VmCBLUs0xgfLtQV4qFyhv9lDAZJS+LN5d6d3lgCmntAettSDmw1k6VdNYe IKaZiY8EyzMg49poO6XipGMi7qX3twakmw+wi71n49wqDq+vNXi4/1B7NFL4o2uYpXQV SCeA6QvuSf9QBS/R5lZZT9M2F1OkyMjiERg+y1T9iEI7ZzbJSw7/RKpAS9Rv/DLKHSeC 2hrQ==
X-Gm-Message-State: AOAM530+yfR2NU80cZwQtHUZsuYDZA3EEsBwjnwIAGPUe8+wiV4cM3Et eHg4KoORayGk/bFOLxIiaVv+dRdinB1DmKcMwyZYHCZO+uio
X-Google-Smtp-Source: ABdhPJy95SXuvekusq0o3Gr5X/UFAHeSkRpu9z0TrjXqP7ZAFs8cb0aDYqioqVELoXFP8iM8XpWWRQ9LPkLixBE5gKk=
X-Received: by 2002:a17:902:ee0b:b029:da:1856:72c2 with SMTP id z11-20020a170902ee0bb02900da185672c2mr624726plb.0.1607022744684; Thu, 03 Dec 2020 11:12:24 -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>
In-Reply-To: <CABcZeBOvCXKfu=ENLfPyutgbDem7KuXBQPrju-B9_YuogFEXBg@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Thu, 3 Dec 2020 14:12:08 -0500
Message-ID: <CAF8qwaCn+8b2K=R5AvjrELeRvFCb82QBOCvPfOMtDgsao0nJOw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d8663805b5942359"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/d47_ym5DERmcJ9yHOAfdL_eaSrc>
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 19:12:27 -0000

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

David