Re: [TLS] Fwd: New Version Notification for draft-nir-tls-tlsflags-02.txt

"Martin Thomson" <mt@lowentropy.net> Wed, 24 July 2019 13:43 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 22E0312004D for <tls@ietfa.amsl.com>; Wed, 24 Jul 2019 06:43:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=rTS83Ix/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ANcaoC6W
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 32rbq0EPwRCf for <tls@ietfa.amsl.com>; Wed, 24 Jul 2019 06:43:45 -0700 (PDT)
Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDA9512006D for <tls@ietf.org>; Wed, 24 Jul 2019 06:43:44 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id BB00C1C7E for <tls@ietf.org>; Wed, 24 Jul 2019 09:43:43 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 24 Jul 2019 09:43:43 -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:content-transfer-encoding; s=fm2; bh=9vlox qBkGedaXXemn8pl6zdcSOPhtBtmNXXh5zp6GJY=; b=rTS83Ix/HYN7xQFIVArWL Zb+vpbohohk4epmG2nEgZSVHqkfOxZ2b3R8y/u5o6zh/TDtemJrPjVFNyuK/x+td BSB/a98UGlLu/20K0DW5C7rihGPNVlnKDnIrwgXhc6TN2rbK5CXV2GKQgvogjqxS xYVJE5tzwwhBm6NAOyxQglW5kihSrjqkhHsIUHF4hVL+vi3yuj6LdGTV/TnNK4xV MB48rasx1bTmdOQfXjglm17hjIiuBJqo3Dsxi3JV1lGGmWeolRoY26iFxss817nw F0BQvQzIqdMrCkuod0QxlgOuq6SZ2WnWlx45KE3oy66WOSJUUosxgVTK2LopeoCy A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=9vloxqBkGedaXXemn8pl6zdcSOPhtBtmNXXh5zp6G JY=; b=ANcaoC6WVLei30Y4/ZW8ZQGb60iewvavi6Svn9yKh8ddRmj1lbiBoS4CH y+xcrm5vqKEvVDNaf3nqvNZ6iUV6juXZmAcI9yKsxmhzIJtVl2WJYdeoZsX4GRna cOtdHH1FrscQrpnkFL+XC+v/+XrzlRIHm696kt83pF9JGtSYAqJXopyubJeuEV3a er08h4nLhV94ociKSIc7xt2xZPDLtuKJ4mU6ykJqf0zNtYhlK0mqZKUsou+5gmjx Mu4ZMDeHe5C+9tdWTbPC+3uhcMAvKAjD7D2tySrFkK0e4B/AmlTQdNaXd6skzXvn xpGWAW0BVveqz5/3o6WlQEFCP0u4w==
X-ME-Sender: <xms:j2A4XfrnJ5d9cUnExO1SptxETQr5ocDHRarEocWB8BXVF1DXrJ8Oog>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrkedtgdeifecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepfihikhhiphgvughirgdrohhrgh dpihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhht rhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:j2A4XexVP_e8jwD--cBnDbb9Jkj82JQpZ7x0NZD0R2fal7v6PYBsoQ> <xmx:j2A4XfJ0i4eb1Dl9QWCKyZ1JgpRYW_G0Hm4HTs7UIPc8Pn76NsgqmQ> <xmx:j2A4XY5_1t-jtzWElAFAoXG6rH0qNBJit9xIDjh2qLxdJPHQQ5SZpA> <xmx:j2A4XUDekMarC0WVUDm8Pb4OaN7tO12RCYp4jC_XjikJtLO87iW88Q>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6E6B9E0129; Wed, 24 Jul 2019 09:43:43 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-736-gdfb8e44-fmstable-20190718v2
Mime-Version: 1.0
Message-Id: <293ac9e3-fbaa-44ca-ad0e-cb728e20936b@www.fastmail.com>
In-Reply-To: <92584B5E-5234-4C5D-ABBC-A312BB59C14F@gmail.com>
References: <156393857098.27882.16925086682562389655.idtracker@ietfa.amsl.com> <92584B5E-5234-4C5D-ABBC-A312BB59C14F@gmail.com>
Date: Wed, 24 Jul 2019 09:43:43 -0400
From: "Martin Thomson" <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IUvkn6EOYX10o6-5Xbo-vp8be8M>
Subject: Re: [TLS] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draft-nir-tl?= =?utf-8?q?s-tlsflags-02=2Etxt?=
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, 24 Jul 2019 13:43:47 -0000

Hi Yoav,

Thanks for doing this.  I personally prefer the flag choice you have.

I think that you need to move from CH,SH,EE (which has a weird duplication that might be problematic), to CH, EE, CR, C.  Critically, I don't think that you want the ServerHello to carry any of these.  Flags are generally not used for key exchange, and I think that we can use the old school approach if that comes up, or define a different flags extension.

The requirement for the server (or really the responder) to echo the client's flags seems like it might have some problems.  From an implementer perspective, I strongly prefer to have this processed in exactly the same way as an empty extension, which is sometimes echoed and sometimes not as needs dictate.  You can see with the case of a flag sent in ClientHello and responded to by the server in either EncryptedExtensions or Certificate.  Requiring that flags are echoed in both contexts might be confusing.

Cheers,
Martin


On Wed, Jul 24, 2019, at 00:32, Yoav Nir wrote:
> Hi.
> 
> Following today’s session, I’ve updated and submitted the draft.
> 
> It contains the proposal from slide #5 in my presentation.
> 
> It does not contain any fancy way of reserving bits for future popular 
> extensions.
> 
> It uses a single numbering of the flags, not the more efficient 
> separate numbering per context (CH, SH, EE, CH-in-CTLS)
> 
> I believe such bikeshedding can be done after adoption. Just so long as 
> we don’t make it of asbestos. [1]
> 
> Yoav
> 
> [1] It was never about the color of the bike shed, but about the 
> material: https://en.wikipedia.org/wiki/Law_of_triviality#Examples
> 
> 
> > Begin forwarded message:
> > 
> > *From: *internet-drafts@ietf.org
> > *Subject: **New Version Notification for draft-nir-tls-tlsflags-02.txt*
> > *Date: *23 July 2019 at 23:22:50 GMT-4
> > *To: *"Yoav Nir" <ynir.ietf@gmail.com>
> > 
> > 
> > A new version of I-D, draft-nir-tls-tlsflags-02.txt
> > has been successfully submitted by Yoav Nir and posted to the
> > IETF repository.
> > 
> > Name: draft-nir-tls-tlsflags
> > Revision: 02
> > Title: A Flags Extension for TLS 1.3
> > Document date: 2019-07-22
> > Group: Individual Submission
> > Pages: 6
> > URL: https://www.ietf.org/internet-drafts/draft-nir-tls-tlsflags-02.txt
> > Status: https://datatracker.ietf.org/doc/draft-nir-tls-tlsflags/
> > Htmlized: https://tools.ietf.org/html/draft-nir-tls-tlsflags-02
> > Htmlized: https://datatracker.ietf.org/doc/html/draft-nir-tls-tlsflags
> > Diff: https://www.ietf.org/rfcdiff?url2=draft-nir-tls-tlsflags-02
> > 
> > Abstract:
> >  A number of extensions are proposed in the TLS working group that
> >  carry no interesting information except the 1-bit indication that a
> >  certain optional feature is supported. Such extensions take 4 octets
> >  each. This document defines a flags extension that can provide such
> >  indications at an average marginal cost of 1 bit each. More
> >  precisely, it provides as many flag extensions as needed at 4 + the
> >  order of the last set bit divided by 8.
> > 
> > 
> > 
> > 
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> > 
> > The IETF Secretariat
> > 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>