On Nov 13, 2013, at 6:30 AM, Jim Reid <j...@rfc1035.com> wrote: > On 13 Nov 2013, at 10:43, Stephane Bortzmeyer <bortzme...@nic.fr> wrote: > >> Contracts do not solve everything: let's assume the manager of the >> ccTLD .cp outsources one name server to a company in the USA. The >> contract clearly states that the contractor MUST NOT send collected >> DNS traffic data to anyone but the registry. Now, a FBI agent comes to >> the contractor and, invoking the Patriot Act, request the data (with, >> of course, a gag order preventing the contractor to warn its >> client). What would the contractor do? > > Decline contracts from customers who have those requirements since they can't > meet them. Though those customers will/should be taking their business to > companies outside USA^W^Win other jurisdictions anyway. And surely the > customer will be obliged to enter contracts that comply with their national > law anyway? We have this in Europe already wrt Data Protection: personal data > can't be exported to a jurisdiction that does not have an equivalent or > better Data Protection regime.
I'm nervous of any assumption that any jurisdiction won't compromise its Data Protection regime under some conditions. I'd simply assume such contracts can't be reliably kept inside the US or outside, unless I'm sure that the data doesn't exist to be turned over. IOW-- I know as a USan I can be expected to say this, but other agencies besides the USG spy, and yes, even in places with stronger Data Protection if only because other jurisdictions tend to have "national security" carve-outs in them too. I thought one of the features of the "revised threat model" is that not only is metadata more interesting than we knew, it's more available than we knew to a determined adversary, state-sponsored or not. We'd do well to generalize further than to assume US-based government-sponsored threats. > BTW, you seem to be making an assumption that the DNS query data for some > domain is "owned" by the domain name holder. I'm not sure that's the case. > However we should leave that layer-9+ discussion to the lawyers and keep it > well away from the IETF. +1 >> >> The real problem is "reasonable user expectation". Imagine a secondary >> name server of .cp hosted in China. Most users of the TLD .cp would be >> quite surprised to know that their data is potentially captured there. > > I'm struggling to see why anyone could have that sort of expectation these > days. The vast majority won't even be aware DNS is involved in their use of > the interwebs at all. [Or what google, facebook, $CloudProvider, et al is > harvesting from their activity.] They send a lookup into the public Internet, > have no way of knowing which DNS server answers (or where it is located), or > who might be listening in to that traffic. Given the recent Snowden > revelations, anyone who is vaguely awake must realise they have next to no > expectation of privacy or anonymity whenever they use the Internet or PSTN as > supplied by their ISP or telco. > I'm wary of bringing "user expectation" in here either way, especially as more and more people interact with the interwebs in ways that don't visibly include the DNS at all. I think Jim's right that it's all very vast and mysterious, so the data-gathering that goes on shouldn't surprise even a naive user, but it also feels to many people like such an extension of themselves and their homes that they're shocked by the notion that anything they're doing online could be happening "in" a foreign country or under hostile eyes. I've already sent some comments privately to Stephane on his draft. I really think this is a useful discussion, and that analyzing DNS in this way is (frustratingly?) typical of the work we have to do on existing protocols if we're serious about responding to the revised threat model for internet privacy. There's a lot more discussion on perp...@ietf.org, which is archived in the usual way at ietf.org for those who might not want to sign up for the full list experience. best, Suzanne _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
