I'm also supportive of this change, and in general of using HTTPSSVC for the
transmission of ESNI keys, speaking as an implementer at Apple.
With regards to the per-version structure, I agree with Steven that the
structure of the configuration should be able to change between versions. I
think that either specifying that the structure can change with versions, or
just moving the version into the label (Stephen's suggestion) would work. I
have a *slight* concern for the case of using a different HTTPSSVC label for
each version or set of extensions, since the code that parses out the records
may be distinct from the code that uses the keys, and it may be easier to fetch
the right information out if it has a consistent label name. Not a huge issue
either way, though.
Thanks,
Tommy
> On Oct 25, 2019, at 7:57 AM, Steven Valdez
> <svaldez=40google....@dmarc.ietf.org> wrote:
>
> Chrome is supportive of this change, and will likely work on implementing
> HTTPSSVC into our DNS stack once the draft progresses further.
>
> As for the ESNIKeys/ESNIConfig change, we were actually thinking of something
> that further abstracted HTTPSSVC having to understand anything about ESNI
> from the ESNI versioning:
>
> The ESNIKeys naming was always a bit confusing since you could have multiple
> ESNIKeys, and there wasn't a great way of referring to those.
>
> HTTPSSVC records include a single ESNIBundle which is length prefixed and
> contains one or more ESNIConfigs. (to allow an endpoint to publish multiple
> ESNIConfigs, potentially supporting multiple versions of the ESNI record).
>
> Each ESNIConfig is then just a version and then a version-specific structure.
> (to allow the entire structure of the ESNIConfigInner to arbitrarily change
> at different versions).
>
> Something roughly like the following:
>
> ESNIBundle {
> ESNIConfig<2..2^16-1>;
> };
>
> ESNIConfig {
> version,
> select (version) {
> case 0: {
> opaque public_name<1..2^16-1>;
> KeyShareEntry keys<4..2^16-1>;
> CipherSuite cipher_suites<2..2^16-2>;
> uint16 padded_length;
> Extension extensions<0..2^16-1>;
> }
> }
> };
>
> (alternatively maybe make an ESNIConfigInner and stuff an opaque in
> ESNIConfig that is version-specific, not sure what the right presentation
> looks like)
>
> On Fri, Oct 25, 2019 at 6:29 AM Stephen Farrell <stephen.farr...@cs.tcd.ie
> <mailto:stephen.farr...@cs.tcd.ie>> wrote:
>
> Hiya,
>
> On 25/10/2019 01:28, Christopher Wood wrote:
> > Hi folks,
> >
> > DNSOP recently adopted HTTPSSVC [1]. Rather than have two ways of
> > doing the same thing, I've put together a PR that drops the custom
> > ESNI RRType in favor of this more general (yet feature compatible)
> > Resource Record:
> >
> > https://github.com/tlswg/draft-ietf-tls-esni/pull/187
> > <https://github.com/tlswg/draft-ietf-tls-esni/pull/187>
> >
> > Please have a look and comment before next Friday. We'd like to land
> > this before Singapore.
>
> I'm supportive of this change, on the assumption that browsers are
> really going to use HTTPSSVC.
>
> If that lands as-is, please bump the version to ff04 and I don't
> see much benefit in changing from ESNIKeys to ESNIConfig (seems
> more likely to confuse than help to me).
>
> Going further, I think we ought also take advantage of this to
> simplify the ESNIKeys/ESNIConfig structure. We don't need to do
> that right now but we could.
>
> There are two related simplifications that'd make sense to me:
>
> - remove the version field and encode that in the HTTPSSVC label
> (so it'd be something like esnikeys05="/wElr6L2ACQAHQ...") - I
> think that'd lead to fewer cases where HTTPSSVC code needs to
> understand what's inside the ESNIConfig structure.
>
> - similarly, remove the extensions field from ESNIConfig, and
> require a new label in HTTPSSVC if something new is really needed
>
> Cheers,
> S.
>
> >
> > Best, Chris (no hat)
> >
> > [1]
> > https://mailarchive.ietf..org/arch/msg/dnsop/9zCxhCfIhDzA3Cv3D2k4NF_nj4s
> > <https://mailarchive.ietf.org/arch/msg/dnsop/9zCxhCfIhDzA3Cv3D2k4NF_nj4s>
> >
> > _______________________________________________ TLS mailing list
> > TLS@ietf.org <mailto:TLS@ietf.org>
> > https://www.ietf.org/mailman/listinfo/tls
> > <https://www.ietf.org/mailman/listinfo/tls>
> >
> _______________________________________________
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls
> <https://www.ietf.org/mailman/listinfo/tls>
>
>
> --
>
> Steven Valdez | Chrome Privacy Sandbox | sval...@google.com
> <mailto:sval...@google.com> | 210-692-4742
> _______________________________________________
> 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
