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

Martin Thomson <mt@lowentropy.net> Tue, 10 August 2021 02:39 UTC

Return-Path: <mt@lowentropy.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 7CDDA3A22E4 for <tls@ietfa.amsl.com>; Mon, 9 Aug 2021 19:39:18 -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=lowentropy.net header.b=YXypNrKO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lY+RlHSG
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 bw9jCvIN9-v2 for <tls@ietfa.amsl.com>; Mon, 9 Aug 2021 19:39:12 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771843A22E1 for <tls@ietf.org>; Mon, 9 Aug 2021 19:39:12 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 936CA5C0175 for <tls@ietf.org>; Mon, 9 Aug 2021 22:39:08 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Mon, 09 Aug 2021 22:39:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=Y5LtJdlbZS1Js8QNS0/GSJ0AsvoKA/Q 18rwUQqXN5Ds=; b=YXypNrKOuO/2l+CmlU0xJv/LIvvlHirJKW8s62LzyqxddwM tDp5ErwmSv34OZCvGwIZq4a7nIE4MKXZKzGrUMJQn7sW5B83oaDQvlSuc05I9QzS Ko3bKqPoBygza7GFWifMidwCrUZy3VlrDxervbhuH1HqQ/jotAD4CxyM10WOMg8s O4Lbs1iQKAwJSp64YMU26p0UtaDA28BGgWEhXFl4/xJnzBUnoyTAvfnHOBRueJUY SW9xHseh7w8tTLVhbT9PKgNACUXU0//ZGuIq5GOP50FnXLhR9FfnGjUUsU5nufJV RYa8YqUFWZbHyfruLo6fMT0WMOoK1o3/YBFCKrg==
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=Y5LtJd lbZS1Js8QNS0/GSJ0AsvoKA/Q18rwUQqXN5Ds=; b=lY+RlHSG107RHngISjRcwK jCaS6rXAC+McrJNY2RX/psWA7oCXoFXXjQgHUkZnu9syj2yh1A2WJxWfL1E3LWFK WzswyxuDeRj8qjjMT/tXPXWEL8HKeTecYHt6zBreyKcQHJP4dcbRpcEUuWrxrKAs vrf1m24y30UX5g0dUl1rICk3h3NbB9CU2w0YL197HhHildCw8Y7pHW+daxCIktUl 4Hmruds/daLd0zNvdCo13mlpo8WCOWlPhqlxcMB9OnVUeaGyRLiXp35/3mVjo+hW 4kpzKF8MeCx9EMe3NmyPOauz9xrkBHnsgqat2ee3TZkfJnqj2VFvQgBkaJJGrYBw ==
X-ME-Sender: <xms:zOYRYbg1QWCzsyrbseiBlMg3BwPIOCQgbJ339bmECQws-eXWnYgVUA> <xme:zOYRYYBLne_MCSiQOC9RNuIJlMzgebObcgQ8IiXS4SFLAWwv-qoZJHxrZfvl5XRun GHBcwZ_Kxww5BVvcDQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrjeekgdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnheptdevtddvgeevkeeiteekud fgffduieegvdfhffefgfdvleffkeetvefgfeeutdfhnecuffhomhgrihhnpehivghtfhdr ohhrghdpghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:zOYRYbF9LunJnFEkljxU3EPTEnwDAKJe-k6iz4Tb7iTKmoVT5pn8aQ> <xmx:zOYRYYT2x6-58_gFNMrhcUTIhyFin_DRH_8bkEhR1tvakqxRWkeeow> <xmx:zOYRYYxSknUvNCUThoNc4AQTQXc7w-KtN5kNhNU-Cd2drZ6Mp31wjA> <xmx:zOYRYX-frYCnNlVz1WkBQVUyDj2ZAhQx_LKKn0fm7hLedJh6JjZyuQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1C5A23C0449; Mon, 9 Aug 2021 22:39:08 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-552-g2afffd2709-fm-20210805.001-g2afffd27
Mime-Version: 1.0
Message-Id: <04b80f09-43e5-4af2-9126-2213a48147c3@www.fastmail.com>
In-Reply-To: <0ad354da-5300-4b48-8925-f7ab18cdf235@www.fastmail.com>
References: <0ad354da-5300-4b48-8925-f7ab18cdf235@www.fastmail.com>
Date: Tue, 10 Aug 2021 12:38:21 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/80DCLp_5X6ehmbLsQg2oZufgYRg>
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: Tue, 10 Aug 2021 02:39:19 -0000

This document is mostly fine.

The text on use of client certificates isn't particularly clear.  The key piece of information that a reader is going to need is that a resumed connection will include any (and potentially all) client authentication.

I found the meat of the flag definition hard to follow.  There is a lot of 2119 language, but very little of it relates to the operation of this extension.  Some is just restatement of RFC 8446, which comes with real risks and should be avoided.  I think that what this needs to say is:

1. What the protocol mechanism is: (a flag in NST)
2. What sending that signal means.  For example, "The flag is an assertion from the server that all servers that answer to the names in the certificate are able to use this ticket."
3. What the client might do with that.  For example, "If a client would accept the certificate for a new connection, it can/MAY attempt resumption even if the server name differs from the server name of the original connection." <- that might be the only 2119 language you need in the entire document, though I'm not sure you even need that.

Then talk about consequences (this is currently in Security Considerations and is mostly good, though not all of this belongs in a section with that title):

1. What if the server is wrong in its assertion.   For example, "A server that wrongly advertises this flag could cause clients to waste tickets on connection attempts where resumption will not be successful."
2. Why the server might choose not to do this: need to coordinate across a deployment, it could be wrong, certificate bloat, key compromise scope, etc... (the existing text on this is fine)
3. What the client needs to consider before exercising this option (tracking -> partitioning, client authn)

On Sat, Jul 17, 2021, at 09:55, 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
>