I had indeed forgotten to do this review. However, here it is now, with thanks for the kind pings. Overall, as I said in Honolulu, I think this is in good shape. It¹s a bracing overview of the attack surface against privacy, what the Items of Interest (IOI in RFC 6873 terms) are, and in what ways pervasive surveillance attack can expose them.
Section 1 - "also called caching resolver or full resolver or simply resolver recursive name server" Editorial: s/resolver recursive name server/recursive resolver/ "Because there is typically no caching in the stub resolver, the recursive resolver, unlike the authoritative servers, sees everything." Comment: This isn¹t quite absolute. The DNS caches in some browsers may impact the data collection. Also, in some enterprises, a load balancer or other intermediary between the stubs and the recursive might affect how complete the data collection at a particular recursive is. "It should be noted that DNS recursive resolvers sometimes forward requests to bigger machines, with a larger and more shared cache, the forwarders (and the query hierarchy can be even deeper, with more than two levels of recursive resolvers)." Comment: there are forwarders before recursive resolvers as well. Section 2 - "Privacy risks for the holder of a zone (the risk that someone gets the data) are discussed in [RFC5936 <https://tools.ietf.org/html/rfc5936>]." Comment: the avoidance of enumeration by NSEC3 (RFC 5155) pertains to this as well. This point can be added to the discussion of RFC 5936 in section 2.1 as well. Section 2.2 - "A note about IP addresses: there is currently no IETF document which describes in detail the privacy issues of IP addressing." Comment: This overlooks RFC 4941, which is all about the privacy issues of IP addresses (IPv6). It doesn¹t say anything about IPv4 addresses, but I think it¹s still worthy of note here. Section 2.3 - "Since this also is a reconnaissance technique for subsequent cache poisoning attacks, some counter measures have already been developed and deployed." Comment: A reference would be helpful here. Section 2.5 - "for research purposes [ditl]² Comment: This reference to DITL goes to a 2002 paper that came before the present arrangement at DNS-OARC. Researchers in DNS-OARC are conscious that DNS data is sensitive and DNS-OARC takes some care to ensure that the data is not redistributed and is not open-acess. I think this comes through clearly enough in the 2008 paper by Sebastian, Duane, kc and Marina: http://www.sigcomm.org/sites/default/files/ccr/papers/2008/October/1452335- 1452341.pdf Section 2.5.2 - "The root sees the traffic for all the TLDs (and the huge amount of traffic for non-existing TLDs), but a large TLDs has less caching before it.² Comment: this sentence is hard to understand, even after s/a large TLDs/a large TLD/. What is meant by ³less caching before it²? Is the distinction that (large) TLDs see more cache misses compared with root? A point that could be added is that there are many unpopular domain names in any TLD and these will usually be cache misses, so information from those queries is available to TLDs. "As of today, all the instances of one root name server, L-root, receive together around 20,000 queries per second. While most of it is junk (errors on the TLD name), it gives an idea of the amount of big data which pours into name servers." Comment: this needs a reference. If it¹s helpful, the statistics for A and J roots (in queries per day but similar when you convert to queries per second) are at [a|j].root-servers.org/metrics.html "Also, it seems (TODO: actual numbers requested) that there is a strong concentration of authoritative name servers among ³popular" domains (such as the Alexa Top N list). With the control (or the ability to sniff the traffic) of a few name servers, you can gather a lot of information.² Comment: Is this based on the paper by Bala Krishnamurthy and Craig Wills in IMC 2006?, ³Generating a Privacy Footprint on the Internet² http://www2.research.att.com/~bala/papers/pfp-imc06.pdf? Section 3 - "It [passive dns] is an example of a privacy issue even when no source IP address is kept.² Comment: could you elaborate? In fairness to the Passive DNS paper (and usage of DNS monitoring for things like DDoS mitigation), operators do aggregation and other things to try to limit the exposure of individuals. So this sentence is a bit abrupt considering the efforts made. On 2/16/15, 4:40 AM, "Stephane Bortzmeyer" <[email protected]> wrote: >On Mon, Feb 16, 2015 at 08:05:03AM +0800, > Warren Kumari <[email protected]> wrote > a message of 41 lines which said: > >> I seem to remember Allison was going to send some comments, privacy >> terminology - not sure if that happened? > >If it did, I missed it. Allison? _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
