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 <erik+i...@nygren.org> 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 <david...@chromium.org> > 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 <erik+i...@nygren.org> 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 >>> <https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-12.html#RFC8126>], >>> Section 4.5 <https://rfc-editor.org/rfc/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 <s...@sn3rd.com> wrote: >>> >>>> >>>> >>>> > On Sep 18, 2023, at 21:39, Stephen Farrell <stephen.farr...@cs.tcd.ie> >>>> 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
