Re: [TLS] RFC8447bis

Sean Turner <sean@sn3rd.com> Thu, 19 August 2021 02:30 UTC

Return-Path: <sean@sn3rd.com>
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 65E8B3A0A80 for <tls@ietfa.amsl.com>; Wed, 18 Aug 2021 19:30:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 cff4dSLMhh_I for <tls@ietfa.amsl.com>; Wed, 18 Aug 2021 19:30:23 -0700 (PDT)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7669A3A0A78 for <tls@ietf.org>; Wed, 18 Aug 2021 19:30:23 -0700 (PDT)
Received: by mail-qk1-x72f.google.com with SMTP id az7so5529157qkb.5 for <tls@ietf.org>; Wed, 18 Aug 2021 19:30:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W/D1cuMuAFLOPcNtJ4F5EOFN3H1irL+1UnqruCBwe08=; b=TdE3Y8xX/+x1RIbP2Z3KCZFXEwKpirDvu0Dzo1YAqR+upTnEbsQuwMInaDhkGr7cyy ZBRSXfl1tcFPdFEnF6bQIYlvQgiSvrwyLJYNZfhZCjLdjGypOR/w0ZzDHDYfEWK1tKzb IUFkfl9k36giQUSKEgufs6WfNPXy4ra1v5dmI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W/D1cuMuAFLOPcNtJ4F5EOFN3H1irL+1UnqruCBwe08=; b=Sa8UFW1GST2ka6BMSJKMUhAOU7c3OkOIMGpw+zicTfXn3ylwHbizHwheSoMAWak+zr O6hx/FYvtTw6CmL2+R1fVdcyjDNMulSXY6n+blAUgniD9om9IQ2vwb5NRUaw2v/AqYen TTgmrM2P3IA7shtp+RBhi1MnFFP+3fsaduRdigBI/px2mYx0pgJYwjsORO56mJAFovD/ 8fnnppPmBQ0NS8+NH4aQUu9qbk+3GHnHhXyyNhCySeE/tFAm6Jo6FJf1D0CzS8izONer 5Kl5nVD+Z+0A0ADjQifYpNYL1ShKjecuW/+uBWlgPI6WJgIGLXj5qqYvxJS7Pwa0btyf BtoQ==
X-Gm-Message-State: AOAM532kebu3Bb0n1vTso35wyWfUVia9V+5Ms0skpgwZXeYNadYrR9w8 +uxHuW0KkeYkUd4vIdYDHUcFA8cK3nEapw==
X-Google-Smtp-Source: ABdhPJzz8WG+5RicW8iFnvvt8Gbvo5+/bdtjy/6+XXg7PzWxeYHql52vsrl5iRiJRzgT18/4WlSZZw==
X-Received: by 2002:a05:620a:c92:: with SMTP id q18mr1387948qki.331.1629340221381; Wed, 18 Aug 2021 19:30:21 -0700 (PDT)
Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id c23sm876118qkk.50.2021.08.18.19.30.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Aug 2021 19:30:20 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <03560d15-6b48-435b-a509-7cbebce153b9@www.fastmail.com>
Date: Wed, 18 Aug 2021 22:30:20 -0400
Cc: TLS List <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2760D629-9990-45F4-A9DE-B41B7698E9CE@sn3rd.com>
References: <b2a65504-4d9b-40bd-b0bb-3b2fa5d37f26@www.fastmail.com> <03560d15-6b48-435b-a509-7cbebce153b9@www.fastmail.com>
To: Martin Thomson <mt@lowentropy.net>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YT9Gogm2QD5z1MbUF9hywpXlSCk>
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: Thu, 19 Aug 2021 02:30:30 -0000

Martin,

The primary reason we are proposing this approach is that it seemed to us to be a bit more explicit about the numbers in this space being part of an experiment. The added benefit here is that we are in some sense greasing the bits too.

spt

> On Aug 17, 2021, at 20:08, Martin Thomson <mt@lowentropy.net> wrote:
> 
> 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
>> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls