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). 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Kazuho Oku _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
