djbdns
[Top] [All Lists]

Re: blocking IP ranges from querying tinydns

To: Jeff King <peff@peff.net>
Subject: Re: blocking IP ranges from querying tinydns
From: Dean Anderson <dean@av8.com>
Date: Thu, 17 May 2007 16:15:33 -0400 (EDT)
Cc: dns@list.cr.yp.to
Delivered-to: sp-com-lists@consult.net
Delivered-to: gmail-djbdns@securepoint.com
Delivered-to: sp.com.list@gmail.com
Delivered-to: mailing list dns@list.cr.yp.to
In-reply-to: <20070517070133.GA13569@coredump.intra.peff.net>
Mailing-list: contact dns-help@list.cr.yp.to; run by ezmlm
On Thu, 17 May 2007, Jeff King wrote:

>   While some participants in the meeting were interested in protecting
>   against disclosure of DNS data to unauthorized parties, the design
>   team made an explicit decision that "DNS data is `public'", and ruled
>   all threats of data disclosure explicitly out of scope for DNSSEC.
> 
> So they:
>   1. Are a working group producing an informational RFC, and don't
>      necessarily represent the view of the IETF as a whole
>   2. admit that people are interested in protecting against disclosure
>   3. make the assumption only that such protections are outside of the
>      scope of DNSSEC, but don't pass any judgement on the concept as a
>      whole

You make good points. But I think the RFC reflects the views of the
people who designed DNS, and in particular those who designed DNSSEC.  
Nothing in the DNS standards assists with protecting DNS records from
disclosure.  Nothing prevents one from taking countermeasures against
real abuse, either, but this isn't about real abuse. This is about an
admin in a position of responsibility, taking actions against someone he
just doesn't like and using his customers' trust as a weapon to advance
his personal goals or paranoia.

No one has offered any evidence that Cyveillance has done anything
wrong, nor has anyone offered any evidence that Cyveillance has obtained
any non-public information.  There seems no justification for blocking
Cyveillance, and even less justification for blocking access from
Cyveillance to thousands of customer sites without the customers'
permission or even notice to customers that this disruptive act is
planned.

I think most people would be upset to find out that access to their
public data was being manipulated and used in some unjustified, paranoid
or political protest without their knowledge and permission. It is sad
to think that such unethical activity might be legal in some countries.  
But, I suppose it takes events like this to cause people to think about
passing such laws.

> So surely this fine and this case are about the blocking of packets,
> right?
> </sarcasm>

Yes. Indeed, to perform an unlawful block, the packet must be acquired;  
then the source IP Address must be decoded and acquired, and then the IP
Address must be compared to a group boycott list. Upon membership in the
boycott list, the entire packet is either discarded or forwarded.  This
acquisition is not 'necessary incident to the rendition of service.'

The Wiretap act service provider exlusion doesn't apply since the
acquisition of the packet and source IP address for the purpose of
participation in a group boycott is not a necessary incident to the
rendition of services.

People have previously asserted that the Wiretap Act and the ECPA don't
apply to ISPs.  Councilman (well, Steve Jackson Games long ago) proves
otherwise.  Councilman(2005) also shows that (as I cited at various
times), the House and Senate Reports clarify and explain the statutory
language.  [This is no surprise, my lawyers told me this years ago, but
people never seemed to believe that] I couldn't have written
Councilman(2005) as well, if I could have done the drafting.

> You attempt to equate such behavior with blocking under 18 USC 2511 by
> claiming that both behaviors fall under the term ``intercept'' and cite
> your interpretation of Webster's dictionary:
> 
>   http://www.cctec.com/maillists/nanog/historical/9801/msg00242.html
> 
> However, as Howard Goldstein pointed out at the time, 18 USC 2510
> specifically provides the definition of ``intercept'' in this context:
> 
>   (4) â??interceptâ?? means the aural or other acquisition of the contents
>   of any wire, electronic, or oral communication through the use of any
>   electronic, mechanical, or other device.

Yep. I incorrectly cited the dictionary definition in 1998. I was wrong
in that definition, as Goldstein quickly pointed out---the statute
defines the term 'intercept'.  However, Goldstein just pointed out my
mistake in using a dictionary definition, but didn't read himself the
statutory definition. The statutory definition still supported my
original argument. I think perhaps you are reading too much into
Goldstein's criticism.

The Court, in U.S. v. Councilman(2005), also supports my view.  As
Councilman(2005) noted, the ECPA modified the definitions so that the
Wiretap Act applies to the entire transmission of an email message.
Communications don't go in and out of Wiretap Act or ECPA coverage.  
The text of Councilman(2005) has the correct definitions.

The amicus brief by Senator Leahy is also quite helpful, and supports my
view, and seems to have weighed on the Court.

> IOW, it refers only to the _acquisition_ of said communications.

That's correct. One has to acquire the packet to get the source IP
address.  But acquisition must be necessary to rendition of service.  
Participation in the group boycott isn't necessary, and it isn't
authorized.

Lawful activities have to be necessary to the rendition of service.

I agree that public information like DNS has less protection than
Email---The Reports state explicitly that for example the law applies
differently so that private emails are protected while access to public
(e.g. BBS) information would be authorized by the BBS to the public.

> I am instead making an argument that the evidence you presented in the
> mail does not support the conclusion that such behavior is illegal.

That may be.  I'll try to improve the web pages to present sufficient
evidence.

                --Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   



<Prev in Thread] Current Thread [Next in Thread>