Re: [TLS] Two Multi-CDN proposals

[Christopher Wood <[e-mail]>]

On Wed, Feb 27, 2019 at 11:34 PM Kazuho Oku <[e-mail]> wrote:
>
> Hi Chris,
>
> Thank you for writing down the PRs describing possible designs that we
> might adopt. I think it helps a lot in understanding the details and
> making accurate comparisons.
>
> My comments inline.
>
> 2019年2月27日(水) 8:19 Christopher Wood <[e-mail]>:
> >
> > Hi folks,
> >
> > Below are two PRs that seek to address the multi-CDN issue discussed
> > on this list and in meetings:
> >
> >    1. https://github.com/tlswg/draft-ietf-tls-esni/pull/136
> >    2. https://github.com/tlswg/draft-ietf-tls-esni/pull/137
> >
> > #136 implements the combined or stapled record approach discussed
> > several times, most recently in [1]. It includes these via an ESNIKeys
> > extension.
>
> Reading the PR, I think that there is a mild privacy concern. The
> issue with the unified record proposal is that it incentivizes the
> operators to create more ESNI records possibly using different keys,
> which is against the design principle of ESNI: provide anonymity set
> by using the least number of keys.
>
> Retaining address resolution unbundled with ESNI incentivizes the
> operator to use less number of keys; for example they might just use
> one key at a time. That would be a nice property to have, especially
> in terms of transparency. It would help third parties verify that an
> operator is actually providing an anonymity set (rather than just
> pretending to use ESNI).

I don't quite agree with this. Operators can already use different
keys across records if they so choose. That said, given the concern,
we could add advisory text suggesting that operators use as few ESNI
keys as possible to cover addresses.

> Also, I would like to point out that it is only when one key is used
> by each of the provider at a given time that it would be possible to
> use ESNI from a network that blocks DoH or DoT; a user can write the
> IP addresses of services he/she wants to access in the hosts file, and
> supply the ESNI key to the client he/she uses. Such a hack becomes
> difficult under the unified approach, where operators could synthesize
> different keys based on various conditions.

Good point!

>
> At the least, if we are to adopt #136, I think we should change the
> definition of record digest included in the ClientHello extension so
> that it does not cover the "address_set" extension of the ESNI record.
> Otherwise, we would be exposing to the wire the fingerprint of the set
> of IP addresses contained in the DNS response the client received
> through a secure channel, whereas in the split record approach you
> only leak the ESNI key being used and the IP address the client has
> chosen.

I'm not sure this is an issue. Clients that use HappyEyeballs will
already reveal the set of addresses by attempting to connect to them.

> As much as I like the idea of bundling IP addresses and ESNI key, I am
> concerned if the requirement to bundle different types of records is a
> requirement specific to ESNI. If not, I think we should (in the long
> term) try to create a generic solution, while in the short time we
> could rely on a more limited mechanism as proposed in #137.

In my view, since these are both extensions, they can both proceed in
parallel. If some operators can support #136, and can do so without
creating many ESNI keys, then I think it's worth including. Operators
for which this is not a concern do not need to support the extension,
right?

> > #137 builds on this design with a mechanism that lets
> > clients detect and recover from A/AAAA and ESNI mismatch (if desired).
> > It is certainly more complex in several respects. A third variant,
> > which is not (yet) in PR form, is a simplification of #137 wherein
> > ESNIKeys addresses are only used as filters, instead of filters *or*
> > complete addresses.
>
> I think using IP address blocks to limit the validity of the ESNI key
> is a fine approach. I do not oppose to having a name-based filter if
> it's impossible for certain operators to apply the IP address-based
> filtering approach.

Indeed -- that's the only reason the name exists.

Best,
Chris