[ih] Interesting correlation between RPZ and SOPA...

[Richard Bennett]

I'm not sure that IH is interested in this, but in case they are, I'm 
forwarding.

I think the discussion is off in the weeds at this point so I'm stopping.

RB

On 12/19/2011 9:43 PM, Paul Vixie wrote:
> On 12/20/2011 3:51 AM, Richard Bennett wrote:
>> See comments in-line.
> ok. i'm not sure why you're responding privately; these issues deserve
> sunlight and oxygen. feel free to share, including publication.
>
>> On 12/19/2011 6:39 PM, Paul Vixie wrote:
>>>> Date: Mon, 19 Dec 2011 12:35:28 -0800
>>>> From: Richard Bennett<richard at bennett.com>
>>>> To: internet-history at postel.org
>>>>
> ...
>
>>>> The implications of adopting a law that requires U. S. ISPs to alter
>>>> their response to certain DNS lookups depends to a great extent on the
>>>> expected user response to a lookup failure, which is a very interesting
>>>> discussion but not really technical.
>>> that's... utterly... fantastical.
>>>
>>> the response of the operating systems, libraries, and applications that
>>> users on the internet will be running at the time that a mandated dns
>>> response (or mandated nonresponse) occurs is both interesting AND
>>> technical. and it's central to understanding whether the adoption of
>>> SOPA or PIPA in its proposed form would preempt DNSSEC in the
>>> marketplace. therefore it's the place we'd have to start any serious
>>> inquiry.
>>>
>>> assuming for the purpose of this message that you were not serious,
>>> let's proceed.
>> There are facts to be had that help answer this question, most
>> significantly a Berkman Center study of user responses to DNS
>> filtering in the many nations that require it. Their survey finds that
>> 97% or so of affected parties don't engage in any circumvention
>> measures. [berk2010]
> that study does not answer this question. the question is, what happens
> when lookups fail? very little about circumvention tools is relevant in
> that discussion. circumvention happens in response to many other inputs.
> most of the time lookups succeed but tcp/ip to port 80 fails. the reason
> this question is technical (i'm disputing you here) is that much of the
> user's reaction depends on the application's, library's, and operating
> systems' reactions. and many of the things in the berkman report are
> related to circumvention of non-dns federal blocking systems.
>
>> If you think this is "utterly fantastical" I suggest you take it up
>> with the Berkman people.
> no, sir, i'm taking it up with you, because you claimed it was not a
> technical issue. it is a technical issue, and the technical issues will
> influence the non-technical ones, so, i claim that we have to study the
> technical issues first.
>
>>>> The bill is based on
>>>> the RPZ feature in BIND9 that allows a DNS administrator to attach
>>>> policy to DNS queries. This feature is controversial in some
>>>> quarters in
>>>> its own right, but there's not much of an issue with its current
>>>> implementation and DNSSEC. When BIND9 finds a user looking up a signed
>>>> domain, it simply bypasses the RPZ logic and gives a straight answer.
>>> ...
>>> first, if you're right that this bill really is based on RPZ, then i am
>>> extremely impressed. RPZ came out in summer 2010 and for it to reach the
>>> level of attention where authors of federal legislation in any country,
>>> especially in the U.S., would be impacted by it, astounds me. i thought
>>> it was a coincidence, as in, folks wanted to do this for a long time,
>>> but they couldn't see mandating it if the only dns filtering in
>>> existence was a commercial product (hello nominum!), and when RPZ came
>>> out, it was sort of like a door opened, allowing in what had been
>>> previously kept out.
>> The discussion about a bill of this type started in late 2009 when DNS
>> blackholes and Nominum were known phenomena. By the time the bill was
>> drafted, RPZ had validated DNS blacklisting and made it easy for the
>> drafters to include such a method.
> is this first hand knowledge on your part, or are you reading some
> calendar-related tea leaves here? rpz validates aligned-interests dns
> blocking, but does nothing to validate the goals or approach taken by
> PIPA or SOPA. if someone really did act the way you're describing, then
> they were fools or they were misled by their technical consultants.
>
>>> second, in the manager's amendment to SOPA, allowance is made for an ISP
>>> to "not resolve" which broadly means "don't answer at all, just time
>>> out." i think this would be bad engineering, even if it wasn't politics
>>> (and thus not engineering at all). but since RPZ is based on a rulesets
>>> containing a lot of<trigger,action>   tuples i'd like to state for the
>>> record that no "action" triggerable by RPZ includes "just drop the
>>> query, don't answer." so if the SOPA folks were really basing their bill
>>> on RPZ, they've gone outside the box with the manager's amendment.
>> No, there's more than that. The amended bill contains a stipulation
>> that the DNS providers don't have to do anything that would undermine
>> DNS Security. Whether they don't respond, respond with a signed
>> pointer to the AG's web site,  respond with Next Secure Domain, or
>> simply resolve the query is an exercise left to the reader. Congress
>> isn't writing the config files for the DNS providers at this stage.
> and yet "not respond" is not an RPZ feature, so if SOPA really is based
> on RPZ as a "reasonable measure" then SOPA is simply wrong to offer "not
> respond" as an option. and you should be in a position to know that
> "respond with Next Secure Domain" is not an option since the responding
> server will not possess the proper DNSSEC key for signing such a
> message. nor is "respond with a signed pointer to the AG's web site"
> since the responding server will not possess the key necessary for such
> a signature. "simply resolve the query" is outside the box since it does
> not comply with the law, unless you think an ISP could prevail in court
> if they say simply "there was no reasonable technical measure, so i did
> nothing." (i do not believe an ISP could prevail, since they could not
> afford the legal fees necessary to keep up with the MPAA people in terms
> of pretrial briefs and other filings.)
>
> what this means is not that i'm asking congress to write a config file,
> but rather, i am pointing out that there is no such possible config
> file; what congress is demanding here intersects rather badly with the
> null set. they may as well demand faster than light travel, because my
> answer would have the same form: "the laws of physics don't work that way."
>
>>> this is a problem in the design, and we're still trying to figure out
>>> what to do about it. if a bad guy with a bad domain can drive right
>>> through the RPZ just by signing his bad domain, then that'll either make
>>> DNSSEC very successful (since many domains are "throw aways" used only
>>> for e-crime) or it will make RPZ a total failure. on the risk that
>>> DNSSEC market success will not be the result of this missing feature in
>>> RPZ, i feel like some better answer is needed. but one thing i won't be
>>> putting into RPZ is a way to break DNSSEC -- as SOPA would require for
>>> effectiveness. if SOPA and PIPA were to be revised to say that any
>>> criminal who signs their infringing web site's domain name with DNSSEC
>>> shall be exempt from blocking under this law, then we'd really have
>>> something to talk about.
>> third, you're right, no signed answer is affected by RPZ at present.
>> Right, criminal domains and DNSSEC are on a collision course that will
>> need to be headed off in order for DNSSEC to live up to its claims. I
>> expect that can be done in a few different ways.
> this is nonresponsive, sir. congress has not said "if a bad guy signs
> their domain with DNSSEC then there is no need for ISP's to block access
> to that domain", and until they say that, they cannot use RPZ as an
> example of a "reasonable technical means" to comply with the law. this
> again is an intersection with the null set; it's a void concept; it's
> "crazy".
>
>>>> Congress needs to know whether doing so undermines Internet security,
>>>> impedes the deployment of DNSSEC, or threatens the Internet or DNS in
>>>> some way.
>>> The intent of SOPA is to have it follow the RPZ implementation, and
>>> as stated above, if SOPA is counting on RPZ, then the proposed law needs
>>> to say "and if criminals sign their domain names then they will not be
>>> blocked under this law" or it needs to refer explicitly to the RPZ
>>> specification, online at:
>>>
>>> https://deepthought.isc.org/article/AA-00512/0
>>>
>>> furthermore if they intend to be compatible with RPZ's actual
>>> capabilities for unsigned domain names, they will have to state a
>>> requirement that an unsigned NXDOMAIN, an unsigned CNAME, or an unsigned
>>> replacement answer record set be sent in response to queries for domains
>>> blocked under this law.
>> Good idea, but they won't get any closer than a "such as." It's best
>> if Congress doesn't specify the code.
> as before i am not asking congress for source code, merely some set of
> constraints that does not have a null result. if you're right that they
> are basing their demands on the existence of RPZ then they are
> responsible for staying within the capabilities of RPZ. they have not
> done the latter so i claim that they have no claim on the former. please
> be responsive to my specific complaints and claims, as i am doing for yours.
>
>>>> access to particular subdomains or even smaller units. That seems a bit
>>>> problematic from and overhead perspective so I'd rather not go there.
>>>> That seems to be going on in the Goodlatte amendment.
>>> The alternative to DNS-level filtering is to have ISPs use ACLs to block
>>> i don't know any ISP who has core (that is, the high speed stuff)
>>> equipment capable of singling out DNS messages and doing a deep dive on
>>> them and modifying those that contain subdomains of a hundred or so
>>> (estimated by the SOPA proponents) parent domains. any requirement to do
>>> this would run afoul of the "any reasonable technical measures" wording.
>>> (this "technical measure" would never be "reasonable".)
>> I mean ACLs that block access to specific IP addresses, not to the DNS
>> messages. Routers can do that. BGP filtering would be another approach.
> you said "subdomains" which meant, to me, that you expected these ACL's
> to be DNS-aware. which is it?
>
> moreover, if congress intends to allow ISP's to block by IP address
> rather than by domain name, then how often must the ISP update their IP
> filters to account for changes in the domain name ->  ip address
> mappings? if a criminal changes their IP address a thousand times per
> day (as some criminals already do, so this would not be an innovation)
> then would ISP's be remiss in their compliance with the law if they only
> update their IP address ACL's once per day? be careful how you answer
> because you're either placing an infinite burden on a non-conspirator or
> you're allowing for the possibility that this whole package of law
> achieves no effective result and ends up either being "just for show" or
> being an historical joke.
>
> paul
>

-- 
Richard Bennett