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

Carrick Bartle <cbartle891@icloud.com> Wed, 11 August 2021 21:49 UTC

Return-Path: <cbartle891@icloud.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 959D83A266A for <tls@ietfa.amsl.com>; Wed, 11 Aug 2021 14:49:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=icloud.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 eA3DhpyxeG_3 for <tls@ietfa.amsl.com>; Wed, 11 Aug 2021 14:49:29 -0700 (PDT)
Received: from mr85p00im-zteg06021601.me.com (mr85p00im-zteg06021601.me.com [17.58.23.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4AE3A2640 for <tls@ietf.org>; Wed, 11 Aug 2021 14:49:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1628718569; bh=CyqhoV40dTfMOW0PpE5H5JAy0HcsaU6g1WoEtUoKKSo=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=lIuGDEwSQqsadUW6E0Z8opJnclCbb0Avgu22wibk7WqtukOZWT7U+frb4nVweQ+B1 GD3ibrRZEdGnU0vQR+FhuXjHR/UucGIMkPuGuAl5fnml/aBzSODLRUa6So7CcN32he QYzXiDueXYAhbASymr8VAzeSDR5XFPmP+ObG45F/hnBV7ZcHzvy+1Oci4nk3chNzpn O1sLJ22aSwf+LLQTJ75c+1XS96+U3e78B9kqtmyXf1S7mQfvXkeOe3LEh3iAkbj0W9 SNCRK9X7u5cVfA2y3zN2+rA/2FocfQNE6s5Qp9m2jOyZ3U2B2LdJ37D8arqlD46ZH1 N30ByRG2G+ubw==
Received: from smtpclient.apple (unknown [17.11.99.8]) by mr85p00im-zteg06021601.me.com (Postfix) with ESMTPSA id 992F0400128; Wed, 11 Aug 2021 21:49:23 +0000 (UTC)
From: Carrick Bartle <cbartle891@icloud.com>
Message-Id: <62E46612-F680-4153-A178-EFF8ABD3DAD0@icloud.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_37909DD4-6485-4B3F-8B79-BBE50D63FE68"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Date: Wed, 11 Aug 2021 14:49:21 -0700
In-Reply-To: <CAF8qwaDSN40CmwwwbLdXNoYyWmCNepTmcAabHEOAMmG6N=01fQ@mail.gmail.com>
Cc: Christopher Wood <caw@heapingbits.net>, "TLS@ietf.org" <tls@ietf.org>
To: David Benjamin <davidben@chromium.org>
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>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.391,18.0.790,17.0.607.475.0000000_definitions?= =?UTF-8?Q?=3D2021-08-11=5F07:2021-08-11=5F01,2021-08-11=5F07,2020-04-07?= =?UTF-8?Q?=5F01_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 malwarescore=0 bulkscore=0 suspectscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2108110148
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/SAEwqF6VD0xh57qMzloQFrtid38>
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: Wed, 11 Aug 2021 21:49:36 -0000

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


> 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 <mailto: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 <mailto: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/ <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 <https://github.com/vasilvv/tls-cross-sni-resumption>
> >> 
> >> Thanks,
> >> Chris, on behalf of the chairs
> >> 
> >> _______________________________________________
> >> TLS mailing list
> >> TLS@ietf.org <mailto:TLS@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> >> 
> > 
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org <mailto:TLS@ietf.org>
> > https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>