Re: [TLS] WGLC for "A Flags Extension for TLS 1.3"
Martin Thomson <mt@lowentropy.net> Mon, 06 April 2020 22: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 EDE093A0DE0 for <tls@ietfa.amsl.com>; Mon, 6 Apr 2020 15:39:29 -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=lowentropy.net header.b=SkMyOm+i; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ED9ZT3qw
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 KfBdiQdQxtS8 for <tls@ietfa.amsl.com>; Mon, 6 Apr 2020 15:39:28 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 600C53A0DDF for <tls@ietf.org>; Mon, 6 Apr 2020 15:39:28 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 693AA68B for <tls@ietf.org>; Mon, 6 Apr 2020 18:39:27 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Mon, 06 Apr 2020 18:39:27 -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=fm1; bh=MZ0//S9d0UyFZj+d2w//c63x+Ql8eaw q06Ym0P0zt3A=; b=SkMyOm+isjhc/U+uFiS1F4ZPbm5sxx+uTkLMdU8DT/99vIa qGiRxoH0MUEBZ98V0pvuQxaMyiHaAulC82U6OovF3HjwJ8PrT+a2acreHZY1ZXj8 eS7Vv1NABGE/6AWEhcFtLAAVepL0vUlvelgx+OHeyZSAc7dcWpOzy7JhuJtSdh4x fmrf/0NsMYw/BjeKGr089k4gjOJMUh7aRWqtL1H0JGX8ros8jtUPlBJcrX8txHpV EqK6xC7dcixDPrjfNsJf7i1utyuNMEbKSy4C2hvzjiIB+UiEKczzyPlHDiiJa4xN JbiDCi+BoFZm1P4qiAFTUc0EzjMjsb9/CGC0t3Q==
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=MZ0//S 9d0UyFZj+d2w//c63x+Ql8eawq06Ym0P0zt3A=; b=ED9ZT3qwcuod4vW4WJhRYZ o/ggQGJ00E9/DBz64GWrlHGflCdGQHtLVGC8IkUCsSxhxetNKyvWH4g9vl/Hh4kG Hps5SX7GoH9SNEs+7mVuyKSSEkw46hhfncd09uEu1+ii4BxSMcZffWmwTbadV5kR 5Pj7thKngAVj5+wj4zSl5gcrzBlEDGIl+oGGnWoZNAWzUoMXm7vEekUOT7JY0s5q uPJuv3+PrEwLfTWBZi2af73lu8AksFaIrfoc6YQUycQw6aMeNHZQ9xFB8EY5UIY6 vhlUX/UEe0+51XV8TTWCew3xkTiqdlLcWJOjQ7p2djoPIXsPGuKdyQpV05JHXo7Q ==
X-ME-Sender: <xms:nq-LXqDJ7KIidRlHeist5isz7YqS81dC0HQOPiEkuefKbHL35z9VaA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeggdduvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghdpghhithhhuh gsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:nq-LXoyOnFyab7mqa9s6nzfpuYV6sXl0yon_YsHjgXTkDbhVPeezPw> <xmx:nq-LXolmdakJgfmigH68iXEx9en7FFNTZR3sxerhpyprBvWOnCeNkQ> <xmx:nq-LXtHHZgQd2JPN8ijNUhQKherVDJ8ITIW6lxj_RD0_1ZOy7QXB2w> <xmx:n6-LXl5ELPP2pnPCCyTCrX0aaS0i8jSc6XVcSr8opQBuyCX9twtx9Q>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id C17AEE00B1; Mon, 6 Apr 2020 18:39:26 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-1084-gdc5e709-fmstable-20200406v2
Mime-Version: 1.0
Message-Id: <3aab08b9-d979-4952-85f6-62e993f6fb4b@www.fastmail.com>
In-Reply-To: <bf0f823a-99ab-46b0-9b2a-d397d6bf3139@www.fastmail.com>
References: <bf0f823a-99ab-46b0-9b2a-d397d6bf3139@www.fastmail.com>
Date: Tue, 07 Apr 2020 08:39:06 +1000
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/6ykECAN6jo1pMKlgWAYQwnqQe1k>
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: Mon, 06 Apr 2020 22:39:30 -0000
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] 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