Re: [DNSOP] [dns-privacy] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

[Petr Špaček <[e-mail]>]

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 <[e-mail] <mailto:[e-mail]>>于
> 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 <[e-mail]
>     <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>>于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: [e-mail] <mailto:[e-mail]>
>     [mailto:[e-mail] <mailto:[e-mail]>]
>     > >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
>     > [e-mail] <mailto:[e-mail]>
>     > 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
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> 致礼  Best Regards
> 
> 潘蓝兰  Pan Lanlan