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
