Subject: Re: [Tls-reg-review] [TLS] RFC8447bis

From: "Christopher Wood" <[email-masked]>
Date: Fri, 20 Aug 2021 05:52:44 -0700

(-list, +Martin, +tls-reg-review)

Martin's proposal is reasonable, but I have some questions for folks more familiar with the registries and their history:

- Does the revised registry policy, which would update the existing registries with a temporary or provisional marker, require RFC publication? I believe it does, similar to Section 5 of RFC8447 (https://datatracker.ietf.org/doc/html/rfc8447#section-5).
- Is it reasonable to expect that the registry can be promptly updated when provisional entries expire?

Thanks!
Chris

On Thu, Aug 19, 2021, at 7:36 AM, David Benjamin wrote:
> I agree with Martin.
> 
> At the end of the day, a collision between IANA and a large-scale 
> experiment isn't significantly more interesting than a collision 
> between two large-scale experiments. They will still cause interop 
> problems. There isn't really any collision benefit to blocking off a 
> range. If anything, there is a *more* collision risk: the experimental 
> block is much smaller than the full codepoint space, yet, by their 
> nature, there will be more experimental allocations than final ones. 
> ECH has gone through so many now. Indeed, while ECH hasn't been 
> constraining itself to a range, it and a few other drafts have had a 
> habit of only picking from the upper 256 unused code points. Yet, by 
> doing that, one of ECH's experimental code points collided with one of 
> Delegated Credentials' experimental code points. Thankfully, I don't 
> believe that version of DC was ever shipped large-scale.
> 
> The concern that people will special-case the range is also very real, 
> and would invalidate anything we learn from experiments using that 
> range. We're already seeing folks special-case GREASE code points. (In 
> hindsight, I think GREASE should not have been reflected in the table 
> proper.) One of TLS stacks which inspired GREASE managed to, over the 
> course of fixing its various bugs, even treat "Unassigned" and 
> "Reserved for Private Use" differently and briefly only allow unknown 
> Private Use values!
> 
> It is true that the TLS space is a little tighter than QUIC, but I 
> think the same lessons apply.
> 
> On Thu, Aug 19, 2021 at 10:18 AM Martin Thomson <[email-masked]> wrote:
> > On Thu, Aug 19, 2021, at 23:14, Salz, Rich wrote:
> > > I understand this concern. I am sympathetic to it. But perhaps 
> > > large-scale experiments on the whole Internet aren't the scope here?  
> > > Those kinds of things seem to ask for an early allocation. I am 
> > > thinking, in particular, of some GOST/TLS identifiers that weren't 
> > > quite right.
> > 
> > Nothing wrong with due diligence before allocation, or even a little reticence.  But I'm also concerned about people putting these ranges in their code and doing something special with them.  Like "this is experimental, so we will ignore these always" or similarly silly things.  You don't need to have a reserved space to say that a particular codepoint is temporary.
> > 
> > _______________________________________________
> > TLS mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 20 Aug 2021 17:47:14 +0000

As one of the three, I think the value for any temporary/provisional entries is an "N" in the recommended column. On removal, perhaps IANA should be asked as I don't recall ever removing an entry.

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 20 Aug 2021 11:00:58 -0700

On Fri, Aug 20, 2021, at 10:47 AM, Salz, Rich wrote:
> As one of the three, I think the value for any temporary/provisional 
> entries is an "N" in the recommended column. On removal, perhaps IANA 
> should be asked as I don't recall ever removing an entry.

Thanks! I'll reach out and see what they have to say. 

Best,
Chris

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 20 Aug 2021 18:02:32 +0000

One interesting possibility is to put an expiration date in the Recommended column.  Do all affected registries have one of those?

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 20 Aug 2021 11:31:26 -0700

On Fri, Aug 20, 2021, at 11:02 AM, Salz, Rich wrote:
> One interesting possibility is to put an expiration date in the 
> Recommended column.  Do all affected registries have one of those?
 
Yep -- the ones currently in Sean and Joe's document (Supported Groups and Extensions) both have a Recommended column.

Best,
Chris

---

From: Sean Turner <[email-masked]>
Date: Fri, 27 Aug 2021 10:37:48 -0400

> On Aug 20, 2021, at 14:31, Christopher Wood <[email-masked]> wrote:
> 

We added a Recommended column to believe all but the orphaned registries.

spt

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 31 Aug 2021 16:06:07 -0700

> - Does the revised registry policy, which would update the existing registries with a temporary or provisional marker, require RFC publication? I believe it does, similar to Section 5 of RFC8447 (h…

I also believe it requires an RFC.

> - Is it reasonable to expect that the registry can be promptly updated when provisional entries expire?

Yes, IANA already has a process for tracking things that are expiring and
it generally works fine.

-Ben