Hello, On 20.3.2017 08:49, Lanlan Pan wrote: > Hi Barry, > > Thanks for your comments. > > Because the draft discussed the DNS privacy problem of ECS, and was first > presented in In NDSS 2017 DNS Privacy Workshop, so I cc the email to dprive > WG. > > > Barry Raveendran Greene <bgre...@senki.org <mailto:bgre...@senki.org>>于 > 2017年3月19日周日 上午2:22写道： > > Hello Yu Fu, > > I was not at the workshop. Warren already mentioned some issues. I > second what he is saying in a stronger terms: > > + What you are proposing has no value for optimizing content > delivery on the Internet. Physical location and the topology of > content delivery do not match. Also, Anycast is used. It is NOT > expensive. The reason why so many CDN operator use DNS based tools > for content delivery is granularity of action. An edge compute > system (i.e. what many CDNs are) can do all sorts of checks via DNS > approach vs an Anycast approach. > > > Everyone has known that physical location and the topology of content > delivery DO NOT MATCH. > As last mail reply to Warren, my proposal can offer the SAME critical > information for authoritative server to make tailored response decision > as ECS's client subnet. > Because in database such as maxmind, ECS (client subnet) can be map > into <AS number, country, province, ISP>, which also guide network > topology. > Therefore, if ECS has ANY value for optimizing content delivery on the > Internet, then EIL has. > > For example，If ECS is tell AUTH : the query is from 114.240.0.0/24 > <http://114.240.0.0/24>. The AUTH knows that ECS(114.240.0.0/24 > <http://114.240.0.0/24>) is indicated (CHINA, BEIJING, UNICOM), which is > not only geolocation, but also contains network topology information. > Then AUTH can return satisfied ip address according to the topology of > content delivery.
Thank you for this example, it helps. > For user privacy concern, we can revise ECS(114.240.0.0/24 > <http://114.240.0.0/24>) => EIL (CHINA, BEIJING, UNICOM)，give a > tradeoff between privacy and precise. Nice, this sounds like appropriate tradeoff to me. Side-effect of this is that it removes need to maintain copies of various Geo-IP databases all over the place, which is an improvement to operational practice. To sum it up, I support this. Nice work! Petr Špaček @ CZ.NIC > |||| > > > > Also, the ECS security assessment if off. ECS from the resolver to > the aDNS is sending a subnet configured by the operator of the rDNS. > Once the connection to the client to the CDN is made, the CDN > operator has the full details of the client. The term “leak client > subnet to AUTH” is misleading from a “privacy risk.” Once the > connection is made to my CDN, I know the IP specifics. > > > Privacy risk of ECS: > 1. If ECS is clear text in the resolution path => eavesdrop => encrypt > the dns traffic, in long term. > 2. The passive DNS log analysis risk > - avoid recursive dns analysis, reserve the optimization ECS, we can > send EIL query by some proxy tunnel. > - avoid authoritative dns analysis. If CDN is ALSO the authoritative > server, AGREE WITH YOU. But to a third-party authoritative service, the > more domains publish their zones on the third-party authoritative > server, the more end user privacy information can be gathered by the > authoritative server according to the ECS queries from recursive. > > ECS's security issue is described in DNS Privacy Workshop 2017 > Background > <http://www.internetsociety.org/events/ndss-symposium/ndss-symposium- > 2017/dns-privacy-workshop-2017-call-papers>， Understanding the Privacy > Implications of ECS > <http://www.cc.gatech.edu/~ynadji3/docs/pubs/dimva16_ecs.pdf>. > And In RFC7871(ECS) <https://tools.ietf.org/html/rfc7871>'s abstract > section: > > /Since it has some known operational and privacy shortcomings, a revision > will be worked through the IETF for improvement./ > > > > + What you are proposing has great value for Law Enforcement and > State Security. It would cut out the Operator as the middle man and > eliminate the need for a court order to release details on suspects. > > This also is a tool for criminals. I can easily see bad guys who are > dropping ransomware use this as a tool to say “pay up or I’ll SWAT > your house” or move from E-mail exertion threats to phone based threats. > > Barry > > > On Mar 17, 2017, at 6:57 PM, Lanlan Pan <abby...@gmail.com > <mailto:abby...@gmail.com>> wrote: > > > > Hi all, > > > > In NDSS 2017 DNS Privacy Workshop, I presented a EIL option as an > alternative privacy improvement for ECS. > > > > The paper and slide are attached. Test code in github : > https://github.com/abbypan/dns_test_eil > > > > Any comments or suggestions will be appreciated. > > > > Regards. > > > > Yu Fu <f...@cnnic.cn <mailto:f...@cnnic.cn>>于2017年3月16日周四 上 > 午10:37写道： > > Hi all, > > > > We have submitted a new draft as draft-pan-dnsop-edns-isp-location-00. > > This document is an improved solution for ECS(RFC7871), describes > an EDNS ISP Location (EIL) extension to address the privacy problem > of ECS, find the right balance between privacy improvement and user > experience optimization. EIL is defined to convey ISP location > information that is relevant to the DNS message. It will provide > sufficient information for the Authoritative Server to decide the > response without guessing geolocation of the IP address. > > > > Your comments are appreciated. > > > > Thanks > > Lanlan & Yu > > > > >-----Original Message----- > > >From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> > [mailto:internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>] > > >Sent: Monday, March 13, 2017 6:07 PM > > >To: Pan Lanlan; Lanlan Pan; Yu Fu > > >Subject: New Version Notification for > draft-pan-dnsop-edns-isp-location-00.txt > > > > > > > > >A new version of I-D, draft-pan-dnsop-edns-isp-location-00.txt > > >has been successfully submitted by Yu Fu and posted to the IETF > repository. > > > > > >Name: draft-pan-dnsop-edns-isp-location > > >Revision: 00 > > >Title: ISP Location in DNS Queries > > >Document date: 2017-03-13 > > >Group: Individual Submission > > >Pages: 14 > > >URL: > > https://www.ietf.org/internet-drafts/draft-pan-dnsop-edns-isp-location-00.txt > > >Status: > https://datatracker.ietf.org/doc/draft-pan-dnsop-edns-isp-location/ > > >Htmlized: > https://tools.ietf.org/html/draft-pan-dnsop-edns-isp-location-00 > > > > > > > > >Abstract: > > > This document describes an Extension Mechanisms for DNS (EDNS0) > > > option that is in active use to carry information about the > network > > > that originated a DNS query and the network for which the > subsequent > > > response can be cached. > > > > > > It is inspired by EDNS Client Subnet (ECS) with some privacy > > > considerations, goals to reduce the "guess geolocation of client's > > > IP" work on Authoritative Nameservers. > > > > > > > > > > > > The IETF Secretariat > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org <mailto:DNSOP@ietf.org> > > https://www.ietf.org/mailman/listinfo/dnsop > > -- > > 致礼 Best Regards > > > > 潘蓝兰 Pan Lanlan > > > > <Slide_EIL_Dealing_with_the_Privacy_Problem_of_ECS_PanLanlan.pdf><Paper_EIL_Dealing_with_the_Privacy_Problem_of_ECS.pdf>_______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org <mailto:DNSOP@ietf.org> > > https://www.ietf.org/mailman/listinfo/dnsop > > -- > 致礼 Best Regards > > 潘蓝兰 Pan Lanlan _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
