Re: [TLS] RFC8447bis

Martin Thomson <mt@lowentropy.net> Wed, 18 August 2021 00:08 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 0327E3A1516 for <tls@ietfa.amsl.com>; Tue, 17 Aug 2021 17:08:51 -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=mrU06TaF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MNi8r7KJ
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 hFlNqh1XawJt for <tls@ietfa.amsl.com>; Tue, 17 Aug 2021 17:08:44 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 940563A152E for <tls@ietf.org>; Tue, 17 Aug 2021 17:08:44 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id EB0FB3200911 for <tls@ietf.org>; Tue, 17 Aug 2021 20:08:40 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Tue, 17 Aug 2021 20:08:41 -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=GQoUV0HsY37xvDUMbH+2XCwyP1qGdR7 QotrCWWuIIbE=; b=mrU06TaFEK0UbjLOGOjzCieweGfO89V2s2YmBeBMmG1KQb4 ECmWCSGmpTWXlCSnmh3dbcmvXSyKCZLF+LkyxzfqLOj/1ousw51QNurrXsPIpeHs wmFPoH3bgkdQJgA5vH1jvrfVGxE144Aa4FYza6GFV7rejY+zDG7fa/LwT/WXj3YK njyAxocopTfn/y1i/pdoYUHR6xzPty4ILvO3Bm3XBwRs5F2PIBdM01zT2ofIikMT 4GkKAYGOM1ZHD7gw+T+RETIzZKtBrGH257XVvDGAUDNGYHQmRiZyer7wdTSwaw8L EZZ6FpVb+TwlDPePBKx+bu6+TLTtQ0gi2WWKf4w==
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=GQoUV0 HsY37xvDUMbH+2XCwyP1qGdR7QotrCWWuIIbE=; b=MNi8r7KJqYtPAWIGY/qZ0q ze28Xi9Bp09INDlBn8U28QfLYhVP80OSRzxt1e4S7OCgMPXqYD3swPBey9AgxmB2 4694o1PMS6gSmsoDGcz8KMSpW0IWPipVuIXmZVR3APL6iqU8WIj1lp7YQk8j6a/S Ddno15mbO7lty8pFXMn//KHrHIQD3khAhSiEU7iLpA3k4kApJC6kM8HQVc+ZuPpG hKp39kEYnmPVJDHV8JgDYP+jYLUFLLRa3k2iTdr90ydKY5yzD30+H6wxAOktBcZc 5RWkGVV3HKkMLSgUKR6fHftcYDhb9puGPl0CnOn/1YWTb+zSk4MfpKYNxvsFp0Zg ==
X-ME-Sender: <xms:iE8cYTBvnmYuQxPEqGIXoSnkiLmGFWQJ24qKEMypz-yiS-uir9sTeg> <xme:iE8cYZiTkHG1o_8xsXk_-mcTLoT2ZXWtSrvlBEaWzi_2eAk7JOKVF5P77wAM0Iav4 Eql_D2W1WTBEfnwNYY>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrleeggddvkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhephfeitddtveeihfejjefgve efuedugffgkeevkeehueeggeelveekveektdfhueeinecuffhomhgrihhnpehivghtfhdr ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:iE8cYem_qRbfAr2rIsYAmadi7ubymg-_JSoB8dKCqSdoaRu8gaEGAg> <xmx:iE8cYVx4YWYHU01UlenYkg-H5smauD4NpUTtInXO6fWAajSENuv9zA> <xmx:iE8cYYSrtiLUwyinq3uLTi7K713ZVHDHGnPoFNDpz_cuu9UtnC-WWA> <xmx:iE8cYfePuw9umjONR4QaKDVkkhRbJLRLZq6rCwyJhvDG4sbCUkb0Mg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 442483C0453; Tue, 17 Aug 2021 20:08:40 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-1118-g75eff666e5-fm-20210816.002-g75eff666
Mime-Version: 1.0
Message-Id: <03560d15-6b48-435b-a509-7cbebce153b9@www.fastmail.com>
In-Reply-To: <b2a65504-4d9b-40bd-b0bb-3b2fa5d37f26@www.fastmail.com>
References: <b2a65504-4d9b-40bd-b0bb-3b2fa5d37f26@www.fastmail.com>
Date: Wed, 18 Aug 2021 10:08:20 +1000
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/oh7hnOVNexEzARUS8irOEo5aq80>
Subject: Re: [TLS] RFC8447bis
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, 18 Aug 2021 00:08:51 -0000

I don't think that this approach is the best we could do.

Experiments, particularly large-scale ones, turn into deployments.  Consequently the difference between "an experiment" and "a standard" is the date at which you look.  See also RFC 6648.

In that light, why not use the entire unassigned space for experiments?  A registry policy that allowed allocations for experiments, but marked those entries as temporary (the word "provisional" is usual here) would suffice.  Reclaiming these codepoints might be more challenging than the draft makes out; the expiration time you have in the draft is fine, though I expect that any dates will be roundly ignored if code is still shipping.

The point of a registry is to avoid collisions and the interoperability failures that follow.  So I would also add that all new allocations (experiment or otherwise) should draw from the unassigned space at random, rather than sequentially.  That should minimize collisions up until the point where we have exhausted the space.

I would also prefer to have no space reserved for private use (though a very small space is tolerable).

(It shouldn't be a surprise, but I'm advocating for the same general approach that QUIC took.)

On Wed, Aug 18, 2021, at 09:34, Christopher Wood wrote:
> Hi folks,
> 
> Based on discussing regarding draft-ietf-tls-hybrid-design during IETF 
> 111, it became clear that we need some mechanism to deal with 
> temporary, experimental codepoints for testing out new features. To 
> that end, Sean and Joe recently published this draft:
> 
>    https://datatracker.ietf.org/doc/html/draft-salowey-tls-rfc8447bis-00
> 
> This document obsoletes RFC8447 and updates a number of other relevant 
> documents. The main changes in this document are:
> 
> - Experimental codepoint policy and process 
> (https://datatracker.ietf.org/doc/html/draft-salowey-tls-rfc8447bis-00#section-17)
> - Updated Recommended registry values 
> (https://datatracker.ietf.org/doc/html/draft-salowey-tls-rfc8447bis-00#section-5)
> 
> Please review the document, especially if you have thoughts about the 
> experimental policy. Assuming there are no major objections, I'd like 
> to propose that we proceed with the proposal to get things started.
> 
> Thanks,
> Chris
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>