Re: [TLS] WGLC for "A Flags Extension for TLS 1.3"
Christopher Wood <caw@heapingbits.net> Tue, 21 April 2020 12:54 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 8DEBE3A0B88 for <tls@ietfa.amsl.com>; Tue, 21 Apr 2020 05:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, 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=Bg6mAJ1n; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oXK2FFaw
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 iuN-IqqK-MQD for <tls@ietfa.amsl.com>; Tue, 21 Apr 2020 05:54:11 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ACB93A0B84 for <tls@ietf.org>; Tue, 21 Apr 2020 05:54:10 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4DB5D5C0198 for <tls@ietf.org>; Tue, 21 Apr 2020 08:54:10 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 21 Apr 2020 08:54:10 -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=fm1; bh=R0p6nsqbi8hfxGh1PH2JxJrbJ4dCuwe f8eQl5IWV7SQ=; b=Bg6mAJ1nDIczracPMc9MydgaJTthARtjChxs/JD+710P7RY 9v2giJXioco+2k5FYBTpizGxABdRVi+X+fJs5SG9dWUX3x33vxbgi2fupWXAAeGT 3LtTJ9qDEu+J0fBgJW1AESQgt/+croagE768StQBJ8i5XThBRUBxIzDQ6Sq9RRRR +Tk456gBaidBIcQtrm+suFLBiUTK/NaKk4l3J+TOD85akqTZVSasisgY7byCtwVr JFYGdiJIOTrhTHyoz7YpsKWDR05JhyM/qpmYao/wGC964PZntfi2f/cjEKaI4lmQ 49DBpWpgrEmAve59Gb0v9By3eTiF0Ykist19QNA==
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=fm2; bh=R0p6ns qbi8hfxGh1PH2JxJrbJ4dCuwef8eQl5IWV7SQ=; b=oXK2FFawhFVglnkFUptXmM xzZkg/+43L9DO8b5UUq0OUHhG9/C8kgknE+2jUh2zw1V82oY0e/Q/qdKNg4hYSLJ QduW9N3kPoc/rKN5qbHGkciFS9dqDRoCyfJ7IHnHwjdPOShBZs6DqJKs0Ue+VkCj KcC5gFFi3F7l1SGkf3rL1UsREu6GQO0vpfA8PERzTrhvDOD0cWrwlMy5/R7L/x77 D12+IbxO+tPkGK1vk4OdiLiAFOB5KRJ/EJ0iHJlK468aAVsYmJNBFRj4X2IWDsGX RwViEv2+07wYnWOfUWopA8oh4Yfu7FONwOkN6b5o9xdAEuStNaWH97cD6QWKYgcQ ==
X-ME-Sender: <xms:8uyeXqCo-JMEmzv-jafkfTNpfg7MiUz8rI5ZIWd6_UJICZedUOEKdw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeehgdehiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghdpgh hithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth
X-ME-Proxy: <xmx:8uyeXunrLO5jP1iJijjfGLFpKcTztCDhPfG97m8Bar1Yh-riVx2fsA> <xmx:8uyeXtcjusHDwb4nyi7MrtpJCwUNnEZDFxyUYKvsY_YUi9saJXJF-A> <xmx:8uyeXqRnEcNZ5za4Qm3Th6DnUEvlQJ-l6tIj7UrfdMdG6W2tkfei-g> <xmx:8uyeXtZa72TLdkbwnwm8Imnrjqq07wWriSmhxJphfglssUN7bXV8zA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0FB37180091; Tue, 21 Apr 2020 08:54:10 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-1152-g08c8976-fmstable-20200420v1
Mime-Version: 1.0
Message-Id: <9051bc64-b116-490a-9465-2cbb26be5217@www.fastmail.com>
In-Reply-To: <3aab08b9-d979-4952-85f6-62e993f6fb4b@www.fastmail.com>
References: <bf0f823a-99ab-46b0-9b2a-d397d6bf3139@www.fastmail.com> <3aab08b9-d979-4952-85f6-62e993f6fb4b@www.fastmail.com>
Date: Tue, 21 Apr 2020 05:53:41 -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/QgIxZT4eeqCDWCEjUtoGg8Etqb8>
Subject: Re: [TLS] WGLC for "A Flags Extension for TLS 1.3"
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, 21 Apr 2020 12:54:14 -0000
This WGLC is now complete. We need more reviews, and likely a bit more work, before moving this ahead. We'll run another WGLC once we have both. Yoav, can you please have a look at the comments and concerns raised below and address them as needed? Thanks, Chris, on behalf of the chairs On Mon, Apr 6, 2020, at 3:39 PM, Martin Thomson wrote: > I like this work, but I don't believe this to be ready yet. > > S1 > None of the current proposed extensions are such that the server > indicates support without the client first indicating support. So as > not to preclude future extensions that are so defined, this > specification allows the client to send an empty extension, > indicating support for TLS flags in general (and presumably some > unspecified features in particular). > > First, for clarification, the distinction between empty and > all-zero-valued is perhaps worth drawing on. Second, more seriously, > if this is the goal, the text needs to acknowledge that the possibility > exists on a *per-flag* basis. > > Third, more substantially, and invalidating the above, I don't think > that we should make flags introduce a new style of negotiation just > because it can. I would strongly prefer that this function as close as > possible to "empty ClientHello extension; empty EncryptedExtensions > extension". Aside from that, the utility of an advertisement from the > server that a client cannot respond to is pretty marginal. > > Fourth, this conflicts with the following text in S2: > > A server that supports this extension and also supports at least one > of the flag-type features that use this extension and that were > declared by the ClientHello extension SHALL send this extension with > the intersection of the flags it supports with the flags declared by > the client. > > Nit here: this isn't about support alone, it is the flags that the > server *chooses* to support. > > S2 > The server may need to send two tls_flags extensions, > one in the ServerHello and the other in the EncryptedExtensions > message. > > Are we confident that sending the same extension in both places is > safe? I know that clients have to implement this and so should be able > to test that this works, but it seems awkward. And it might not be > necessary. It's also not sufficient, as we currently allow responses > to ClientHello extensions to appear in Certificate (and for > CertificateRequest to carry "requests" in the other direction). > > Perhaps we might avoid this problem entirely. ServerHello extensions > are limited to key exchange. If we say that flags are limited (today) > to functional properties that don't affect key exchange, my thought is > that we don't lose much (if anything) by only allowing this extension > in EncryptedExtensions. > > I don't know what I think about Certificate extensions. This seems to > have a clear use there. > > Editorial: > > S1 > It might be better to draw examples from the canon of published RFCs > than to refer to things that might not get published. > > On Tue, Apr 7, 2020, at 00:53, Christopher Wood wrote: > > This is the working group last call for the "A Flags Extension for TLS > > 1.3" draft, available at: > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ > > > > Please review the document and send your comments to the list by April > > 20, 2020. The GitHub repository for this draft is available at: > > > > https://github.com/tlswg/tls-flags > > > > 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] WGLC for "A Flags Extension for TLS 1.3" Christopher Wood
- Re: [TLS] WGLC for "A Flags Extension for TLS 1.3" Salz, Rich
- Re: [TLS] WGLC for "A Flags Extension for TLS 1.3" Martin Thomson
- Re: [TLS] WGLC for "A Flags Extension for TLS 1.3" Christopher Wood
- Re: [TLS] WGLC for "A Flags Extension for TLS 1.3" Yoav Nir
- Re: [TLS] WGLC for "A Flags Extension for TLS 1.3" Martin Thomson
- Re: [TLS] WGLC for "A Flags Extension for TLS 1.3" Yoav Nir
- Re: [TLS] WGLC for "A Flags Extension for TLS 1.3" Christopher Wood