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?
>>
>>
>>
>