Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption
David Benjamin <davidben@chromium.org> Thu, 03 December 2020 21:08 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 AF4853A0CB0 for <tls@ietfa.amsl.com>; Thu, 3 Dec 2020 13:08:01 -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 oBVB5e9H8dt2 for <tls@ietfa.amsl.com>; Thu, 3 Dec 2020 13:08:00 -0800 (PST)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 16DBA3A0CA2 for <tls@ietf.org>; Thu, 3 Dec 2020 13:08:00 -0800 (PST)
Received: by mail-pl1-x62b.google.com with SMTP id v3so1844025plz.13 for <tls@ietf.org>; Thu, 03 Dec 2020 13:08:00 -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=WGO+BjDzecYrWmpEktQY7GKYZv9OoQs/TLr7Xl0ESlg=; b=kQvcuf7U88leaJ9VzafQcRdZohk5cV9Xm6WLq1Uf76Go1E9VVhMNmu3keUusFXIsJV PKQMUmj8ZLUE8+4RhzfFJO+UI5/FEc7Zk6OSBnBLZZk3x+myAUAnW0hH3y0r3vt9Vg5s F6yetuwBE3KnQzOSmPOJ7mgGjRhe8d0uN6Tmg=
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=WGO+BjDzecYrWmpEktQY7GKYZv9OoQs/TLr7Xl0ESlg=; b=g9FosSaSCUtqG18EKv3eyB0rOknP9epqmNEGADfIO4fE74L8z24aGlC8RIQSUruwoS lV2mBZCWCq0/8oILUZfTraze3OT2i+oyDIw0DX+8kyHeH/+Ys4qY8BWmMrJoorF+Mv0C qzkzj1ENIplh6AOktraTer9Cd0b6LdQyb2vL3IHb0aNuqHsHEcnevhr0upICyDgmBg2J /+vSwL5+XSKhF5HHeiI9RN4OGXhh2Svuy8bau+EwPTNVB8wsstM+Bi2v32L5zdrSUFHu 15VvRu/JQBt4evjIBJ5xrMlBZc8ArAYctGBC7bZxbmf5aCfexnTGehYFIUUL7fbtGVog bB7g==
X-Gm-Message-State: AOAM531qX8mJOWTkb3uv4Ue3j9EQImDOFzULCgoQXR92DAyDJVvG2UFF 5E7oCVpHwDpAaatRosxbBi4LtLmxBvou4TUWqv+k
X-Google-Smtp-Source: ABdhPJxLiCMYw59E5klEM5zcx2q0R1FD4Ey6eGe+19aEtY02fIqgPfYwSzSbb6htM7Y8YsNwzfdPzboUaa9XIHCi5fw=
X-Received: by 2002:a17:902:74cc:b029:da:9287:2b4 with SMTP id f12-20020a17090274ccb02900da928702b4mr984893plt.9.1607029679334; Thu, 03 Dec 2020 13:07:59 -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> <22DD5290-9978-4006-A192-EA4927F4FBAE@akamai.com> <CABcZeBModS45EOGhAYdpOjPDAarLBZJXWjY0pK3eVcybB6mqaA@mail.gmail.com>
In-Reply-To: <CABcZeBModS45EOGhAYdpOjPDAarLBZJXWjY0pK3eVcybB6mqaA@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Thu, 03 Dec 2020 16:07:43 -0500
Message-ID: <CAF8qwaCVJp6w_DMDhLWhQ72rYHGGWEdxs=7StVAWCyMA7r0-qw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "Salz, Rich" <rsalz@akamai.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002e7fe805b595c1a1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_Tm6OFkIHR1MVkD1_PaavCntL9o>
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 21:08:02 -0000
I think, like the tracking issue, it should go in both. (I wrote https://github.com/tlswg/tls13-spec/pull/1205 to try to capture the tracking case.) This draft should definitely (re)-state it because TLS preferences are most common keyed by domain name. So even if it's in TLS itself, it's worth emphasizing it. At the same time, I think it is a general property of resumption. An application may have different TLS preferences even for a single domain. (E.g. web browsers make both credentialed and uncredentialed requests, which are supposed to imply different client certificate preferences.) Or maybe you have some contexts with different server authentication preferences than other contexts. Such an application would need to adjust its resumption behavior accordingly. To me, the ideal state would be that TLS contains the long-form general guidance and then this draft cites TLS as a reminder, because keying preferences by domain is so common. But since the order between rfc8446bis and this draft isn't yet clear, probably we restate the rules in full in both and, after rfc8446bis is done, documents can be more concise. On Thu, Dec 3, 2020 at 4:00 PM Eric Rescorla <ekr@rtfm.com> wrote: > Hmmm... I think it probably goes in this draft, but I'm open to being > wrong. > > On Thu, Dec 3, 2020 at 12:46 PM Salz, Rich <rsalz@akamai.com> wrote: > >> >> - 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.) >> >> >> >> Totally agree. @ekr, you want to make this change in your BIS draft? >> >> >> >
- [TLS] Call for adoption of draft-vvv-tls-cross-sn… Joseph Salowey
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… Martin Thomson
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… Stephen Farrell
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… Martin Thomson
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… Victor Vasiliev
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… Martin Thomson
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… Ryan Sleevi
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… David Benjamin
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… Victor Vasiliev
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… Joseph Salowey
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… Salz, Rich
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… Eric Rescorla
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… David Benjamin
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… Eric Rescorla
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… Salz, Rich
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… Eric Rescorla
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… David Benjamin
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… Salz, Rich
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… David Schinazi
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… Carrick Bartle
- Re: [TLS] Call for adoption of draft-vvv-tls-cros… Joseph Salowey