Re: [TLS] Two Multi-CDN proposals

[Kazuho Oku <[e-mail]>]

2019年3月2日(土) 1:57 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.

Having a guidance sounds sufficient to me.

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

Using happy eyeballs does not always mean that the clients are
exposing all the addresses in the address_set. IIUC, a client does not
eyeball between multiple addresses belonging to the same address
family.

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

I think the idea of using extensions is a nice approach to move
forward. I won't oppose to having an "option" to change the way the
address is being resolved, as long as it does not hinder the
standardization of the draft without the feature.
>
> > > #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



--
Kazuho Oku