Re: Comcast files "recommended practices" draft RFC with IETF for DNS Redirection

[David Farber <dave () farber net>]

Begin forwarded message:

From: Karl Auerbach <karl () cavebear com>
Date: July 9, 2009 10:08:15 PM EDT
To: dave () farber net, "David P. Reed" <dpreed () reed com>
Subject: Re: [IP] Comcast files "recommended practices" draft RFC with  
IETF for DNS Redirection

On 07/09/2009 05:35 PM, David Farber wrote:

> *From: *"David P. Reed" <dpreed () reed com <mailto:dpreed () reed com>>
> *Date: *July 9, 2009 5:06:02 PM EDT

> *Subject: **Comcast files "recommended practices" draft RFC with IETF
> for DNS Redirection*
>
> http://tools.ietf.org/html/draft-livingood-dns-redirect-00
>
> I note that this draft RFC proposes practices that routinely return
> *valid* responses to erroneous DNS lookups, and encourage an opt-out
> policy rather than an opt-in policy.

While I generally agree with your concern and alarm, I do think that  
this is a deeper issue than Verisign's "Sitefinder".

Let me begin that a lot of internet users are tired of garbage on the  
web and that their desire to prune theor perception of the internet  
landscape into one that pleases their senses and protects their  
families is a desire that is legitimate and deeply rooted.  I can  
imagine that Comcast may find this service popular, particularly among  
more conservative or religious communities.

And it may well be that ICANN has no lever to tell Comcast to do  
otherwise.  ICANN operates by a pyramid of contracts and when one is  
outside the contractual tent contractual limitations don't apply.

(By-the-way, in ICANN's various contracts with registries and  
registrars and others ICANN actively denies what are called "third  
party beneficiary" right to the public.  This has the effect of  
eliminating the ability of a member of the public going to court and  
requiring that a registrar or registry, or even ICANN itself, live up  
to the terms of the contract.  ICANN is established as a "public  
benefit" corporation and it receives a US tax exemption on the grounds  
that it serves the public, so it does seem odd, even wrong, for ICANN  
to block the public from enforcing those things that ICANN does not.   
Witness the disaster at Firefly when ICANN sat idly by twidding its  
thumbs while that registrar violated its ICANN registrar agreement.)

Nor is what Comcast is proposing unlawful.

But back to the thing at hand.

I very much agree that this thing that Comcast proposal would be an  
utter disaster, particularly in that it would affect protocols that  
are not supporting a human user typing into a web browser and reading  
the responses on the screen.

But then again, who has standing to complain in a meaningful way?  Not  
ICANN.  Not law enforcement.  The FTC or the FCC?  I doubt it.

Customers could walk away from Comcast and seek another provider, but  
that could mean abandoning pre-payed contracts and equipment.  And  
besides if, as it may well prove, that this is a popular service, the  
other half of our national duopoly might pick it up as well.

But the point that I wanted to make is this:  You say "return
*valid* responses to erroneous DNS lookups".  I dispute that, but only  
slightly.

There's nothing necessarily wrong with wildcarding in the abstract -  
wildcards *are* part of the DNS internet standard.  What is wrong is  
that not only internet users, but also internet based software, might  
be surprised, confused, or misled.

So rather than denying wildcards in totality as ICANN has resolved to  
do (at least at the TLD layer) it would be more productive to try to  
comprehend those limited circumstances when wildcarding would be  
appropriate, useful, and not harmful.

Right now at this instant I'm having a hard time thinking up a  
situation in which those conditions might be met.  But I don't want my  
lack of imagination to server as a barrier to those who are smarter  
and more inventive than I am - as long as they make their case why  
they are meeting those conditions.

There is a large, more encompassing issue which is this:  The internet  
lacks an architectural layer in which the parties to a communication  
have means to identify one another and perform mutual authentication  
of those identities.  People believe that HTTPS is "secure" but is  
really only one way and even when supported by code in a web browser  
that checks the validity of the other party's certificate that check  
is usually only that the other party has bought a certificate from a  
vendor who has paid an adequate monetary tithe to the browser vendor.)

DNS is really only a hinting system.  The "word" authoritative in  
conjunction is mis-applied by people to mean that the result is  
authoritative as to identity when all it really means is that the DNS  
server that gave the answer is giving first-hand answers rather than  
reflecting DNS hearsay.)

DNS ought to lead us to a target, but whether it is the right target  
for what we are doing or not is a question that needs to be resolved  
by other means.  But for us to connect to a target and presume that we  
are actually in contact with the desired party (and vice versa) is  
silly. That would be like pounding a phone number into a phone (a la  
Steven Colbert), waiting for an answer, and without any preamble  
launch into some horrific disclosure of our most private thoughts.  At  
the human-to-human voice protocol level we usually engage in some  
preliminary identification - we recognize a voice or a tone or  
announce ourselves or something.  On the internet we don't have a well  
established and consistent way to do that.

Yes we have SSH and SSL (one way) and IPSEC and PKI and all the rest  
of the bag of acronyms.  But it is not yet a consistent deployed part  
of our infrastructure.  And there are considerable privacy and civil  
liberties aspects (such as the need for a Big Brother master of  
identities) that we would need to face.

All of this is to say is that the Comcast thing is the tip of a very  
large problem.

                --karl--




-------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com