Subject: [TLS] RFC8447bis

From: "Christopher Wood" <[email-masked]>
Date: Tue, 17 Aug 2021 16:34:38 -0700

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

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 18 Aug 2021 10:08:20 +1000

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:
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Aug 2021 18:31:52 -0700

On Tue, Aug 17, 2021 at 5:09 PM Martin Thomson <[email-masked]> wrote:

> 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 agree with the bit about the unified space.

I'm a bit less sure about randomly versus sequentially, but I could go
either way. IIRC the QUIC thing leaned somewhat on the space being very big.

-Ekr

> > (
> https://datatracker.ietf.org/doc/html/draft-salowey-tls-rfc8447bis-00#section-17
> )
> > (
> https://datatracker.ietf.org/doc/html/draft-salowey-tls-rfc8447bis-00#section-5
> )
> >

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 18 Aug 2021 12:00:00 +1000

> either way. IIRC the QUIC thing leaned somewhat on the space being very 

That is true.  QUIC has a large space, but TLS is a lot smaller.  This is just my attempt to avoid a repeat of the extension 26 mess.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Aug 2021 13:28:57 +0000

*   I'm a bit less sure about randomly versus sequentially, but I could go either way. IIRC the QUIC thing leaned somewhat on the space being very big.

As one of the three TLS registry designated experts, I’d rather not pick randomly.

To be pedantic, of course, sequential could be random, just predictably so :)

---

From: Sean Turner <[email-masked]>
Date: Wed, 18 Aug 2021 22:30:20 -0400

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 <[email-masked]> wrote:
>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 19 Aug 2021 22:48:54 +1000

On Thu, Aug 19, 2021, at 12:30, Sean Turner wrote:
> 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.

I understand.  It's just that, as I said...

> > 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.

That is, when you mark this space out, you are saying that it's special.  People might try to treat it as such, but it won't be once a few experiments get successful.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Aug 2021 13:14:38 +0000

>    That is, when you mark this space out, you are saying that it's special.  People might try to treat it as such, but it won't be once a few experiments get successful.

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.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 20 Aug 2021 00:17:47 +1000

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.

---

From: David Benjamin <[email-masked]>
Date: Thu, 19 Aug 2021 10:36:59 -0400

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:

> 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.
>