Re: [TLS] Adopting HTTPSVC for ESNI

[Eric Rescorla <[e-mail]>]

I have some concerns here that I floated in the bug.

At a high level, ipv[46]hints seems like a regression from the way things
are in ESNI.

-Ekr


On Fri, Oct 25, 2019 at 9:01 AM Tommy Pauly <tpauly=
[e-mail]> wrote:

> 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=[e-mail]> 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 <[e-mail]>
> 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
>> >
>> > 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
>> > [e-mail] https://www.ietf.org/mailman/listinfo/tls
>> >
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
> --
>
> Steven Valdez |  Chrome Privacy Sandbox |  [e-mail] |
>  210-692-4742
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>