Subject: [TLS] Adopting HTTPSVC for ESNI

From: "Christopher Wood" <[email-masked]>
Date: Thu, 24 Oct 2019 17:28:26 -0700

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.

Best,
Chris (no hat)

[1] https://mailarchive.ietf.org/arch/msg/dnsop/9zCxhCfIhDzA3Cv3D2k4NF_nj4s

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Oct 2019 01:18:57 +0000

So a global replace of ESNIKeys with ESNIConfig and deleting a now-redundant section.  Looks good to me!

>       https://github.com/tlswg/draft-ietf-tls-esni/pull/187

Very happy to see the re-use!

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Oct 2019 11:28:51 +0100

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:
> 

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
>
>  _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Steven Valdez <[email-masked]>
Date: Fri, 25 Oct 2019 10:57:37 -0400

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 <[email-masked]>
wrote:

> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 

Steven Valdez |  Chrome Privacy Sandbox |  [email-masked] |
 210-692-4742

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 25 Oct 2019 09:00:13 -0700

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=[email-masked]> 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).
> 
> (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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hiya,
> 
> > https://github.com/tlswg/draft-ietf-tls-esni/pull/187 <https://github.com/tlswg/draft-ietf-tls-esni/pull/187>
> > 
> > https://mailarchive.ietf..org/arch/msg/dnsop/9zCxhCfIhDzA3Cv3D2k4NF_nj4s <https://mailarchive.ietf.org/arch/msg/dnsop/9zCxhCfIhDzA3Cv3D2k4NF_nj4s>
> >
> > [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> > 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> 
> 
> -- 
> 
> Steven Valdez |	 Chrome Privacy Sandbox |	 [email-masked] <mailto:[email-masked]> |	 210-692-4742

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Oct 2019 11:37:19 -0700

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=
[email-masked]> 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=[email-masked]> wrote:
>
>> https://mailarchive.ietf..org/arch/msg/dnsop/9zCxhCfIhDzA3Cv3D2k4NF_nj4s
>> <https://mailarchive.ietf.org/arch/msg/dnsop/9zCxhCfIhDzA3Cv3D2k4NF_nj4s>
>> >