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>于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 184.108.40.206/24. The
AUTH knows that ECS(220.127.116.11/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.
For user privacy concern, we can revise ECS(18.104.22.168/24) => EIL (CHINA,
BEIJING, UNICOM)，give a tradeoff between privacy and precise.
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
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
Understanding the Privacy Implications of ECS
And In RFC7871(ECS) <https://tools.ietf.org/html/rfc7871>'s abstract
*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.
> On Mar 17, 2017, at 6:57 PM, Lanlan Pan <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 :
> Any comments or suggestions will be appreciated.
> Yu Fu <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.
> Lanlan & Yu
> >-----Original Message-----
> >From: 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
> >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
> >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
> > 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
> 致礼 Best Regards
> 潘蓝兰 Pan Lanlan
> DNSOP mailing list
致礼 Best Regards
潘蓝兰 Pan Lanlan
DNSOP mailing list