Re: [TLS] Two Multi-CDN proposals

[Kazuho Oku <[e-mail]>]

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

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.

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.

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.

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

> We are asking for feedback on these PRs, as we would like to merge one
> of them for the next draft version. As #136 is simpler and permits
> extensibility, that is the current preference.
>
> Thanks in advance for your feedback.
>
> Best,
> Chris (no hat, on behalf of the authors)
>
> [1] https://mailarchive.ietf.org/arch/msg/tls/WXrPgaIsIPItDw3IQthmJk9VRlw
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



-- 
Kazuho Oku