2019年3月2日(土) 1:57 Christopher Wood <christopherwoo...@gmail.com>: > > On Wed, Feb 27, 2019 at 11:34 PM Kazuho Oku <kazuho...@gmail.com> 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 <christopherwoo...@gmail.com>: > > > > > > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
