Re: [TLS] RFC8447bis

2021-08-19 Thread David Benjamin
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  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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] RFC8447bis

2021-08-19 Thread Martin Thomson
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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] RFC8447bis

2021-08-19 Thread Salz, Rich
> > 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.

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] RFC8447bis

2021-08-19 Thread Martin Thomson
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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls