Re: [DNSOP] Public Suffix List

Eric Brunner-Williams <> Mon, 09 June 2008 18:54 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 1226A3A6BBE; Mon, 9 Jun 2008 11:54:25 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F3963A6B87 for <>; Mon, 9 Jun 2008 11:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UE-DVWzI8+0I for <>; Mon, 9 Jun 2008 11:54:22 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 3F7C73A6A70 for <>; Mon, 9 Jun 2008 11:54:22 -0700 (PDT)
Received: from clam-local.local ( []) by (8.14.2/8.14.2) with ESMTP id m59Dp7FO090426; Mon, 9 Jun 2008 09:51:14 -0400 (EDT) (envelope-from
Message-ID: <>
Date: Mon, 09 Jun 2008 11:54:14 -0700
From: Eric Brunner-Williams <>
User-Agent: Thunderbird (Macintosh/20080421)
MIME-Version: 1.0
To: Edward Lewis <>
References: <> <> <> <a06240803c472e87e44f2@[]>
In-Reply-To: <a06240803c472e87e44f2@[]>
Cc: Gervase Markham <>,,
Subject: Re: [DNSOP] Public Suffix List
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit


I'm going to piggy-back this on something Edward Lewis wrote:

> ...
> I doubt that you'll find any repository that can 
> be used to register "registry-like" zones.  The 
> DNS lacks anything like a RADB, RPSL, etc., 
> mechanism employed by the routing infrastructure. 
> Partly because, unlike IP addresses, there is no 
> organizational link through all parts of the 
> Domain administrations.  ICANN does not have it's 
> "thumbs" on all the TLDs - many ccTLDs do not 
> operate under any agreement with ICANN.
> I admire and respect the effort of web browser 
> implementers to try to improve their code to make 
> it harder to abuse.  Even if the desired tactic 
> is on target, it may still fail because the 
> information is just not available.  Worse is 
> broken security which will just frustrate the 
> users and make the situation even more fertile 
> for abuse (through uncertainty and confusion).
> The domain name industry is more complex than one 
> would think.  It's not technical, it's a market 
> place with operators, wholesalers, resellers, 
> etc.  I think the answers to building a domain's 
> reputation lie more in what happens at an ICANN 
> meeting than an IETF meeting.
The model we had was that with a dsig in the payload, along with a DCP, 
the US FTC could pursue bad actors in the US, and these would be forced 
"off-shore". Iterate until bad actors are restricted to well-known 
jurisdictions and policy set-cookie operations accordingly.

Now I was profoundly dumb in several dimensions -- I didn't anticipate 
that the FTC would be indifferent to consumer fraud, I didn't anticipate 
that "off-shore" (meaning outside of Reston and its environs) would grow 
so dramatically, I didn't anticipate that the "new entity" would become 
part of the problem, creating a privacy hostile and consumer fraud 
indifferent regime in one part of the namespace, and failing to provide 
a mechanism for policy coordination across the entire namespace, and I 
didn't anticipate that we'd be wiped out in 2000, or that privacy would 
be wiped out as a policy area in 2001.

That said, it is my experience that leads me to differ with Ed. The IE 
5.5 beta blocked all 3rd-party cookies, and Mozilla's market share then 
was much smaller than it is today, yet our prototype of the policy parse 
policy model (in your code) was sufficient to cause that vendor to 
change their policy for IE 5.5, and hence for the entire market.

I'm not unconcerned by the problems of state consistency (list update), 
or bit-delivery with that state embedded in each bit-set, or the 
specifics of discovery across 300+ mostly indifferent actors, or the 
(imho) larger problem of associating policy to namespace delegation or 
heuristics, but in my experience, the sink for all the set-cookie 
requests can independently, and usefully, determine the value of cookies 
and namespaces. We didn't use the IETF last time, other than to float 
drafts, in part because the HTTP-WG was closed, and ICANN didn't exist. 
Yet we got cookies into the only available model at the time, pretty 
much to solve the same problem you're trying to solve, modulo all the 
dumbness I mentioned above.

DNSOP mailing list