Hiya Stephen, On 2/25/15 10:13 PM, Stephen Farrell wrote: > > This document is very good stuff, many thanks. I think it ought > go forward regardless of how my comment below is dealt with.
I agree! > > One issue I don't think is covered well enough is the potential > (I don't know if this is actual) risk of re-identification via > sets of DNS queries. Are you thinking of looking at patterns of qname values/labels or just some number of packets going towards a DNS resolver within a certain time frame? If it is the latter, I think it is out of scope since that type of analysis can be done on any type of traffic. If it is the former, I agree that such analysis can be prevented with encryption of DNS queries going to the resolver. Regards, Brian > > Imagine the adversary identifies a user somehow, and then records > that that user sends queries for a set of names within some time > window. Perhaps due to a browser "opening all" bookmarks in tabs, > or due to some sequencing of application startups on reboot. In > any case, the adversary recognises some pattern in DNS queries > that is unlikely to be seen at random. > > If the adversary later sees a matching set of DNS queries within > a time window, then the adversary may have re-identified the victim > without any other knowledge, and e.g. might be able to see the IP > address of the victim and then leverage that to launch further > attacks or simply to add additional tracking information to the > victim's surveillance "history." Equally, the adversary might get > this wrong, and incorrectly claim re-identification with possible > bad consequences for an incorrectly re-identified second victim. > > I think (more) explicitly calling out such threats would be a fine > thing. If there are studies that have quantified any of this then > referencing those would be great - I've not gone looking and don't > know of any off the top of my head, sorry. I also wonder if such > signals, if detectable (and I bet a beer they are), might be just as > detectable on the upstream side of a recursive if the adversary has > tempora-like access. > > Cheers, > S. > > > On 23/02/15 22:36, Warren Kumari wrote: >> Dear DPRIVE WG, >> >> The authors of draft-ietf-dprive-problem-statement have indicated that >> they believe that the document is ready, and have asked for Working >> Group Last Call. >> >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-ietf-dprive-problem-statement/ >> >> This document was discussed at the DPRIVE meeting at IETF91 - some >> notes here: >> http://tools.ietf.org/wg/dprive/minutes?item=minutes-91-dprive.html >> >> The document has also been worked on in GitHub, here: >> https://github.com/bortzmeyer/my-IETF-work >> It has also received a fair bit of on-list discussion. >> >> Please review this draft to see if you think it is ready for >> publication and send comments to the list, clearly stating your view. >> Even if you previously expressed support for the document (e.g during >> adoption), please respond to the WGLC showing that you still support >> it. >> >> This WGLC ends Mon 09-Mar-2015. >> >> >> In addition, to satisfy RFC 6702 ("Promoting Compliance with >> Intellectual Property Rights (IPR)"): >> Are you personally aware of any IPR that applies to >> draft-ietf-dprive-problem-statement? If so, has this IPR been >> disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, >> 3669, and 5378 for more details.) >> >> Thanks, >> Warren Kumari >> (as DPRIVE WG co-chair) >> >> > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
