Re: [DNSOP] Public Suffix List

[Paul Hoffman]

At 3:02 PM -0700 6/9/08, Doug Barton wrote:
>I'm also not sure you quite understand the magnitude of the task you're
>undertaking. It's a matter of fact that any sentence including the
>phrase "all TLDs" is doomed from the start. :)  You're dealing with a
>wide variety of business models (often with competing interests),
>policies, levels of technical ability, levels of operating capacity, and
>dare I say it, personalities. You will never get full cooperation, and
>as you can see by Stephane's response you will definitely irritate at
>least some of the TLD operators with this change. You might want to
>rethink socializing this concept before you launch.

Directly related to this is Mozilla's TLD-based IDN settings that Kim 
Davies mentioned at 
. 
If you go to the Mozilla page listed in that message, you will notice 
that a few TLDs that allow IDNs have not registered with Mozilla for 
various reasons (*cough* *cough* .com, .ru, 
.many-countries-in-the-arab-speaking-world, ...). This is reasonably 
good and local proof that Mozilla asking TLDs for information for 
this new registry is likely to result in incomplete information for 
many important TLDs.

--Paul Hoffman, Director
--VPN Consortium
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Doug Barton]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

Yngve and Gerv,

As you have no doubt concluded by now, you've touched a nerve. :) It
doesn't seem to me that you have, but I hope that you will not interpret
the strong reaction you've received as an attack. It's simply the case
that what you're planning to do sounds (and in some ways is) painfully
similar to other ideas that haven't worked out so well in the past, and
you're dealing with a lot of people here who do not want to see history
repeat itself.

Coming as it does late in your development cycle (and especially given
the "enthusiastic" reaction you've received here today) the temptation
would be for you to dig your heels in and insist on moving forward as
planned. I urge you to resist that temptation.

I apologize if this sounds like self-aggrandizement, but I think I'm
pretty well qualified to comment on your plan:

1. I dealt with almost all of the TLDs in my role as dns administrator
for Yahoo!, and maintained a similar list of valid registration points
there for several years.

2. My first job at Yahoo! was programming CGI apps, including domain
name registration and authentication modules, both of which used cookies.

3. I used to manage the IANA, so I have a lot of experience working with
the TLD operator community on various topics, including policy matters
and updates to their records.

All that said, I think that there is some merit in what you're trying to
do. Such a list has utility (to the extent that it is kept up to date)
and it would be nice to have that information collected in one location.
In an ideal world that location would be ICANN (specifically IANA) but
for a variety of reasons, some of which David already mentioned, that
probably isn't possible at this time. I would like to refer you to one
similar (although limited) resource that IS managed by IANA, the list of
valid TLDs that we set up while I was there. It may help you at least
update your current list, and help keep it up to date:
http://data.iana.org/TLD/tlds-alpha-by-domain.txt

When I was maintaining the list of valid registration points (IIUC what
you're referring to as "public suffixes") I was dealing with a limited
number of TLDs, and received updates to the list roughly every week and
a half or so. A lot of these updates were additions, which IIUC your
software will handle as a "soft fail" if they are not present in the
list already. More troublesome for the topic at hand is that roughly
twice a month I received an update about a registry that had changed its
policy, usually making it more permissive (i.e., adding additional
registration points). Indeed, that has been the trend amongst virtually
all of the TLDs since I started caring about this topic in 1998.

There is also another issue which I haven't seen addressed, although
admittedly it's a corner case, of TLD NICs that establish a firm policy
preventing user registration at the top level, but allow themselves to
operate sites such as www.nic.tld.

I'm also not sure you quite understand the magnitude of the task you're
undertaking. It's a matter of fact that any sentence including the
phrase "all TLDs" is doomed from the start. :)  You're dealing with a
wide variety of business models (often with competing interests),
policies, levels of technical ability, levels of operating capacity, and
dare I say it, personalities. You will never get full cooperation, and
as you can see by Stephane's response you will definitely irritate at
least some of the TLD operators with this change. You might want to
rethink socializing this concept before you launch.

There is also the issue raised here by others already that new TLD
introduction (and the corresponding churn on registration policies that
will come as each new TLD matures) will soon become much, much more
common. This will (IMO) be especially true of the new IDN TLDs. If this
cookie security issue in particular is valuable, you do your users a
disservice by treating new TLDs differently from old ones. One of the
key features of the DNS is that it is supposed to work the same for
everyone. What you're proposing places artificial, and immutable
categorization into the name space that it is not only not designed, but
I would say not intended to have.

Now all THAT said, let's look at what you're planning to do. Leaving
aside the "nice to have" stuff like history grouping, I'm very
interested in your concerns about cookie policy. Is the threat you're
trying to guard against (cookie collusion) something real that you've
seen in action, or something that you perceive to be a potential threat?
Please forgive my ignorance on this topic, it's been a while since I've
had to deal with cookie issues.

Others have already said that the proper place to deal with this is in
the cookie spec, so I won't belabor that. Assuming that you are going to
go forward with some form of this no matter what, I would urge you in
the strongest possible terms to reconsider your plan to make it

Re: [DNSOP] Public Suffix List

[Ted Lemon]

I'm a little puzzled by this discussion.   Why not just set up a list  
of TLDs in a mozilla.org subdomain, sign the subdomain with DNSSEC,  
put the DNSSEC public key into firefox, and have firefox consult the  
TLD list in the DNS, verified with DNSSEC, whenever information is  
needed?

That way nobody can say that you have a software update problem.   Yet  
you retain the autonomy you need to get a solution implemented  
quickly.   If the solution proves out well, perhaps people will adopt  
it.   Even if it doesn't, it can't possibly be worse than a list hard- 
coded into the software.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Andrew Sullivan]

On Mon, Jun 09, 2008 at 04:53:42PM +0100, Gervase Markham wrote:

> > What you're really
> > trying to do here is extract meaning from the domain name, but you
> > can't do that reliably.  Previous efforts in that direction have
> > failed in unexpected ways; and given that you seem to have multiple
> > ways you want to use this feature, I don't see any reason to believe
> > you won't have surprising failures too.
> 
> I think your statements of doom need to be more specific.

I think you may be misplacing the burden of proof there.  We have
previous cases where apparently innocent inference of this sort of
metadata about domains turned out to be harmful.  I'm arguing, by way
of analogy, that it is not unreasonable to suppose your approach may
cause harm too.

Your response appears to be that you won't cause that kind of harm.
I'm sure that's true.  But my argument is that, because you are
relying on meanings that simply aren't in the DNS at all, your feature
is automatically fragile.  It will behave in ways that are surprising,
because the behaviour of cookies (and, for that matter, of grouping of
history stuff) will be based on hard-coded bits inaccessible to any
user unwilling to read the source code.  Also, new operators of various
domains that may want to behave differently than your current
expectation will be disadvantaged by what you're doing.  Without
getting every current user in the world to upgrade their client, they
will continue to suffer that disadvantage to some extent.  That seems
like a kind of "harm" to me, but I appreciate that we may have
different meanings of that word.

Best regards,

A

-- 
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Stephane Bortzmeyer]

On Mon, Jun 09, 2008 at 11:07:23PM +0200,
 Phil Regnauld <[EMAIL PROTECTED]> wrote 
 a message of 21 lines which said:

>   about:config in firefox
> 
>   search for IDN
> 
>   disable network.IDN.whitelist for all listed TLDs.

Andrew was asking how to disable the "cookie domain policy", I think. 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Stephane Bortzmeyer]

On Mon, Jun 09, 2008 at 03:21:11PM +0100,
 Gervase Markham <[EMAIL PROTECTED]> wrote 
 a message of 22 lines which said:

> I am not particularly interested in a long discussion about whether
> we need this data. Please be assured that we need it.

That's a very good summary of Mozilla's method. "Trust us and do not
ask questions"
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Phil Regnauld]

Stephane Bortzmeyer (bortzmeyer) writes:
> On Mon, Jun 09, 2008 at 10:29:27AM -0400,
>  Andrew Sullivan <[EMAIL PROTECTED]> wrote 
>  a message of 52 lines which said:
> 
> > Is there any way to turn this off in Firefox 3?
> 
> Switch to a free software browser without this very bad policy?
> 
> http://www.konqueror.org/

Less radical...

about:config in firefox

search for IDN

disable network.IDN.whitelist for all listed TLDs.

Cheers,
Phil

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Joe Abley]

On 9 Jun 2008, at 12:57, Brian Dickson wrote:

> Gervase Markham wrote:
>> We've had this basic problem in the domain of cookies for years. I  
>> don't
>> expect another solution to pop out of the woodwork now. But I'm  
>> open to
>> being surprised :-)
>>
> Surprise!
>
> If you want grouping, there is a simple-to-code, reliable, and
> authoritative way to do so.
>
> Zone cuts (in DNS).

I'm not sure that's a general solution. What about registries that  
permit registration at multiple levels, and publish the results in a  
single zone? (e.g. ca, on.ca, toronto.on.ca). How to distinguish those  
registries from others who don't? (e.g. in, co.in, za, co.za)


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Stephane Bortzmeyer]

On Mon, Jun 09, 2008 at 10:29:27AM -0400,
 Andrew Sullivan <[EMAIL PROTECTED]> wrote 
 a message of 52 lines which said:

> Is there any way to turn this off in Firefox 3?

Switch to a free software browser without this very bad policy?

http://www.konqueror.org/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Stephane Bortzmeyer]

On Mon, Jun 09, 2008 at 11:56:05AM -0700,
 David Conrad <[EMAIL PROTECTED]> wrote 
 a message of 46 lines which said:

> Some might even think it rude (even Microsoftian :-)) not to ask.

Me, for instance. And, AFAIK, Microsoft did not announce such a scheme
for Internet Explorer. This is a sad day when the free software world
tries to have more bad ideas than Microsoft.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Stephane Bortzmeyer]

On Mon, Jun 09, 2008 at 12:57:00PM -0400,
 Brian Dickson <[EMAIL PROTECTED]> wrote 
 a message of 48 lines which said:

> If you want grouping, there is a simple-to-code, reliable, and 
> authoritative way to do so.
> 
> Zone cuts (in DNS).

I find the arm-twisting by Mozilla very questionable but zone cuts are
not a solution. They indicate a technical cut, not an administrative
one. Let's see two real-life counter-examples in ".fr".

Two years ago, "fr" and "com.fr" were on two different sides of a zone
cut but were managed by the same organization, AFNIC, which registers
under "fr" or under some SLD like "com.fr".

As of today, one of the biggest ISP in France, Free Telecom, gives
domain names under free.fr to its customers (but do not delegate - in
the technical sense - them). dupont.free.fr and martin.free.fr are
therefore inside the same zone - but managed by different persons.

That's why the Mozilla idea is bad from the beginning. 


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Paul Hoffman]

At 3:21 PM +0100 6/9/08, Gervase Markham wrote:
>I am not particularly interested in a long discussion about whether we
>need this data. Please be assured that we need it. I am, on the other
>hand, open to suggestions about better ways to obtain it.

One possible method is to start Firefox 3.0 with an empty registry, 
and fetch a registry update from Mozilla each time a user does either 
a manual or automatic "check for updates" on Firefox. Checking for 
updates (as compared to getting updates) happens often enough for 
users who care about updates to minimize the negative effects of TLD 
policy changes for those users. By starting with an empty registry, 
people who never update have the same interface issues they have 
today with Firefox 1 and 2. This proposal does not involve a 
per-domain lookup, thus avoiding a lot of overhead and privacy issues.

"Fixing cookies" is a wonderful idea, and basically impossible in the 
IETF (and probably in the W3C) in any reasonable amount of time due 
to proven repeated lack of consensus. In the meantime, having a 
browser manufacturer "fix cookies" locally may or may not be harmful; 
if it is harmful, hopefully that harm affects the browser maker more 
than the users (or, in this case, domain name holders).

--Paul Hoffman, Director
--VPN Consortium
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Kim Davies]

On 9/06/08 11:56 AM, "David Conrad" <[EMAIL PROTECTED]> wrote:
>
> On Jun 9, 2008, at 9:34 AM, Gervase Markham wrote:
>>> I'm curious: have you consulted with the various TLD-related
>>> organizations (e.g., ccNSO, gNSO, CENTR, APTLD, AfTLD, LACTLD,
>>> etc.) on
>>> how to solve this problem?
>>
>> No. What do you think they'd say that hasn't been said in this thread
>> already?
>
> You're talking about essentially creating a registry of their registry
> policies and distributing it statically via your product.  I would
> imagine they might be interested and might even have some useful input
> to provide.  Some might even think it rude (even Microsoftian :-)) not
> to ask.  But perhaps I've been at layer 9 too long.

This thread sounds remarkably like deja vu. Indeed, the TLD community was
rather upset a few years ago by Mozilla taking unilateral action to
introduce a hard-coded white-list of acceptable IDN TLDs without prior
consultation. It is not unreasonable to think that doing so for a second
time, with the benefit of hindsight, would be received negatively.

I'd also speculate much of the pros and cons to this discussion are equally
applicable to the IDN whitelist. (
http://www.mozilla.org/projects/security/tld-idn-policy-list.html)

kim

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[David Conrad]

Gervase,

On Jun 9, 2008, at 9:34 AM, Gervase Markham wrote:
>> I'm curious: have you consulted with the various TLD-related
>> organizations (e.g., ccNSO, gNSO, CENTR, APTLD, AfTLD, LACTLD,  
>> etc.) on
>> how to solve this problem?
>
> No. What do you think they'd say that hasn't been said in this thread
> already?

You're talking about essentially creating a registry of their registry  
policies and distributing it statically via your product.  I would  
imagine they might be interested and might even have some useful input  
to provide.  Some might even think it rude (even Microsoftian :-)) not  
to ask.  But perhaps I've been at layer 9 too long.

Just to be clear, my understanding of the situation is that you are  
proposing to ask that every TLD who has a zone in which the public can  
register to notify you of that fact so that you can distribute and use  
a list of these registries within your product, relying on Mozilla's  
update/upgrade functionality to update and maintain this list.   
Explicit in this proposal is that the registries notify you every time  
they add a new 'public registry' or change the status of an existing  
'public registry'.  Failure to update a registry could have negative  
impact on customers of the TLD due to, for example, being unable to  
set cookies. Is this an accurate summary?

Regards,
-drc

P.S. If you do send your message to the technical contacts for all the  
TLDs, expect quite a few bounces.  It seems keeping whois data up to  
date is a challenge for many TLD admins.  Having a bit of experience  
dealing with the various TLD administrators, this might be seen as  
cautionary towards what you're proposing to do.

P.P.S. Before anyone asks, IANA policies disallow IANA from initiating  
a change and require all changes to be confirmed by the TLD admins --  
IANA could harass people to update their info, but the TLD AC and TC  
must take action for a change to occur.  This turns out to be quite a  
stumbling block.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Eric Brunner-Williams]

Gervase,

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.

Eric
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] FYI, more comments on IETF "not having members"

[Dean Anderson]

The frivolous, dishonest, and false statements in the January 15, 2008
IESG Appeal Response found at
[http://www.ietf.org/IESG/APPEALS/appeal-response-dean-anderson-01-15-2008.txt]
must be corrected.  Persons are begining to incorrectly claim that the
IETF has no members, and no ability to make official statements. In fact
numerous Official IETF documents refer to IETF members, and the IETF is
part of the Internet Society, Inc, a U.S. non-profit corporation.  The
ISOC is engaging in improper trade practices by misrepresenting its both
its incorporation status and its status as a part of a non-profit
membership corporation.

Dean Anderson
CEO
AV8 Internet, Inc


-- Forwarded message --
Date: Mon, 9 Jun 2008 10:17:36 -0400
From: Edward Lewis <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Gervase Markham <[EMAIL PROTECTED]>, dnsop@ietf.org, [EMAIL PROTECTED]
Subject: Re: [DNSOP] Public Suffix List

At 16:00 +0200 6/9/08, Yngve Nysaeter Pettersen wrote:
>On Mon, 09 Jun 2008 15:32:11 +0200, Patrik Fältström <[EMAIL PROTECTED]>
>wrote:
>
>>  The problem with any such mechanisms is that the barrier of entry for
>>  new players (that does not match the currently used list -- including
>>  non-upgraded software) is increased. More than what people think.
>
>That is why my subtld-structure draft is suggesting that TLD profiles be
>downloaded at regular intervals (and at need) from a repository, in order
>to make it possible to add new TLDs or new registry-like domains under a
>TLD, and to prevent problems with old software. My drafts also suggest a
>rule-of-thumb fallback in case a TLD is unknown.

This thread is going to go around in circles for 
quite a while.  There's a history of the IETF 
wanting to define something without fixed 
boundaries.  DNS names is one, IPv6 addresses is 
another.  But when it comes to operations, having 
fixed boundaries makes mass production much 
easier.

E.g., in IPv6, IETFer's (as we know, the IETF 
doesn't have any official statement source and no 
members, so I refer to those in the debate that 
brandish IETF credentials) would say that the 
days of classful addressing are behind us, so 
IPv6 addresses ought to be treated as nothing but 
a string of 128 bits.  But RIR policy writers 
wanted to know whether to recommend /48's, /54's, 
/32's, etc. for certain types of uses.  ("Uses" 
not users.)

Shifting back to DNS, there's not going to be a 
scientific differentiation between one zone and 
another.  During the DNSSEC development days we 
wanted to declare some zones as "widely 
delegated" (such as .com) from other zones - to 
alleviate the issues we see with NSEC, NSEC3, 
etc. that are apparent still now.  There's 
nothing in DNS to differentiate, at a protocol 
level, one zone from another, but at the 
operational end of the stick, there are many 
differentiators (like whether the administration 
interface is on paper or via EPP).

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.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis+1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Eric Brunner-Williams]

Gervase,

The Dan Jay (and later) cookie policy drafts had a dsig in the payload 
so that the data collection policy (DCP) asserted in a cookie could be 
verified. The xml dsig draft wasn't ready, so we took off that part of 
the payload, leaving only the DCP. At the W3C P3P Spec WG meeting in San 
Jose a _large_ vendor agreed to implement what had been protoyped in 
Mozilla, replacing a no-3rd-party-cookies policy (there's reasonable 
policy claims on both sides of that) with parse-the-policy-user-decide 
policy (again, there's reasonable ...).

It's not unreasonable to revisit how we know an assertion about a DCP is 
true, or provably false, as xml dsig is now mature.

Turning to the list it self, I'm working on proposals (to ICANN) for new 
generic TLDs with string lengths greater than four bytes, and the latest 
estimate (by ICANN staff) is that they anticipate between 300 and 600 
applications in 2009, zero or more of which may be operationalized in 
2010. Additionally, a subset of the existing iso3166 code-point 
associated registries may elect to apply to add non-ASCII (well, 
technically, ACE junk) labels to the root.

My point here is that two of the safe assumptions (byte count < mumble & 
( sizeof(rootzone) & compositionof(rootzone) ) are quasi-static) has a 
two-year or less shelf-life remaining.

It isn't unreasonable to expect registry operators under contract (to 
ICANN) to publish SLD data directly, so you (and others) don't have to 
wikipedia (not that wikipedia isn't generally a better source of data), 
and you'd probably want that in machine readable form, with an update 
mechanism, and it might be useful if that request got incorporated into 
the process I mentioned above before it "goes live".

The PROVREG WG added a DCP into EPP, however, the intended scope was 
simply to announce the DCP of registry operators to registrars, who may 
then communicate the registry's DCP, and their own, towards the eventual 
registrant. We didn't provide a mechanism for registrants to announce 
the DCPs that they would be implementing from the resources they 
obtained by registering domains, or a mechanism for registries to 
announce DCPs scoped to a particular namespace.

FYI, the elephant in the room for P3P is we didn't provide a means to 
assert linkage to data collected by other means, so data collectors 
don't have a means to announce if they do, or don't, link cookie data 
with credit-report data obtained by other means.

We did, over the objections of one of the major deterministic personal 
profile vendors, now owned by a _large_ search engine operator, make 
linked data disclosure manditory through the include/exclude statements.

Eric

Gervase Markham wrote:
> Dear HTTP and DNS Operations WGs,
>
> The following email message will shortly be sent to the technical
> contact for all TLDs. Yngve Pettersen at Opera suggested that I also let
> you both know about it.
>
> The technology in question, including a version of the list, is about to
> ship in Firefox 3, but we'd like to verify and improve the quality of
> the underlying data.
>
> Please let me know if you see any way I can improve the email, the
> explanatory website, or the submission process.
>
> Gerv
>
> 
> Dear Technical Contact,
>
> The Mozilla Project (http://www.mozilla.org/), responsible for the
> Firefox web browser, requests your help.
>
> We are maintaining a list of all "Public Suffixes". A Public Suffix is a
> domain label under which internet users can directly register domains.
> Examples of Public Suffixes are ".net", ".org.uk" and ".pvt.k12.ca.us".
> In other words, the list is an encoding of the "structure" of each
> top-level domain, so a TLD may contain many Public Suffixes. This
> information is used by web browsers for several purposes - for example,
> to make sure they have secure cookie-setting policies. For more details,
> see http://publicsuffix.org/learn/.
>
> We would like your help to make sure, now and in the future, that the
> entries for your TLD(s) are correct. It is in your interest as a
> registry to make sure that this is so. Any errors may either cause your
> customers (domain owners in your TLD) to not be able to set cookies when
> they should, or cause cookie information to be leaked between two
> domains without a trust relationship. Neither of these things is desirable.
>
> Therefore, we are writing to ask your technical team to view the current
> list and, if it is incorrect, to submit updated data. A description of
> the format of the list, and details for sending updates is at:
>
> http://publicsuffix.org/submit/
>
> We also ask you to send updated information whenever you change your
> registration policies in a way which affects the list.
>
> Thanking you in advance,
>
> Gervase Markham
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>   

___
DNSOP mailing list

Re: [DNSOP] Public Suffix List

[Peter Koch]

Gervase,

first I'd like to thank Yngve for providing the pointer and you for following
his advice.

> I am not particularly interested in a long discussion about whether we
> need this data. Please be assured that we need it. I am, on the other
> hand, open to suggestions about better ways to obtain it.

Without discussing the perceived need it's hard to tell what good or
better solution might exist.  From what I see and also from what I remember
from earlier discussions on this topic, you are trying to exploit a
property that the DNS simply doesn't have: You are trying to deduce
administrative "grouping" from proximity or hierarchy in the name space.
In spite of sloppy language that lets "a domain" have a policy or lets
"a domain" publish a website and so on, this is not what the DNS is about.

The DNS naming hierarchy does neither follow nor imply administrative
hierarchy.  Therefore, as others already suggested, the discussion of
the need or the way cookies' scopes are defined is more needed than
details of a data collection scheme that appears to be in conflict with
very basic properties of the protocol.

-Peter {no hats}
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Brian Dickson]

Gervase Markham wrote:
> We've had this basic problem in the domain of cookies for years. I don't
> expect another solution to pop out of the woodwork now. But I'm open to
> being surprised :-)
>   

Surprise!

If you want grouping, there is a simple-to-code, reliable, and 
authoritative way to do so.

Zone cuts (in DNS).

(Note well - a zone is not semantically identical to a domain, although 
they can at times seem that way.
In particular, if a child domain is served by the same server(s) as the 
parent, there will not be a zone cut.
This, I believe, will generally do a good job of permitting grouping 
automagically.)

Where there is a delegation of authority, via a zone cut, that is 
*exactly* where you want to group.

And in the absence of a zone cut, you do not want separation by grouping.

That (among other things) is what distinguishes "foo.co.uk" from 
"myprivatesubdomain.foo.com".

Perhaps examining other aspects of DNS responses may further inform the 
device needing to determine grouping.
Things like presence/absence of glue (at particular places, e.g. 
root/TLD), commonality of NS instances between parent/child, etc.

Whether this gets done by the end-user's client, or by some 
more-centralized box, is an implementation issue (but one that should be 
given lots of thought!!).

But, it is better to trust information already published, which is 
required for proper operation of DNS, than to look for additional 
information that may become stale or inconsistent.

Brian Dickson


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

Jamie Lokier wrote:
> Gervase Markham wrote:
>>> Wouldn't it be more appropriate for MyBank to _itself_ say the history
>>> for these sites should be grouped?  E.g. in an HTTP response header,
>>> or DNS record for mybank.co.uk?
>> The total amount of effort required for this solution is mind-boggling.
> 
> How is it more work for them to publish over DNS or HTTP, than to send
> you the information to publish, with the associated time lag etc?

Your solution requires every site to set HTTP response headers, or every
ISP to contact their customers to get the correct values for the DNS
records.

My solution involves communicating with a far smaller group.

> You've asked for the same thing: for administrators of certain domains
> to provide you with information about independent or related users of
> those subdomains.

But the two plans are talking about two different sets of admins, one
vastly larger than the other.

Gerv
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Jamie Lokier]

Gervase Markham wrote:
> > Wouldn't it be more appropriate for MyBank to _itself_ say the history
> > for these sites should be grouped?  E.g. in an HTTP response header,
> > or DNS record for mybank.co.uk?
> 
> The total amount of effort required for this solution is mind-boggling.

How is it more work for them to publish over DNS or HTTP, than to send
you the information to publish, with the associated time lag etc?

You've asked for the same thing: for administrators of certain domains
to provide you with information about independent or related users of
those subdomains.

The only difference that I see, is you're able to include commonly
known information about TLDs like *.com and *.co.uk.  I agree with
that: it's good to collect and publish the info.

For the more obscure ISP-owned domains with independent user
sub-domains, I don't see a difference in work _for them_ between you
putting out a call and collecting the info, and keeping it update as
new ISPs come on line, and the ISPs having a mechanism to publish it
themselves.  Except that the latter will be more accurate, and less
work for you.

-- Jamie

> > Also, wouldn't DNS generally be the appropriate mechanism to say what
> > grouping relationships there are under $DOMAIN?  After all, the
> > administrative control for the grouping info which you are maintaining
> > for *.$DOMAIN, and DNS for *.$DOMAIN, are the same.
> 
> It would be an appropriate mechanism; when it does contain this
> information, let me know.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Jamie Lokier]

Gervase Markham wrote:
> This isn't just about cookies. For example, we would like to group
> together related sites (www.mybank.co.uk, accounts.mybank.co.uk) in
> history. Grouping together all sites in ".co.uk" does not provide for an
> optimum user experience.

Wouldn't it be more appropriate for MyBank to _itself_ say the history
for these sites should be grouped?  E.g. in an HTTP response header,
or DNS record for mybank.co.uk?

Also, wouldn't DNS generally be the appropriate mechanism to say what
grouping relationships there are under $DOMAIN?  After all, the
administrative control for the grouping info which you are maintaining
for *.$DOMAIN, and DNS for *.$DOMAIN, are the same.

-- Jamie
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

David Conrad wrote:
> I suspect I might have a better list than you (:-) hint: I work at ICANN).

Well, OK :-)

> My reading of Yngve's draft (in particular, section 5.1) led me to
> believe that all TLDs would not need to run such a service, rather that
> such a service be available in a "well known" place (I think the right
> approach would be for IANA to maintain pointers to well known places,
> but that's an implementation detail).

I'm happy to admit that Yngve's solution, if it ever got up and running,
would be a good one. (Although it's worth noting that such a service
would need to deal with a non-negligible amount of traffic.) But it
doesn't exist.

> I'm curious: have you consulted with the various TLD-related
> organizations (e.g., ccNSO, gNSO, CENTR, APTLD, AfTLD, LACTLD, etc.) on
> how to solve this problem?

No. What do you think they'd say that hasn't been said in this thread
already?

We've had this basic problem in the domain of cookies for years. I don't
expect another solution to pop out of the woodwork now. But I'm open to
being surprised :-)

Gerv
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

Jamie Lokier wrote:
> Wouldn't it be more appropriate for MyBank to _itself_ say the history
> for these sites should be grouped?  E.g. in an HTTP response header,
> or DNS record for mybank.co.uk?

The total amount of effort required for this solution is mind-boggling.

> Also, wouldn't DNS generally be the appropriate mechanism to say what
> grouping relationships there are under $DOMAIN?  After all, the
> administrative control for the grouping info which you are maintaining
> for *.$DOMAIN, and DNS for *.$DOMAIN, are the same.

It would be an appropriate mechanism; when it does contain this
information, let me know.

Gerv
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[David Conrad]

Gervase,

On Jun 9, 2008, at 8:57 AM, Gervase Markham wrote:
> David Conrad wrote:
>>> however, my view is that getting comprehensive buy-in
>>> would take quite a lot more time and effort than this method.
>> is the common excuse that results in lots of broken crap on the
>> Internet.  It is sad to see the same mistake repeated again and  
>> again.
> Prove me wrong, then. You can send a message to the Technical Contacts
> of all 284 domains (I can supply you with a list)

I suspect I might have a better list than you (:-) hint: I work at  
ICANN).

> saying "Please set up
> a resilient, highly-available web service to provide current data on
> your registration structure." See what sort of reaction you get.

My reading of Yngve's draft (in particular, section 5.1) led me to  
believe that all TLDs would not need to run such a service, rather  
that such a service be available in a "well known" place (I think the  
right approach would be for IANA to maintain pointers to well known  
places, but that's an implementation detail).

I'm curious: have you consulted with the various TLD-related  
organizations (e.g., ccNSO, gNSO, CENTR, APTLD, AfTLD, LACTLD, etc.)  
on how to solve this problem?

In any event, while I think the goal you are trying to reach is a good  
one, I suspect the implementation approach you're suggesting will lead  
to regrets.  However, your code and all that...

 How can non-TLD's get into this list!?
>>> Just by asking; I already got an email from CentralNIC.
>> If there is no vetting, doesn't this defeat the purpose?
> Who says there's no vetting?

"Just by asking".

I gather I misunderstood.

Regards,
-drc

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

David Conrad wrote:
>> however, my view is that getting comprehensive buy-in
>> would take quite a lot more time and effort than this method.
> 
> is the common excuse that results in lots of broken crap on the
> Internet.  It is sad to see the same mistake repeated again and again.

Prove me wrong, then. You can send a message to the Technical Contacts
of all 284 domains (I can supply you with a list) saying "Please set up
a resilient, highly-available web service to provide current data on
your registration structure." See what sort of reaction you get.

>>> How can non-TLD's get into this list!?
>> Just by asking; I already got an email from CentralNIC.
> 
> If there is no vetting, doesn't this defeat the purpose?

Who says there's no vetting?

How does adding e.g. CentralNIC defeat the purpose? In some ways, it is
the purpose; CentralNIC customers will no longer be able to conspire to
damage users privacy, and if users accidentally mis-set cookies, other
CentralNIC customers can't steal them.

Gerv
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

Andrew Sullivan wrote:
> Because what you are proposing to do adds special meaning to certain
> labels (and their relative position) and not to others, in exactly the
> way that previously people had special interpretations of certain
> labels and their positions in the set of labels. 

Right. But they did things like throw error messages saying "That's an
invalid domain name because it has too many characters in the extension.
Please enter a valid one." We aren't planning anything like that.

> What you're really
> trying to do here is extract meaning from the domain name, but you
> can't do that reliably.  Previous efforts in that direction have
> failed in unexpected ways; and given that you seem to have multiple
> ways you want to use this feature, I don't see any reason to believe
> you won't have surprising failures too.

I think your statements of doom need to be more specific.

> The plan is both too narrow and too wide.  First, it will almost
> certainly fail to capture 100% of the cases you currently don't want
> to succeed. 

That's true. It's an improvement to privacy and UI, not a magic bullet.

> Second, it will (as we've been arguing in this thread)
> not work for new TLDs and other cases.

It will work perfectly for any new TLD which allows registration
directly below the root.

Of the seven new gTLDs introduced in 2001/2, this is true (as far as I
can see) of .biz, .info, .name and .coop. So those four would have
worked fine if this system had been in place and there had been no
update. .museum and .name have sub-structure, but we haven't found a
definitive list.

If .pro were not present in the list, then people within the
professional subdomains such as bar.pro could conspire to share cookies.
The end-user effect of this is a minor loss of privacy, but none of
function.

> Your counterargument is that
> the behaviour will then fall back to the current arrangement.  This
> means that different domains behave in different ways, and the user
> can't rely on any behaviour consistently.

But if consistent behaviour was the goal, then we _would_ allow
privacy-busting cookies for .co.uk and .com.au, because those domains
are "just the same" as foo.com, and we want "consistency".

Who is "the user" in your statement?

>> This isn't just about cookies. For example, we would like to group
>> together related sites (www.mybank.co.uk, accounts.mybank.co.uk) in
>> history. Grouping together all sites in ".co.uk" does not provide for an
>> optimum user experience.
> 
> It seems to me that what you want is metadata about certain domains.
> Therefore, what you need is a mechanism for publishing metadata, not a
> magical list of domains about which you'll have hard-coded
> information. 

As I have mentioned earlier in the thread, Yngve is proposing a scheme
were every TLD operator publishes this information using a web service,
and clients can look it up (and cache it). I personally think the
chances of that happening are very slim. But if I am proved wrong, we
can happily switch over to using it.

Gerv
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[David Conrad]

Gervase,

On Jun 9, 2008, at 4:48 AM, Gervase Markham wrote:
> Fortunately, Firefox has an extremely good and fast update and uptake
> rate. This is partly because we don't give users a choice about taking
> non-major-version updates.

And how does this update/update rate take into account folks who use  
your product behind firewalls and/or who are constrained by policy to  
not update/upgrade?  Or the folks that disable the version probe?

Broken crap on the Internet has a half-life measured in decades.   
We've learned time after time that static lists of dynamic data  
compiled into globally distributed programs are simply a bad idea and  
that

> however, my view is that getting comprehensive buy-in
> would take quite a lot more time and effort than this method.

is the common excuse that results in lots of broken crap on the  
Internet.  It is sad to see the same mistake repeated again and again.

>> How can non-TLD's get into this list!?
> Just by asking; I already got an email from CentralNIC.

If there is no vetting, doesn't this defeat the purpose?

Regards,
-drc

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Andrew Sullivan]

On Mon, Jun 09, 2008 at 03:43:29PM +0100, Gervase Markham wrote:

> > RFC 3696 explains, I think, most of the reasoning that I would offer
> > for why I think this is a bad idea.  I urge you and others who are
> > planning to ship this kind of feature to go (re)read that RFC.
> 
> Why do you think that the negative consequences explained in that RFC
> would apply in this case? Please think carefully about the consequences
> of possible failure scenarios.

Because what you are proposing to do adds special meaning to certain
labels (and their relative position) and not to others, in exactly the
way that previously people had special interpretations of certain
labels and their positions in the set of labels.  What you're really
trying to do here is extract meaning from the domain name, but you
can't do that reliably.  Previous efforts in that direction have
failed in unexpected ways; and given that you seem to have multiple
ways you want to use this feature, I don't see any reason to believe
you won't have surprising failures too.

The plan is both too narrow and too wide.  First, it will almost
certainly fail to capture 100% of the cases you currently don't want
to succeed.  Second, it will (as we've been arguing in this thread)
not work for new TLDs and other cases.  Your counterargument is that
the behaviour will then fall back to the current arrangement.  This
means that different domains behave in different ways, and the user
can't rely on any behaviour consistently.

> This isn't just about cookies. For example, we would like to group
> together related sites (www.mybank.co.uk, accounts.mybank.co.uk) in
> history. Grouping together all sites in ".co.uk" does not provide for an
> optimum user experience.

It seems to me that what you want is metadata about certain domains.
Therefore, what you need is a mechanism for publishing metadata, not a
magical list of domains about which you'll have hard-coded
information. 

I agree with Ed Lewis's remarks that operators often want such lists.
I understand the value of them.  I am arguing that coming up with such
a list and hard-coding it anywhere is a very bad idea, because users
will not get predictable behaviour, particularly in new TLDs and other
new areas of the DNS tree.  That unpredictability of behaviour means
that new services have yet more barriers to surmount before success.
I think that's a bad thing.

> As I noted in an earlier message, this may solve security problems but
> does not solve privacy ones.

That seems to be yet more reason to try to fix the cookies
specification, rather than trying to impute metadata to the DNS
labels.

Obviously, it's your code, and you can do what you want with it.  But
I think this is a very bad idea, and I think it's a shame that it
should be adopted anywhere.

A
-- 
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

Andrew Sullivan wrote:
> Is there any way to turn this off in Firefox 3?  

Not that I know of.

> RFC 3696 explains, I think, most of the reasoning that I would offer
> for why I think this is a bad idea.  I urge you and others who are
> planning to ship this kind of feature to go (re)read that RFC.

Why do you think that the negative consequences explained in that RFC
would apply in this case? Please think carefully about the consequences
of possible failure scenarios.

> I know that you have a security problem, which is that cookies are
> widely used for some purposes in such a way that they can be
> subverted.  That's a problem with the cookies specification, which was
> always broken. 

This isn't just about cookies. For example, we would like to group
together related sites (www.mybank.co.uk, accounts.mybank.co.uk) in
history. Grouping together all sites in ".co.uk" does not provide for an
optimum user experience.

> If you're not going to fix the cookies specification (which is what I
> think you ought to do, but I understand why people are reluctant to
> take that on), then there should at least be some way to publish data
> about the relationship you want to permit.  One way to do this would
> be to figure out a way to publish lists of domains for which a given
> domain publishes cookies, and from which a given domain accepts
> cookies. 

As I noted in an earlier message, this may solve security problems but
does not solve privacy ones.

> I still run into problems with email addresses in .info domains not
> being accepted, because the top level domain label is "too long".

Which is why the list is soft-fail - e.g in the cookie case, if a new
TLD is added which is not on the list, we simply fall back on the
current behaviour.

Gerv
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Yngve Nysaeter Pettersen]

On Mon, 09 Jun 2008 16:07:10 +0200, Wes Hardaker <[EMAIL PROTECTED]>  
wrote:

> EG, if I had "www.example.com" and I received cookies in a request from
> "example.com", "images.example.com" and "hacker.com" I could determine

Not sure if you mean that www.example.com is sending cookies for  
example.com, images.example.com and hacker.com, of which only the first is  
legal, or that www.example.com includes resource that sets cookies for  
those destinations, which can be controlled by third-party cookie filters.

> based on the source which ones I wanted to accept.  The current issue
> with cookie usage is that sites don't have the ability to not accept
> data from external sources.  Fix that problem instead and you'll have a
> much better and more scalable solution.  It'll require work on both the
> server side and the browser side but in the end is a better solution.

RFC 2965 requires the client to send the domain along with the cookie  
under some conditions. My suggested update of RFC 2965 http://www.ietf.org/internet-drafts/draft-pettersen-cookie-v2-02.txt > ,  
which changes the domain semantics, also suggest sending the domain for  
_all_ cookies, also those set using old versions of the specification, and  
the name of the host setting the cookie (if known) for cookies set using  
the older versions.

For cookies, the primary problem here is limiting what the client can set,  
so that malicious.co.uk cannot set a cookie that will be seen by  
mybank.co.uk, or that can be used to track users across several domains  
(without advertising that they do share the information).

Requesting permission from the server (or individual resources) to send  
cookies will require an extra turnaround, thus reducing performance.

-- 
Sincerely,
Yngve N. Pettersen

Senior Developer Email: [EMAIL PROTECTED]
Opera Software ASA   http://www.opera.com/
Phone:  +47 24 16 42 60  Fax:+47 24 16 40 01

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Andrew Sullivan]

On Mon, Jun 09, 2008 at 11:00:39AM +0100, Gervase Markham wrote:

> The following email message will shortly be sent to the technical
> contact for all TLDs. Yngve Pettersen at Opera suggested that I also let
> you both know about it.
> 
> The technology in question, including a version of the list, is about to
> ship in Firefox 3, but we'd like to verify and improve the quality of
> the underlying data.

Is there any way to turn this off in Firefox 3?  Because it seems to
me (as I argued before in response to Yngve's I-D) that this is a
spectacularly bad idea.

RFC 3696 explains, I think, most of the reasoning that I would offer
for why I think this is a bad idea.  I urge you and others who are
planning to ship this kind of feature to go (re)read that RFC.

I know that you have a security problem, which is that cookies are
widely used for some purposes in such a way that they can be
subverted.  That's a problem with the cookies specification, which was
always broken. 

If you're not going to fix the cookies specification (which is what I
think you ought to do, but I understand why people are reluctant to
take that on), then there should at least be some way to publish data
about the relationship you want to permit.  One way to do this would
be to figure out a way to publish lists of domains for which a given
domain publishes cookies, and from which a given domain accepts
cookies.  In a DNSSEC context, this could be a secure way of
communicating such data without resorting to hard-coded lists.  Loathe
as I am to suggest yet another way of loading up the DNS, I expect it
could be done with a DNS RR.

I still run into problems with email addresses in .info domains not
being accepted, because the top level domain label is "too long".
This is years after .info went into the root, and yet we have these
old hard-coded rules hanging about the Internet.  It was a bad idea
when they did it then, and it's a bad idea to do it now.

Best regards,
A

-- 
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

Patrik Fältström wrote:
> What about new structures in a TLD that is in the list?

If the structure is additive, then again there is no problem. If it is
reductive, then there are potential problems depending on how the
customers of the newly-available domains set things up.

Let us say, for example, that the .zz domain has five sub-levels, which
are the only places you can register:

com.zz
org.zz
net.zz
ltd.zz
plc.zz

So this is what the list will say. Now, say the .zz domain changes their
policies to permit direct registration under the root.

If someone purchases "foo.zz", they will not be able to set a cookie for
"foo.zz" until the list is updated. They will, however, be able to set
one for "www.foo.zz". So what is inhibited is the sharing of cookies
across different sites in the same domain, not the setting of cookies
entirely.

I agree that this is not ideal. But I believe what we are doing now is
the least worst option, and that good publicity for the scheme among the
TLD owners will mean that if they are considering such a move, they will
let us know. I hope that publicsuffix.org (or somewhere more official)
will become the single source for this data.

Gerv
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

Wes Hardaker wrote:
> I think a better policy would be to fix the HTTP protocol so that it
> could specify an incoming cookie policy.  Rather than having every site
> under the sun be able to set cookies and block that by some random list
> of hard coded "within" list, allow each site to specify where they
> accept cookies from.  

That doesn't solve the privacy problem.

If www.flirble.co.zz and www.widget.co.zz wished to conspire to track
users across the two sites, they would simply both say that they are
happy to accept co.zz cookies.

I am not particularly interested in a long discussion about whether we
need this data. Please be assured that we need it. I am, on the other
hand, open to suggestions about better ways to obtain it.

Gerv
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Edward Lewis]

At 16:00 +0200 6/9/08, Yngve Nysaeter Pettersen wrote:
>On Mon, 09 Jun 2008 15:32:11 +0200, Patrik Fältström <[EMAIL PROTECTED]>
>wrote:
>
>>  The problem with any such mechanisms is that the barrier of entry for
>>  new players (that does not match the currently used list -- including
>>  non-upgraded software) is increased. More than what people think.
>
>That is why my subtld-structure draft is suggesting that TLD profiles be
>downloaded at regular intervals (and at need) from a repository, in order
>to make it possible to add new TLDs or new registry-like domains under a
>TLD, and to prevent problems with old software. My drafts also suggest a
>rule-of-thumb fallback in case a TLD is unknown.

This thread is going to go around in circles for 
quite a while.  There's a history of the IETF 
wanting to define something without fixed 
boundaries.  DNS names is one, IPv6 addresses is 
another.  But when it comes to operations, having 
fixed boundaries makes mass production much 
easier.

E.g., in IPv6, IETFer's (as we know, the IETF 
doesn't have any official statement source and no 
members, so I refer to those in the debate that 
brandish IETF credentials) would say that the 
days of classful addressing are behind us, so 
IPv6 addresses ought to be treated as nothing but 
a string of 128 bits.  But RIR policy writers 
wanted to know whether to recommend /48's, /54's, 
/32's, etc. for certain types of uses.  ("Uses" 
not users.)

Shifting back to DNS, there's not going to be a 
scientific differentiation between one zone and 
another.  During the DNSSEC development days we 
wanted to declare some zones as "widely 
delegated" (such as .com) from other zones - to 
alleviate the issues we see with NSEC, NSEC3, 
etc. that are apparent still now.  There's 
nothing in DNS to differentiate, at a protocol 
level, one zone from another, but at the 
operational end of the stick, there are many 
differentiators (like whether the administration 
interface is on paper or via EPP).

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.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis+1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Wes Hardaker]

> On Mon, 09 Jun 2008 12:48:19 +0100, Gervase Markham <[EMAIL PROTECTED]> 
> said:

GM> Fortunately, Firefox has an extremely good and fast update and uptake
GM> rate. This is partly because we don't give users a choice about taking
GM> non-major-version updates.

And how long to do you maintain the older versions?  Are you forever
going to ship updates to your older branches?

I think a better policy would be to fix the HTTP protocol so that it
could specify an incoming cookie policy.  Rather than having every site
under the sun be able to set cookies and block that by some random list
of hard coded "within" list, allow each site to specify where they
accept cookies from.  The browser would need to track the source of each
cookie, but that would be helpful for other tracking reasons anyway.

EG, if I had "www.example.com" and I received cookies in a request from
"example.com", "images.example.com" and "hacker.com" I could determine
based on the source which ones I wanted to accept.  The current issue
with cookie usage is that sites don't have the ability to not accept
data from external sources.  Fix that problem instead and you'll have a
much better and more scalable solution.  It'll require work on both the
server side and the browser side but in the end is a better solution.

(and DNSSEC will be useful for assuring that the cookie creation site
isn't spoofing their address)
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Yngve Nysaeter Pettersen]

On Mon, 09 Jun 2008 15:32:11 +0200, Patrik Fältström <[EMAIL PROTECTED]>  
wrote:

> The problem with any such mechanisms is that the barrier of entry for
> new players (that does not match the currently used list -- including
> non-upgraded software) is increased. More than what people think.

That is why my subtld-structure draft is suggesting that TLD profiles be  
downloaded at regular intervals (and at need) from a repository, in order  
to make it possible to add new TLDs or new registry-like domains under a  
TLD, and to prevent problems with old software. My drafts also suggest a  
rule-of-thumb fallback in case a TLD is unknown.



-- 
Sincerely,
Yngve N. Pettersen

Senior Developer Email: [EMAIL PROTECTED]
Opera Software ASA   http://www.opera.com/
Phone:  +47 24 16 42 60  Fax:+47 24 16 40 01

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Patrik Fältström]

On 9 jun 2008, at 15.41, Gervase Markham wrote:

> Patrik Fältström wrote:
>> The problem with any such mechanisms is that the barrier of entry for
>> new players (that does not match the currently used list -- including
>> non-upgraded software) is increased. More than what people think.
>
> This isn't so. For TLDs not in the list, the usual rules (about e.g.
> cookie setting) would be applied. In other words, the situation is no
> different to what it is now. This information is additive.

What about new structures in a TLD that is in the list?

I.e. I do understand what you want to do, but am nervous still about  
the result if the list is not updated. Yes, you say your software is  
updated often, and sure, you might be the best in the class.

I just felt it was sort of my job to point out the risks, specifically  
as the risks are written down.

What you at the end of the day do is of course up to you. ;-)

Patrik

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

Patrik Fältström wrote:
> The problem with any such mechanisms is that the barrier of entry for  
> new players (that does not match the currently used list -- including  
> non-upgraded software) is increased. More than what people think.

This isn't so. For TLDs not in the list, the usual rules (about e.g.
cookie setting) would be applied. In other words, the situation is no
different to what it is now. This information is additive.

Gerv
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Patrik Fältström]

On 9 jun 2008, at 12.00, Gervase Markham wrote:

> The following email message will shortly be sent to the technical
> contact for all TLDs. Yngve Pettersen at Opera suggested that I also  
> let
> you both know about it.

The problem with any such mechanisms is that the barrier of entry for  
new players (that does not match the currently used list -- including  
non-upgraded software) is increased. More than what people think.

When we added TLDs with more characters than three, we had problems.  
Now we will with lists like these have similar problems again.  
Specifically as we are on the edge of getting new TLDs etc etc (IDN  
related issues, if nothing else).

This is already described in RFC 3696, Section 2.

Patrik

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[bert hubert]

On Mon, Jun 09, 2008 at 08:33:30AM -0400, Edward Lewis wrote:
> If the browsers do implement a check based on TLD name, I bet they 
> are also gullible enough to implement RFC 3514.

Browsers already implement a lot of 'supra-dns' knowledge. Try visiting a
known malware or phishing site these days with a good browser. It is not the
sort of mathematically proven protection we all crave but I'm not going to
stand in their way of improving the security of a typical browsing session.

A lot more useful than 3514 for sure.

Raising bars is not perfection, but it still raises the bar.

Bert

-- 
http://www.PowerDNS.com  Open source, database driven DNS Software 
http://netherlabs.nl  Open and Closed source services
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[bert hubert]

On Mon, Jun 09, 2008 at 02:24:30PM +0200, Antoin Verschuren wrote:
> > You can't hijack something that does not exist though, which is what I
> > think
> > is the problem here.
> 
> Agree, but when this global list of local DNS policy would exist and used, 
> which would be authoritative, the list or the DNS ? 

The DNS of course. Compare whois for example - that is also
'non-authoritative' for real DNS lookups.

If I understand correctly, Mozilla wants to use this for security purposes:

  The usefulness of this can be seen if we take the example of cookies.
  Currently, browsers use an algorithm which basically only denies setting
  wide-ranging cookies for top-level domains with no dots (e.g. com or org).

  However, this does not work for top-level domains where only third-level
  registrations are allowed (e.g. .co.uk). In these cases, websites can set
  a cookie for .co.uk which will be passed onto every website registered
  under co.uk.

  Since there is no algorithmic method of finding the highest level at which
  a domain may be registered for a particular top-level domain (the policies
  differ with each registry), the only method is to create a list. This is
  the aim of the Public Suffix List.

  Software using the Public Suffix List will be able to detemine where
  cookies may and may not be set, protecting the user's data from theft.

So the instaflaming and ""technology"" jokes appear to be out of place. 

If "we" DNS people think we have a better way of encoding "public
delegations", we should move quickly to make that happen. In the meantime,
the public suffix list is probably a great idea.

Bert

-- 
http://www.PowerDNS.com  Open source, database driven DNS Software 
http://netherlabs.nl  Open and Closed source services
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Edward Lewis]

(Responding only on the DNS list to avoid cross posting.)

At 14:11 +0200 6/9/08, bert hubert wrote:
>On Mon, Jun 09, 2008 at 02:02:05PM +0200, Antoin Verschuren wrote:
>(...)
>>  I'm very afraid that Mozilla is trying to hijack the authority model here.
>
>You can't hijack something that does not exist though, which is what I think
>is the problem here.

Yes you can hijack something that doesn't exist (for varying values 
of existence).

This is the same situation that the RIRs faced with the bogon lists 
for IP address prefixes.  (The problem peaked as recently as 2005 - 
i.e., it was a recent one.)  ISPs would filter out all traffic to the 
unallocated slash-8's (as listed by IANA as inactive).  When an RIR 
was allocated a slash-8, even an announcement on mailing lists wasn't 
enough to get all filters changed.  Now the RIR's put in test 
addresses for traceroutes and pings to allow checks for bad filters.

If the browsers do implement a check based on TLD name, I bet they 
are also gullible enough to implement RFC 3514.

Keep in mind that there is more than just the ICANN root zone DNS in 
the world.  Perhaps the thought is that it is the only legitimate 
root zone on the global public Internet but there are other global 
inter-networks.  These networks also employ DNS albeit operating 
under a private administration.  A browser that is hard-wired for the 
global public Internet would be a problem on these private networks.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis+1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Elmar K. Bins]

Re Antoin,

[EMAIL PROTECTED] (Antoin Verschuren) wrote:

> > You can't hijack something that does not exist though, which is what I
> > think
> > is the problem here.
> 
> Agree, but when this global list of local DNS policy would exist and used, 
> which would be authoritative, the list or the DNS ? 

That will entirely depend on the degree of adoption ;-)

Honestly, I see the Mozilla guys taking the lead here and probably
establishing a trust model that the actual TLD operators don't want
that way. When established (through upgrade to current Firefoxes),
it will definitely "rule", whatever the TLD operators do, until
an understanding between the supplier of the widespread tool (FF)
and the "autorities" has been established.

Application manufacturers can set de-facto standards if their
product is widespread enough.

The problem I see here - for the TLD operators - is that there are
more applications/manufacturers than available hands at the operators
to make cooperation even possible...

Yours,
Elmi.

-- 

"Hinken ist kein Mangel eines Vergleichs, sondern sollte als wesentliche
 Eigenschaft von Vergleichen angesehen werden."   (Marius Fränzel in desd)

--[ ELMI-RIPE ]---

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Antoin Verschuren]

> -Original Message-
> From: bert hubert [mailto:[EMAIL PROTECTED]
> 
> You can't hijack something that does not exist though, which is what I
> think
> is the problem here.

Agree, but when this global list of local DNS policy would exist and used, 
which would be authoritative, the list or the DNS ? 

Antoin Verschuren

Technical Policy Advisor
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands

T +31 26 3525500
F +31 26 3525505
M +31 6 23368970
E [EMAIL PROTECTED]
W http://www.sidn.nl/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[bert hubert]

On Mon, Jun 09, 2008 at 02:02:05PM +0200, Antoin Verschuren wrote:
(...) 
> I'm very afraid that Mozilla is trying to hijack the authority model here.

You can't hijack something that does not exist though, which is what I think
is the problem here.

Bert

-- 
http://www.PowerDNS.com  Open source, database driven DNS Software 
http://netherlabs.nl  Open and Closed source services
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Antoin Verschuren]

> If you are going to push this 'technology', you might want to consider
> doing an SPF-alike test, thus getting that information from the provider
> of the label, or better: fix the cookie standards.

I must agree here.
What I see here is an attempt to make a global list of local policy.
That won't scale administrative.
You're trying to apply 2 structures on the same namespace.
If you would like to get some authoritative answer on the existence of a zone 
boundary, the only place you should administer this is in the DNS itself.

I'm very afraid that Mozilla is trying to hijack the authority model here.
If this is hardcoded into Firefox, and requires a software update for changes 
to work, then all TLD's are delivered to the goodwill of Firefox developers to 
have changes to their zones work in real life.
And what's next, TLD's that need to propagate changes in their zones to each 
and every software developer, so it can be hardcoded in their products too ?

Antoin Verschuren

Technical Policy Advisor
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands

T +31 26 3525500
F +31 26 3525505
M +31 6 23368970
E [EMAIL PROTECTED]
W http://www.sidn.nl/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

Jeroen Massar wrote:
> [Why not go DNSSEC first instead of solving a problem which is not a
> real problem? See below... ]

I'm not sure that DNSSEC solves the problem we are trying to solve, but
would be happy to be enlightened.

> You are *hard-coding* such a list into a 'product'? You do realize that
> a lot of people simply don't update their software I hope. Unfortunately
> for the OS's that need updating the most those people don't tend to update.

Fortunately, Firefox has an extremely good and fast update and uptake
rate. This is partly because we don't give users a choice about taking
non-major-version updates.

> You might want to consider using at least an RBL-style way for this.
> Though, you will of course hit off on all the privacy folks when you are
> doing another DNS query for www.spooks.gov.rbl.mozilla.org every hit and
> collecting all that information. 

Indeed. This is why this type of scheme is not a runner.

Yngve Pettersen of Opera has suggested something like this in his
internet draft; however, my view is that getting comprehensive buy-in
would take quite a lot more time and effort than this method.
http://www.ietf.org/internet-drafts/draft-pettersen-subtld-structure-03.txt

> How can non-TLD's get into this list!? 

Just by asking; I already got an email from CentralNIC.

> If you are going to push this 'technology', you might want to consider
> doing an SPF-alike test, thus getting that information from the provider
> of the label, or better: fix the cookie standards.

Yngve has several suggestions about how this may be fixed longer-term:
http://my.opera.com/yngve/blog/2008/02/25/refreshed-internet-drafts-0208

However, this is what we have that works here and now.

> And another much better step which I think the rest of this group (as of
> course this message is just and only my personal opinion and not that of
> the group in anyway... that is how the IETF works afterall ;) would
> actually also like is the use of DNSSEC. Which actually tells you that
> the domain you are looking at is really the domain you are requesting
> records from. 

That's a different problem, though. Even if DNSSEC was deployed, it
wouldn't teach browsers about the structure of the DNS.

Gerv
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Jeroen Massar]

[Why not go DNSSEC first instead of solving a problem which is not a 
real problem? See below... ]


Gervase Markham wrote:
[..]
> The technology in question, including a version of the list, is about
> to ship in Firefox 3, but we'd like to verify and improve the quality
> of the underlying data.

You are *hard-coding* such a list into a 'product'? You do realize that 
a lot of people simply don't update their software I hope. Unfortunately 
for the OS's that need updating the most those people don't tend to update.


Hard-coding can be fine for most TLD's which are quite static in setup 
and might not ever change, but what about everybody else?


You might want to consider using at least an RBL-style way for this.
Though, you will of course hit off on all the privacy folks when you are 
doing another DNS query for www.spooks.gov.rbl.mozilla.org every hit and 
collecting all that information. Guess that quite a few companies would 
also become quite jealous of those kind of data collecting techniques, 
just like the current "domain protection" stuff that exists in FF which 
allows collection of that kind of information.


[..]

We are maintaining a list of all "Public Suffixes". A Public Suffix is a
domain label under which internet users can directly register domains.
Examples of Public Suffixes are ".net", ".org.uk" and ".pvt.k12.ca.us".


How can non-TLD's get into this list!? Eg www.google.com is quite 
different from evilsite.google.com which is not under the same 
administrative control as the first. Of course it is not the smartest 
way of setting up a trusted site, but it happens a lot, eg to save on 
costs for SSL certificates one customer gets cust1.ssl.example.org and 
the next cust2.ssl.example.org, they are not the same and might both be 
evil. Not even going into warring departments or even rival countries 
being put under the same DNS label (tw.example.org, cn.example.org ;)


If you are going to push this 'technology', you might want to consider 
doing an SPF-alike test, thus getting that information from the provider 
of the label, or better: fix the cookie standards.


The latter could be achieved, amongst others, by having the cookie 
include only exactly the domains/sites for which that cookie is valid.

And of course not allowing wild-card cookies anymore...

And another much better step which I think the rest of this group (as of 
course this message is just and only my personal opinion and not that of 
the group in anyway... that is how the IETF works afterall ;) would 
actually also like is the use of DNSSEC. Which actually tells you that 
the domain you are looking at is really the domain you are requesting 
records from. Who cares about the cookie domain if bank.com is actually 
evilbank.com. (of course again not even going to the b4nk.com example 
and all others).


Lastly; DNS does not establish that you are talking to the domain you 
think you are talking to, it only makes it look like that.


Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Public Suffix List

[Gervase Markham]

Dear HTTP and DNS Operations WGs,

The following email message will shortly be sent to the technical
contact for all TLDs. Yngve Pettersen at Opera suggested that I also let
you both know about it.

The technology in question, including a version of the list, is about to
ship in Firefox 3, but we'd like to verify and improve the quality of
the underlying data.

Please let me know if you see any way I can improve the email, the
explanatory website, or the submission process.

Gerv


Dear Technical Contact,

The Mozilla Project (http://www.mozilla.org/), responsible for the
Firefox web browser, requests your help.

We are maintaining a list of all "Public Suffixes". A Public Suffix is a
domain label under which internet users can directly register domains.
Examples of Public Suffixes are ".net", ".org.uk" and ".pvt.k12.ca.us".
In other words, the list is an encoding of the "structure" of each
top-level domain, so a TLD may contain many Public Suffixes. This
information is used by web browsers for several purposes - for example,
to make sure they have secure cookie-setting policies. For more details,
see http://publicsuffix.org/learn/.

We would like your help to make sure, now and in the future, that the
entries for your TLD(s) are correct. It is in your interest as a
registry to make sure that this is so. Any errors may either cause your
customers (domain owners in your TLD) to not be able to set cookies when
they should, or cause cookie information to be leaked between two
domains without a trust relationship. Neither of these things is desirable.

Therefore, we are writing to ask your technical team to view the current
list and, if it is incorrect, to submit updated data. A description of
the format of the list, and details for sending updates is at:

http://publicsuffix.org/submit/

We also ask you to send updated information whenever you change your
registration policies in a way which affects the list.

Thanking you in advance,

Gervase Markham
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop