Re: [TLS] Early IANA Allocations for draft-ietf-tls-esni

[Erik Nygren]

We're going through AUTH48 with SVCB right now and reviewing edits from the
RFC Editor.  I think there is a good question of how to handle this.  Right
now it is "RESERVED (will be used for ECH)" for SvcParamKey "ech" (5) but
we also say:

New entries in this registry are subject to an Expert Review registration
policy ([RFC8126
],
Section 4.5 ). The
designated expert MUST ensure that the Format Reference is stable and
publicly available, and that it specifies how to convert the
SvcParamValue's presentation format to wire format. The Format Reference
MAY be any individual's Internet-Draft, or a document from any other source
with similar assurances of stability and availability. An entry MAY specify
a Format Reference of the form "Same as (other key Name)" if it uses the
same presentation and wire formats as an existing key.

This puts this in a weird state given that the ECH specification is not
stable yet and did have some changes.
Perhaps a question for the dnsops chairs and Warren as well?

Should draft-ietf-tls-esni be referenced informationally?  It seems like
there's a risk of "ech=" (5) getting burned as a codepoint
given that implementations may exist with different interpretations...

  Erik



On Tue, Sep 19, 2023 at 11:22 AM Sean Turner  wrote:

>
>
> > On Sep 18, 2023, at 21:39, Stephen Farrell 
> wrote:
> >
> > I wonder if we also need to say something about the ech= SVCB
> > parameter value 5 that's reserved at [1]? Not sure, but maybe
> > no harm to make that "official" at the same time if possible.
> > (There could be current code that assumes that 5 in a wire-
> > format HTTPS RR value maps to 0xff0d within an ECHConfigList
> > even if that isn't really right.)
>
> I’ll check with the dnsops chairs.
>
> spt
> ___
> 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] Early IANA Allocations for draft-ietf-tls-esni

[David Benjamin]

I don't think what we do with the registry has any bearing on whether the
codepoint is burned. There are already draft ECH deployments today, on both
the client and server side, independent of what we later put in the
registry. Rather, the ECHConfigList structure is internally versioned, so
as long as we keep that structure, the codepoint isn't burned. If we find
we need to change the versioning scheme, that will indeed be incompatible,
and we'll need to switch codepoints. I wouldn't expect that to happen, but
I don't think we need to be deathly worried about it either. Codepoints are
plentiful.

So I'd suggest that reserving it makes sense (to make sure no one allocates
it for something unrelated to ECH), and we can leave draft-sbn-tls-svcb-ech
to sort out the true allocation. If that doesn't work procedurally, it's
probably not worth the energy and we can just omit the entry from the SVCB
spec. We'd just then be relying on the expert review to not accidentally
use the value for something else.

On Wed, Sep 20, 2023 at 2:44 PM Erik Nygren  wrote:

> We're going through AUTH48 with SVCB right now and reviewing edits from
> the RFC Editor.  I think there is a good question of how to handle this.
> Right now it is "RESERVED (will be used for ECH)" for SvcParamKey "ech" (5)
> but we also say:
>
> New entries in this registry are subject to an Expert Review registration
> policy ([RFC8126
> ],
> Section 4.5 ). The
> designated expert MUST ensure that the Format Reference is stable and
> publicly available, and that it specifies how to convert the
> SvcParamValue's presentation format to wire format. The Format Reference
> MAY be any individual's Internet-Draft, or a document from any other source
> with similar assurances of stability and availability. An entry MAY specify
> a Format Reference of the form "Same as (other key Name)" if it uses the
> same presentation and wire formats as an existing key.
>
> This puts this in a weird state given that the ECH specification is not
> stable yet and did have some changes.
> Perhaps a question for the dnsops chairs and Warren as well?
>
> Should draft-ietf-tls-esni be referenced informationally?  It seems like
> there's a risk of "ech=" (5) getting burned as a codepoint
> given that implementations may exist with different interpretations...
>
>   Erik
>
>
>
> On Tue, Sep 19, 2023 at 11:22 AM Sean Turner  wrote:
>
>>
>>
>> > On Sep 18, 2023, at 21:39, Stephen Farrell 
>> wrote:
>> >
>> > I wonder if we also need to say something about the ech= SVCB
>> > parameter value 5 that's reserved at [1]? Not sure, but maybe
>> > no harm to make that "official" at the same time if possible.
>> > (There could be current code that assumes that 5 in a wire-
>> > format HTTPS RR value maps to 0xff0d within an ECHConfigList
>> > even if that isn't really right.)
>>
>> I’ll check with the dnsops chairs.
>>
>> spt
>> ___
>> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Early IANA Allocations for draft-ietf-tls-esni

[Erik Nygren]

The registry already exists with the pointer to ech (5) :

https://www.iana.org/assignments/dns-svcb/dns-svcb.xhtml

so no action is needed to make sure it isn't allocated for something else.
(Removing it would be more effort and more problematic.)
Do we believe the draft is stable enough that we should reference it
informationally for that code point?


On Wed, Sep 20, 2023 at 3:01 PM David Benjamin 
wrote:

> I don't think what we do with the registry has any bearing on whether the
> codepoint is burned. There are already draft ECH deployments today, on both
> the client and server side, independent of what we later put in the
> registry. Rather, the ECHConfigList structure is internally versioned, so
> as long as we keep that structure, the codepoint isn't burned. If we find
> we need to change the versioning scheme, that will indeed be incompatible,
> and we'll need to switch codepoints. I wouldn't expect that to happen, but
> I don't think we need to be deathly worried about it either. Codepoints are
> plentiful.
>
> So I'd suggest that reserving it makes sense (to make sure no one
> allocates it for something unrelated to ECH), and we can
> leave draft-sbn-tls-svcb-ech to sort out the true allocation. If that
> doesn't work procedurally, it's probably not worth the energy and we can
> just omit the entry from the SVCB spec. We'd just then be relying on the
> expert review to not accidentally use the value for something else.
>
> On Wed, Sep 20, 2023 at 2:44 PM Erik Nygren  wrote:
>
>> We're going through AUTH48 with SVCB right now and reviewing edits from
>> the RFC Editor.  I think there is a good question of how to handle this.
>> Right now it is "RESERVED (will be used for ECH)" for SvcParamKey "ech" (5)
>> but we also say:
>>
>> New entries in this registry are subject to an Expert Review registration
>> policy ([RFC8126
>> ],
>> Section 4.5 ). The
>> designated expert MUST ensure that the Format Reference is stable and
>> publicly available, and that it specifies how to convert the
>> SvcParamValue's presentation format to wire format. The Format Reference
>> MAY be any individual's Internet-Draft, or a document from any other source
>> with similar assurances of stability and availability. An entry MAY specify
>> a Format Reference of the form "Same as (other key Name)" if it uses the
>> same presentation and wire formats as an existing key.
>>
>> This puts this in a weird state given that the ECH specification is not
>> stable yet and did have some changes.
>> Perhaps a question for the dnsops chairs and Warren as well?
>>
>> Should draft-ietf-tls-esni be referenced informationally?  It seems like
>> there's a risk of "ech=" (5) getting burned as a codepoint
>> given that implementations may exist with different interpretations...
>>
>>   Erik
>>
>>
>>
>> On Tue, Sep 19, 2023 at 11:22 AM Sean Turner  wrote:
>>
>>>
>>>
>>> > On Sep 18, 2023, at 21:39, Stephen Farrell 
>>> wrote:
>>> >
>>> > I wonder if we also need to say something about the ech= SVCB
>>> > parameter value 5 that's reserved at [1]? Not sure, but maybe
>>> > no harm to make that "official" at the same time if possible.
>>> > (There could be current code that assumes that 5 in a wire-
>>> > format HTTPS RR value maps to 0xff0d within an ECHConfigList
>>> > even if that isn't really right.)
>>>
>>> I’ll check with the dnsops chairs.
>>>
>>> spt
>>> ___
>>> 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
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Early IANA Allocations for draft-ietf-tls-esni

[David Benjamin]

To clarify, when you say "the draft" do you mean draft-ietf-tls-esni
or draft-sbn-tls-svcb-ech? draft-ietf-tls-esni doesn't actually define a
format for it in the first place. draft-sbn-tls-svcb-ech does... that got
adopted, right? Is there a TLSWG version?

Messiness around the status of the draft aside, the format for ech (5) is
stable. In the unlikely event that we want to change the format, we will
also need to change the codepoint to avoid breaking things. So ech (5) will
forever mean what it currently means: an ECHConfigList of
internally-versioned ECHConfigs.

On Wed, Sep 20, 2023 at 3:08 PM Erik Nygren  wrote:

> The registry already exists with the pointer to ech (5) :
>
> https://www.iana.org/assignments/dns-svcb/dns-svcb.xhtml
>
> so no action is needed to make sure it isn't allocated for something
> else.  (Removing it would be more effort and more problematic.)
> Do we believe the draft is stable enough that we should reference it
> informationally for that code point?
>
>
> On Wed, Sep 20, 2023 at 3:01 PM David Benjamin 
> wrote:
>
>> I don't think what we do with the registry has any bearing on whether the
>> codepoint is burned. There are already draft ECH deployments today, on both
>> the client and server side, independent of what we later put in the
>> registry. Rather, the ECHConfigList structure is internally versioned, so
>> as long as we keep that structure, the codepoint isn't burned. If we find
>> we need to change the versioning scheme, that will indeed be incompatible,
>> and we'll need to switch codepoints. I wouldn't expect that to happen, but
>> I don't think we need to be deathly worried about it either. Codepoints are
>> plentiful.
>>
>> So I'd suggest that reserving it makes sense (to make sure no one
>> allocates it for something unrelated to ECH), and we can
>> leave draft-sbn-tls-svcb-ech to sort out the true allocation. If that
>> doesn't work procedurally, it's probably not worth the energy and we can
>> just omit the entry from the SVCB spec. We'd just then be relying on the
>> expert review to not accidentally use the value for something else.
>>
>> On Wed, Sep 20, 2023 at 2:44 PM Erik Nygren  wrote:
>>
>>> We're going through AUTH48 with SVCB right now and reviewing edits from
>>> the RFC Editor.  I think there is a good question of how to handle this.
>>> Right now it is "RESERVED (will be used for ECH)" for SvcParamKey "ech" (5)
>>> but we also say:
>>>
>>> New entries in this registry are subject to an Expert Review
>>> registration policy ([RFC8126
>>> ],
>>> Section 4.5 ). The
>>> designated expert MUST ensure that the Format Reference is stable and
>>> publicly available, and that it specifies how to convert the
>>> SvcParamValue's presentation format to wire format. The Format Reference
>>> MAY be any individual's Internet-Draft, or a document from any other source
>>> with similar assurances of stability and availability. An entry MAY specify
>>> a Format Reference of the form "Same as (other key Name)" if it uses the
>>> same presentation and wire formats as an existing key.
>>>
>>> This puts this in a weird state given that the ECH specification is not
>>> stable yet and did have some changes.
>>> Perhaps a question for the dnsops chairs and Warren as well?
>>>
>>> Should draft-ietf-tls-esni be referenced informationally?  It seems
>>> like there's a risk of "ech=" (5) getting burned as a codepoint
>>> given that implementations may exist with different interpretations...
>>>
>>>   Erik
>>>
>>>
>>>
>>> On Tue, Sep 19, 2023 at 11:22 AM Sean Turner  wrote:
>>>


 > On Sep 18, 2023, at 21:39, Stephen Farrell 
 wrote:
 >
 > I wonder if we also need to say something about the ech= SVCB
 > parameter value 5 that's reserved at [1]? Not sure, but maybe
 > no harm to make that "official" at the same time if possible.
 > (There could be current code that assumes that 5 in a wire-
 > format HTTPS RR value maps to 0xff0d within an ECHConfigList
 > even if that isn't really right.)

 I’ll check with the dnsops chairs.

 spt
 ___
 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
>>>
>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls