[cooperation-wg] DNS-based filtering

Il 30/01/2014 17:04, Peter Koch ha scritto:
> On Tue, Jan 28, 2014 at 05:42:17PM -0500, Meredith Whittaker wrote:
>
>> I would suggest removing the target audience -- here started as law
>> enforcement and governments -- and dedicating this work more broadly to
>> anyone who's interested in this topic and would like a basic understanding
>
> so, this paragraph in the draft was one that I like very much because it
> is forgotten too often and helps focus the document. It also frames
> expectations on the side of the raeder.

Accepting Meredith's remark, but also keeping focus on my original
aim, I changed the paragraph of page 4:

	This document is _particularly_ addressed to legislators,
	agencies, stakeholders, courts and to whoever may be involved
	in Internet governance and engaged in law enforcements on the
	network, and also to who is interested in this topic and would
	like a basic understanding of mechanisms and approaches used by
	whoever to block or prevent access to contents.

In my opinion this paper should stay focused on RIPE coop-wg target
audience, which is especially governments and regulators.

> seconded.  Also, the actors (LEA in this case) could better be left away.
> It's not important for the method who's asking/ordering/threatening/volunteering.

I changed paragraphs on page 8 too and also any occurrence of "illicit"
/ "LEAs" with "unwanted/undesired/forbidden" and a generic "requestors"
or "requesting governments".

	Web blocking and filtering are measures usually requested by 	
	governments [...] addressed to prevent access to illicit
	contents such as pedo-pornography [...] or even to constrain
	access to opposing political or religious contents or to quiet
	debates that threaten the parties in power.

	These measures are particularly used when the _undesired_
	content is hosted on servers that are out of the jurisdiction
	of the _requesting party_, so when it’s not possible or very
	difficult to order the website operator to remove the
	_unwanted_ material from its servers. In such cases ISPs
	operating under the jurisdiction of the requestor are imposed
	to prevent their customers to access the identified resources.

	Optionally, they may be asked to redirect customers who try to
	access the _forbidden_ content to a web page reporting
	additional information, such as the legal notice about the
	blocking measure (“stop-page”).

>
> The draft could benefit from a terminology pass sooner than later.

Yes, I'm the first to admit it, it needs a review on both technical
terminology and grammar (as you can see my English is not very good);
now the document is hosted on Google Drive, if someone wants to take
care about that I can give him/her write permissions.

> We've
> already has some debate about "authoritative servers", where that was
> meant to be registrations at the second (or third, for that matter) level.

I missed that debate so, for clarity, this is what I meant in the
document (please refer to diagram on page 8):

- root servers: servers that hold TLD-registries mappings;

- registries: servers that hold TLD-domain mappings;

- authoritative servers: servers that hold the domain zone.

I know that "authoritative" is something else, every server is
authoritative for zones it directly serves, but I preferred to use a not
strictly proper terminology for the sake of reading easiness.

Any suggestions/corrections would be appreciated.

> I'd also suggest to skip the part about domain name "takedowns".  It has
> similar side effects but is really different from filtering.

Because domain name takedowns are actually used to prevent users from
accessing contents I think it's correct to include them in this document
and to show their pros and cons there. Am I the only one to think that?

> Speaking of side effects, the language chosen in that section sounds tentative
> and defensive to me ("may", "could be").  While applicable in an academic debate,
> the other party is absolutely undoubtful about their doing the Right Thing.

Sorry, my fault; here a native English speaker can render the idea
better than me.

> While at it, I'd not support the myth that DNSSEC and suppressing DNS responses
> are incompatible.  While the changes applied are either detected and suppressed by the
> validating resolver or injected at that very place (again, the ISP),
> the result usually is either you receive the government enhanced response
> with the seal of the validator or you get an error response, in which case
> the end user still can't access the site.

DNSSEC and response suppression are not incompatible, even if DNSSEC is
implemented in the resolver the final result is anyway achieved and the
user is anyway prevented from accessing the website (maybe he/she will
not get the stop-page but of course he/she will not open the website too).

I'm more concerned about the fact that such blocking measures can have
impact on the background philosophy that is behind DNSSEC, impair trust
on it and slow down its deployment rather than about technical issues.
Please refer to this Paul Vixie's post [1]; he explains far better what 
I mean.

Do you think that's only a vague and unfounded fear?

>
> Careful with the risk assessments:
>
>    DNS blocking techniques may be used to defeat cybercrime too, by blocking those
>    domain names which are dedicated to frauds, phishing or malware distribution (viruses,
>    trojans, #). If users decide to change their device configuration and use public
>    open resolvers to access (over-) blocked content any local anti-cybercrime activity is vanished.
>
> Sounds either like an encouragement to restrict/regulate access to alternative
> resolution mechanisms or like a "then don't do that".

I think it's a side effect of measures that don't solve the problem but
just hide it. Maybe the paragraph can be arranged in another way if you
think it leads to wrong impressions.

>
> Finally, again on wording, apologies,

These topics are complex and we need to find the better way to explain them.

> we should not call the mechanisms "content
> filtering" because all they do is fiddling with levels of indirection that
> mediate access to the content rather than the content itself.

Correct, in the overblocking paragraph a distinction is already made
between domain seizure and content filtering, anyway I changed some
occurrences of "content filtering" in the rest of the document.

> To that extent, referring to the DNS as the "phone book" has helped quite a couple
> of times. People understand that de-listing does not make the number inaccessible. YMMV.

It's a very good example, easy to understand, I'll see how to merge it
in the document: any suggestions?

>
> PS: my contribution to the bikeshed part of the debate: for diversity, but especially in a
>     European context, we could use somthing other than the COM gTLD in the examples.
>     That's even more important for those parts that I suggested to skip, since it will
>     emphasize that ICANN is not in the game in many cases.

Roland Perry speculated about the chance for a dedicated domain set up
by RIPE for our purposes... this would be the perfect solution.

Thanks for your feedback Peter, they have given the chance to take stock
of the situation!

[1] "Defense in Depth for DNSSEC Applications" -
http://www.circleid.com/posts/defense_in_depth_for_dnssec_applications/

-- 
Pier Carlo Chiodi
http://pierky.com/aboutme

The opinions expressed here represent my own and not those of any
organization, entity or committee to which I may hold a position.