Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

Christopher Wood <caw@heapingbits.net> Fri, 20 August 2021 20:24 UTC

Return-Path: <caw@heapingbits.net>
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 3AA7F3A03FE for <tls@ietfa.amsl.com>; Fri, 20 Aug 2021 13:24:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=v0+rVxUu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PdF9ZTwv
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 Xc4Ldx5BqMm2 for <tls@ietfa.amsl.com>; Fri, 20 Aug 2021 13:24:33 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 294F23A0407 for <tls@ietf.org>; Fri, 20 Aug 2021 13:24:33 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 658C35C0092 for <tls@ietf.org>; Fri, 20 Aug 2021 16:24:32 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Fri, 20 Aug 2021 16:24:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=FIpQ/XjvJ0Np0ZCjQfyQCpw5bJ/40M9 fhWOmQ89StuE=; b=v0+rVxUuIm3cCWwzuNHIZrqPEx6hWKQA+O9J/GNj7HGLPTb g9HIAT2amy3ZUkArJDZ81RtV+zM8bsOvnkbeeyCxaU2Tm1npHnXHWPOFXeBdQPAs 5pEW5D54pUdJa8MGz5yMgdkDbVBDcfEpSYRX3NhOjWVM2mqb/4ScdCSjb6CBL4r4 0fOSwYSwg7ZL5o5XHk3b7ZYgFGGSq7/VV188rQbngclVgJFkLVYpi8SmXcPwmP1J E//ZjLjzYKIDEW0FxobsnuiUjrpCbu2qAQsHM8GClp1MQoqnJzEDYB8sY0QPvV6H LGPcuGc1u0zm/mJbLUSA8kidB44Ask76vbw2/ag==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=FIpQ/X jvJ0Np0ZCjQfyQCpw5bJ/40M9fhWOmQ89StuE=; b=PdF9ZTwvuuf4rYGICW3Xt5 kD58IM1+OSRyLsAFY9qkQ+qSqcsFHPtwZTfxU3ibSMLSi1cMNg98JbPbFi1q9+6m JquuIQ4PoNPcsXNnigC5iXu4/mgVhVsrMNdNjNIpLdjo8ta3JR2CJDmcz1/UmXiB bqEHIKLs63WAtyitsj2Iie1Xf9spUHXWbYmxRoVkY9ngav6ITjnkphwXYN2q4rHi L0EwlYxgI5GIlJzOKjmbaMlT07a6ojBN1r50P+CtkBZ4KC63+3Sweu88pP0I61It S+peOrxjENnTuyeGL4IYuyV27AyYqwZhx7XxIl14pL+mv73f2fQQSh6U5WnRp0tQ ==
X-ME-Sender: <xms:fw8gYbmh7CHHypAhlP1OsamN56TFAJszwkQipKKPdGFWzilZrlcoMg> <xme:fw8gYe0tj9d_jDS6kmQE6B0IBLcdMlPUJLx76wFEz_6FiO1iyHdwKMNJBZk1PinU_ -LD90PL9DYL-ghHJIU>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrleelgddugeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpedtffeuleevfe elheelffffgfelffejhfekteduhfeuleehteejhedvfffghfeuleenucffohhmrghinhep ghhithhhuhgsrdgtohhmpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:fw8gYRrUFT8jXAwNOSNLzA1S5lleRrf1eWO99oQPquVz3YzWzXlSXQ> <xmx:fw8gYTkXttGZgaiIaYlaeTGCajieK0J_YTpJZXqaUN981OsNlmCVxA> <xmx:fw8gYZ3dNPYsxKy0fjtJaBmZwdGMYTO-deJEyi51NhzEc_Meh0e2-A> <xmx:gA8gYaAqACsZcwLGsa-LqAi3yDTqxQFNbFBtnfY7aR_ZdONEbA-33g>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 229D33C0F7F; Fri, 20 Aug 2021 16:24:31 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-1118-g75eff666e5-fm-20210816.002-g75eff666
Mime-Version: 1.0
Message-Id: <05348ab9-fb0b-490a-a9f5-03f79abdd812@www.fastmail.com>
In-Reply-To: <8616A3E6-5EEA-4584-9DA9-83E56A52792B@icloud.com>
References: <0ad354da-5300-4b48-8925-f7ab18cdf235@www.fastmail.com> <8d260f7a-7cbe-4980-9ed2-0120764fc476@www.fastmail.com> <9F2E90F8-3461-4D71-A3E7-A3A9FC5DA8E7@icloud.com> <CAF8qwaDSN40CmwwwbLdXNoYyWmCNepTmcAabHEOAMmG6N=01fQ@mail.gmail.com> <62E46612-F680-4153-A178-EFF8ABD3DAD0@icloud.com> <CAF8qwaCGkmLjYhKeq4oMNndGmb41it+RAhT3aaHU+9OiL3UCXw@mail.gmail.com> <06CDFFDF-FB69-4952-AC5D-9A584DEA8D75@icloud.com> <8616A3E6-5EEA-4584-9DA9-83E56A52792B@icloud.com>
Date: Fri, 20 Aug 2021 13:24:10 -0700
From: "Christopher Wood" <caw@heapingbits.net>
To: "TLS@ietf.org" <tls@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/eaqnvF_gvSjKsA98t6ukJjlRbNE>
Subject: Re: [TLS] WGLC for draft-ietf-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: Fri, 20 Aug 2021 20:24:43 -0000

This WGLC is now complete. Thanks to everyone who chimed in. Based on past discussions and this WGLC, the chairs believe there is consensus to move this document forward after some clarifying changes, especially around security considerations. We will work with the author to make these changes and then request publication alongside draft-ietf-tls-flags.

Best,
Chris, for the chairs

On Fri, Aug 13, 2021, at 4:48 PM, Carrick Bartle wrote:
> I've submitted a PR that addresses this issue: 
> https://github.com/vasilvv/tls-cross-sni-resumption/pull/3
> 
> In general though, I support publication of this draft.
> 
> 
> > On Aug 11, 2021, at 3:50 PM, Carrick Bartle <cbartle891=40icloud.com@dmarc.ietf.org> wrote:
> > 
> > Okay, in that case, I wouldn't use the word "re-validated," since to me that sounds like the certificate is to be completely validated again (e.g. checking expiration). Instead I would say something like "attempt resumption only if the certificate is valid for the new SNI," ideally with a reference to the current best practice of how to do that.
> > 
> > 
> > 
> >> On Aug 11, 2021, at 3:25 PM, David Benjamin <davidben@chromium.org> wrote:
> >> 
> >> On Wed, Aug 11, 2021 at 5:49 PM Carrick Bartle <cbartle891@icloud.com> wrote:
> >>>> - Ticket-based PSKs carry over the server certificate from the previous connection
> >>> 
> >>> What does "carry over" mean here? That the client literally holds on to the certificate and re-evaluates it before resumption? Or just that the trust from evaluating the certificate during the initial handshake also applies to the PSK? Because, AFAICT, the literal ticket isn't required to contain the server certificate.
> >> 
> >> I meant the latter. Though every TLS stack I've seen does actually retain the peer certificate. It's not in the literal ticket (that wouldn't work since it's issued by the server), but in the session state the client stores alongside the ticket, just like the PSK and other state. This is because TLS APIs typically have some kind of function to get the peer certificate, and applications typically expect that function to work consistently for all connections. That stuff is mostly not in the RFCs because it's local state and TLS doesn't define an API.
> >> 
> >> Anyway, as with any other use of resumption, in order to offer a ticket, you need to have retained enough information locally to know that the trust from the initial handshake is also good for this connection. This could be remembering application context (perhaps by way of separate session caches). This could be remembering the whole certificate. This could be remembering smaller amounts of information from the certificate. The exact details here I don't think TLS should specify, only the conditions on when using a session is okay.
> >> 
> >> David
> >>  
> >>>> On Aug 11, 2021, at 2:13 PM, David Benjamin <davidben@chromium.org> wrote:
> >>>> 
> >>>> On Wed, Aug 11, 2021 at 5:00 PM Carrick Bartle <cbartle891=40icloud.com@dmarc.ietf.org> wrote:
> >>>>> >  Notably, it still relies on the server certificate being re-validated against the new SNI at the
> >>>>> >  session resumption time.
> >>>>> 
> >>>>> Where is this specified? I can't find it in RFC 8446. (Sorry if I missed it.)
> >>>> 
> >>>> Does RFC 8446 actually say this? I haven't looked carefully, but I suspect, if it says anything useful, it's implicit in how resumption works:
> >>>> 
> >>>> - If the client offers a PSK, it must be okay with the server authenticating as that PSK for this connection
> >>>> - Ticket-based PSKs carry over the server certificate from the previous connection
> >>>> - Therefore, in order to offer a ticket in a connection, the client must be okay with that previous server certificate in the context of that connection. Server name, trust anchors, and all.
> >>>> 
> >>>> This is another one of those cases where cross-SNI resumption is just a more obvious example of a general principle that needs to be written down somewhere in TLS proper. (Even with the same SNI, suppose two different parts of my application use different trust stores. My session resumption decisions must be consistent with that.)
> >>>>  
> >>>>> >  However, in the absence of additional signals, it discourages using a session ticket when the SNI value > does not match ([RFC8446], Section 4.6.1), as there is normally no reason to assume that all servers
> >>>>> > sharing the same certificate would also share the same session keys.
> >>>>> 
> >>>>> It'd be helpful to describe under what circumstances there is reason to assume that servers that share the same certificate also share the same session keys (and are able to take advantage of cross-SNI resumption).
> >>>>> 
> >>>>> 
> >>>>> > On Jul 30, 2021, at 6:57 PM, Christopher Wood <caw@heapingbits.net> wrote:
> >>>>> > 
> >>>>> > Given the few responses received thus far, we're going to extend this WGLC for another two weeks. It will now conclude on August 13.
> >>>>> > 
> >>>>> > Best,
> >>>>> > Chris, for the chairs
> >>>>> > 
> >>>>> > On Fri, Jul 16, 2021, at 4:55 PM, Christopher Wood wrote:
> >>>>> >> This is the working group last call for the "Transport Layer Security 
> >>>>> >> (TLS) Resumption across Server Names" draft, available here:
> >>>>> >> 
> >>>>> >>    https://datatracker.ietf.org/doc/draft-ietf-tls-cross-sni-resumption/
> >>>>> >> 
> >>>>> >> Please review this document and send your comments to the list by July 
> >>>>> >> 30, 2021. The GitHub repository for this draft is available here:
> >>>>> >> 
> >>>>> >>    https://github.com/vasilvv/tls-cross-sni-resumption
> >>>>> >> 
> >>>>> >> Thanks,
> >>>>> >> Chris, on behalf of the chairs
> >>>>> >> 
> >>>>> >> _______________________________________________
> >>>>> >> TLS mailing list
> >>>>> >> TLS@ietf.org
> >>>>> >> https://www.ietf.org/mailman/listinfo/tls
> >>>>> >> 
> >>>>> > 
> >>>>> > _______________________________________________
> >>>>> > TLS mailing list
> >>>>> > TLS@ietf.org
> >>>>> > https://www.ietf.org/mailman/listinfo/tls
> >>>>> 
> >>>>> _______________________________________________
> >>>>> TLS mailing list
> >>>>> TLS@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/tls
> >>> 
> > 
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>