Subject: Public Suffix List

From: Gervase Markham <[email-masked]>
Date: Mon, 09 Jun 2008 11:00:39 +0100

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

<snip>
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

---

From: Gervase Markham <[email-masked]>
Date: Mon, 09 Jun 2008 12:48:19 +0100

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 9 Jun 2008 15:15:09 +0200

> explanatory website, or the submission process.

Hi, I think you should mention the special cases NIC, WHOIS, and WWW
in <http://gnso.icann.org/drafts/reservations-nic-whois-wwwv8.pdf>
for your purposes.  FWIW both 2606bis I-Ds tried or try to tackle
it, compare <http://tools.ietf.org/html/draft-eastlake-2606bis> and
<http://tools.ietf.org/html/draft-ellermann-idnabis-reserved-tlds>.

At the time when it was created I submitted a few obscure cases like
.e164.arpa to the SURBL suffix white list, and so I'm not sure why
you want to organize this again as a "private" registry instead of
creating an "official" IANA registry in an RFC.  This stuff can be
quite disruptive if you get it wrong for any reason.

 Frank

---

From: Gervase Markham <[email-masked]>
Date: Mon, 09 Jun 2008 14:41:31 +0100

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

---

From: Gervase Markham <[email-masked]>
Date: Mon, 09 Jun 2008 14:48:13 +0100

Frank Ellermann wrote:
> for your purposes. 

Interesting, but I don't think it's relevant. What makes you think it is?

 FWIW both 2606bis I-Ds tried or try to tackle
> .e164.arpa to the SURBL suffix white list, 

Where can I find a copy of this list?

> and so I'm not sure why
> creating an "official" IANA registry in an RFC. 

We are maintaining it for anyone and everyone to use. If IANA were
interested in maintaining this information instead of us, that would be
great.

Gerv

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Mon, 09 Jun 2008 16:00:17 +0200

> 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-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Gervase Markham <[email-masked]>
Date: Mon, 09 Jun 2008 15:21:11 +0100

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

---

From: Gervase Markham <[email-masked]>
Date: Mon, 09 Jun 2008 15:24:52 +0100

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

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Mon, 09 Jun 2008 16:38:05 +0200

On Mon, 09 Jun 2008 16:07:10 +0200, Wes Hardaker <[email-masked]>  
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 <URL:  
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.

---

From: Gervase Markham <[email-masked]>
Date: Mon, 09 Jun 2008 15:43:29 +0100

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 9 Jun 2008 16:53:21 +0200

Gervase Markham wrote:

 [NIC, WHOIS, and WWW]
> Interesting, but I don't think it's relevant. What makes you

I think that any concept of "globally reserved" SLD labels is
FUBAR.  What could happen is that your list claims to list all
SLDs for a given TLD, forgetting NIC, WHOIS, or WWW.  

What TLDs do is their business, and it could be a can of worms
if the TLDs are redelegated later.  It would be nice to know 
the state of the art now for any given TLD, and TLD admins are
free to publish their policies in an RFC.  Unfortunately most
don't, offering an official IANA registry where they can do it
might help, but it is tricky.

They'd need to be aware that it will be near to impossible to
change some published practises even after a TLD redelegation.

E.g., .co.uk is what it is today, any attempt to twist it into
an ordinary domain or wildcard could cause havoc, but it is 
hard to find anybody in the position to say MUST NOT.  If TLD
.uk itself says it, is that binding after a redelegation ?  If
ICANN says it, do they have a MoU with ccTLD .uk covering it ?
AFAIK there is no BCP or standards track RFC to justify this.

If your private list says it, what if they really change their
rules for some convoluted applications we are not yet aware of,
say NAPTR ?  What if the DKIM WG invents a new .co.uk wildcard
for ADSP purposes ?  BTW, they won't, but IMO your list cannot
guarantee that nobody else does it.

That you forwarded your question to the HTTPbis list triggered
my sitefinder.verisign alert, HTTP is not the only user of DNS.

>> At the time when it was created I submitted a few obscure
>> cases like .e164.arpa to the SURBL suffix white list, 
 
> Where can I find a copy of this list?

What I had in mind was <http://www.surbl.org/faq.html#cctlds>
with a link to <http://spamcheck.freeapp.net/two-level-tlds> -
IMHO the term "two level TLDs" is already too wrong to fix it.

> We are maintaining it for anyone and everyone to use. If IANA
> were interested in maintaining this information instead of us,
> that would be great.

I think that IANA is not "interested" to create new registries,
they are "obliged" to do this under RFC 5226 and 2860 rules. :-)

See <http://www.iab.org/documents/correspondence/index.html> with
http://www.iab.org/documents/correspondence/IANA-2006/IAB-IANA-Position.htm
http://www.iab.org/documents/correspondence/2008-02-15-midterm-view-icann-doc-jpa.html

 Frank

---

From: Adrien de Croy <[email-masked]>
Date: Tue, 10 Jun 2008 03:23:23 +1200

I agree.  I'm really not fond of this idea.

IMHO creating registries and heuristics like this will be about as 
effective as bayesian antispam.

I see it creating a large administrative burden on many people, but 
never catching up with the current state.  I see people relying on it 
for all manner of things for which it's not designed.  Also you're 
dealing with organisations whose prime focus is not maintaining your 
list.  You might get some initial enthusiasm to start, but down the 
track I see that waning.

This is all being proposed to _enable_ cross-site cookies (as opposed to 
just blocking or warning the user).. why not make that aspect explicit?  
I can't see any other way to make it secure.  Ignore DNS, make the 
cookies' realm explicit. 

As for privacy, if an issuer of a cookie prescribes the realms within 
which that cookie may be submitted, then privacy falls under the control 
of the cookie-issuing site.  A compliant browser won't submit it outside 
those realms.

And as for sites colluding... well there are other ways for sites to 
collude to learn things from each other without even involving the 
client. I think we have to accept that if sites really want to collude, 
they will find a way to do so.

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Gervase Markham <[email-masked]>
Date: Mon, 09 Jun 2008 16:29:03 +0100

Adrien de Croy wrote:
> for all manner of things for which it's not designed. 

That's their problem.

> Also you're

Their incentive to keep the list up to date is that sites in their TLD
will be treated correctly by browsers, which will keep their customers
happy.

> just blocking or warning the user).. 

No. It's being proposed to *disable* cross-site cookies which we
currently enable because we have no good way to prevent. Along with
other UI applications in the areas of:

- History
- Download Manager
- UI display of responsible domain for SSL DV certs
  (this isn't switched on by default in Firefox 3)

> of the cookie-issuing site.  A compliant browser won't submit it outside

The problem is sites conspiring against a user to damage the user's
privacy and track them across multiple sites.

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Mon, 09 Jun 2008 16:57:32 +0100

David Conrad wrote:
>> however, my view is that getting comprehensive buy-in
> 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.

> 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

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 9 Jun 2008 17:24:27 +0100

> history. Grouping together all sites in ".co.uk" does not provide for an

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

---

From: Gervase Markham <[email-masked]>
Date: Mon, 09 Jun 2008 17:28:52 +0100

> or DNS record for mybank.co.uk?

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

> 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

---

From: Gervase Markham <[email-masked]>
Date: Mon, 09 Jun 2008 17:34:16 +0100

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

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 9 Jun 2008 17:36:59 +0100

> 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

---

From: Gervase Markham <[email-masked]>
Date: Mon, 09 Jun 2008 17:50:03 +0100

> 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.

> to provide you with information about independent or related users of

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

Gerv

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 09 Jun 2008 11:34:39 +0000

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.

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.

[..]
> 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 ;)

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

---

From: "Antoin Verschuren" <[email-masked]>
Date: Mon, 09 Jun 2008 12:02:44 +0000

> 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-masked]
W http://www.sidn.nl/

---

From: bert hubert <[email-masked]>
Date: Mon, 09 Jun 2008 12:12:14 +0000

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

---

From: "Antoin Verschuren" <[email-masked]>
Date: Mon, 09 Jun 2008 12:25:09 +0000

> -----Original Message-----
> From: bert hubert [mailto:[email-masked]]
> 

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

---

From: "Elmar K. Bins" <[email-masked]>
Date: Mon, 09 Jun 2008 12:30:52 +0000

Re Antoin,

> 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 ]---

---

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 09 Jun 2008 10:35:53 -0700

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:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 09 Jun 2008 13:33:04 +0000

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

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 09 Jun 2008 13:56:56 +0000

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

---

From: bert hubert <[email-masked]>
Date: Mon, 09 Jun 2008 12:34:52 +0000

> 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

---

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 09 Jun 2008 11:54:14 -0700

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 9 Jun 2008 12:31:13 -0700

>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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 9 Jun 2008 22:14:49 +0200

On Mon, Jun 09, 2008 at 12:57:00PM -0400,
 Brian Dickson <[email-masked]> 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.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 9 Jun 2008 22:19:08 +0200

On Mon, Jun 09, 2008 at 11:56:05AM -0700,
 David Conrad <[email-masked]> 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.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 9 Jun 2008 23:02:01 +0200

On Mon, Jun 09, 2008 at 10:29:27AM -0400,
 Andrew Sullivan <[email-masked]> wrote 

> 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/

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 9 Jun 2008 23:09:16 +0200

On Mon, Jun 09, 2008 at 03:21:11PM +0100,
 Gervase Markham <[email-masked]> 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"

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 9 Jun 2008 23:14:15 +0200

On Mon, Jun 09, 2008 at 11:07:23PM +0200,
 Phil Regnauld <[email-masked]> 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.

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 10 Jun 2008 00:16:09 +0200

Phil Regnauld wrote:

 [about:config in FF]
> disable network.IDN.whitelist for all listed TLDs.

AFAIK that's about TLDs with no-nonsense IDN policies,
not about cookies.  If you want no IDN display you 
can enable network.IDN_show_punycode globally.

If you want no third party cookies FF makes this more
interesting, try network.cookie.cookieBehavior 1.

I fear you have to check this after each update, with
IE6 "no third party cookies" was simpler.  It should
be the default, of course, but... <sigh />  See also
http://kb.mozillazine.org/Firefox_:_FAQs_:_About:config_Entries#Network..2A

But don't believe this without checking what happens,
the FAQ can be obsolete, and never underestimate the
criminal energy of the tracker industry.

 Frank

---

From: Adrien de Croy <[email-masked]>
Date: Tue, 10 Jun 2008 11:01:00 +1200

>> for all manner of things for which it's not designed. 
it will become their customers problem.

> other UI applications in the areas of:

I disagree.  If you were really wanting to disable cross-site cookies, 
you wouldn't need any of this, you'd just block them in the browser.

This is fundamentally enabling in a restricted mode, which is enabling, 
not disabling.

> privacy and track them across multiple sites.
this can be done regardless.  Site A gets request from client, submits 
request back to site mentioned in referer tag.  Client not involved 
except for transporting the referer information.

Adrien

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 9 Jun 2008 16:51:02 -0700

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 
<http://www.ietf.org/mail-archive/web/dnsop/current/msg06140.html>. 
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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 10 Jun 2008 11:09:19 +0200

On Mon, Jun 09, 2008 at 04:51:02PM -0700,
 Paul Hoffman <[email-masked]> wrote 
 a message of 28 lines which said:

> 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, ...).

It would be interesting to know if it was a deliberate decision
(because they did not appreciate an unilateral policy) or negligence.

AFAIK, none of these TLD explained their decision publically.

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 10 Jun 2008 11:09:17 +0100

> My solution involves communicating with a far smaller group.

No, I don't think so.

The information would be published in the ISP's TLD-alike domain, not
the customer's subdomains.  E.g. 'co.uk', not 'mybank.co.uk', assuming
the information is "each domain $WORD.co.uk is independent".

The values are the same information that you are gathering.  The
ISP/NIC (Nominet UK for .co.uk) does not need to contact their
customers for this: it's a .co.uk policy.

> vastly larger than the other.

See above.

-- Jamie

---

From: Gervase Markham <[email-masked]>
Date: Tue, 10 Jun 2008 11:11:41 +0100

Hi Doug,

Doug Barton wrote:
> 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.

Just as a matter of fact, Firefox 3 ships in a week; there is no
possibility of further change in that release.

The fact that I am working on this question now is not to present a
/fait accompli/; I've just been too busy to get to it.

> 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

Thank you. I believe something like that was used initially.

> 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.

That would be fine if (again, using cookies as an example) they set them
for www.nic.tld and not nic.tld. Or, they could add an exception to the
public suffix data they submitted.

> phrase "all TLDs" is doomed from the start. :)  

If the scheme relied on getting explicit responses from them all, then
yes, it would be doomed. (That's why I think a model of getting the TLDs
to publish the information via DNS or some other mechanism is doomed.)
But in the absence of their input, we can use public sources and
deduction to make a good guess - or just not give them an entry. There
aren't many ad networks who are setting cookies for .com.je to track
visitors across different Jersey websites.

> 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.

It's real. I recently checked my list and had cookies for both .co.uk
and .com.au.

Yngve probably knows more about this than me, though.

> 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 a static
> list that is built into the binary. 

We can certainly look at that for the next release.
I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=438304 .

> I would further suggest that this should be a user-configurable option.

As a usability person rather than a security person, I think that a good
principle is to only expose preferences which a significant proportion
of your users will be able to understand.

I wouldn't be the person to make the final decision, but I strongly
suspect that UI to turn this off wouldn't make it into the product.

> Finally, I'd like to make a suggestion that I know you will reject, but
> I feel compelled to make it anyway. :)  You could solve this problem
> much more easily by making the default policy to deny cookies, and ask
> the user to choose to accept cookies from domains that they have a trust
> relationship with. 

As you know, I do reject that :-) It's not one user in a thousand who
has the ability to correctly judge whether accepting a particular cookie
is "safe" or not. In one sense, they are all safe. You won't lose any
money by accepting a cookie, and your box can't get rooted. And cookies
don't come with must-be-truthful purpose statements. "OK, I'll accept
the one which says it's required to make the shopping cart one work, and
reject the one that tracks me for advertising purposes."

> I know this was a long post, but I hope you found the information
> valuable. Please let me know if I can be of any further assistance.

Thanks :-)

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Tue, 10 Jun 2008 11:13:06 +0100

> customers for this: it's a .co.uk policy.

OK. Then we are basically back to Yngve's suggestion. But this does
require universal take-up for universal support - and that, as someone
else has pointed out, makes it (in my opinion) doomed.

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Tue, 10 Jun 2008 11:10:29 +0100

Paul Hoffman wrote:
> 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. 

That's an interesting idea. We didn't make the data remotely-updatable
on its own for Firefox 3, but we may be able to do so for the next release.

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Tue, 10 Jun 2008 11:09:56 +0100

David Conrad wrote:
> 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. 

We're about to ask them for their input.

> 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?

Yes, basically. For best results we'd get the data directly from those
in the know, but if they don't want to keep us informed, they don't have to.

If you think this is unreasonable, what is the alternative position?

- "No, sorry, you can't do any of the things for which you might want
this data"

- "It's fine to want this data, but you should get it via this
alternative method:..."

> P.S. If you do send your message to the technical contacts for all the
> TLDs, expect quite a few bounces.  

OK - thanks.

Gerv

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 10 Jun 2008 12:14:55 +0100

> - "It's fine to want this data, but you should get it via this

I'm inclined to suggest: Gather and hard-code your list into Firefox,
and also provide a mechanism by which domain authorities can publish
information which overrides your list for their domain.

E.g. When evaluating online.myservice.free.fr, Firefox could look up
DNS records for online.myservice.free.fr, myservice.free.fr, free.fr
and .fr (in that order), and if there's a record use that.  If not,
use the hard-coded information you have gathered for that domain.

In this case, you would expect, eventually, that free.fr may publish a
record indicating that $NAME.free.fr are independent adminstratives
entities, and that's the first record you'll fine.

One day, someone creates dyndns.littleisp.free.fr, and lets people
register themselves underneath that domain.  (Such as
littlecustomer.dyndns.littleisp.free.fr).  Then, instead of contacting
you and trying to get their information into your next Firefox update,
they would simply publish a DNS record on dyndns.littleisp.free.fr,
and the information would be live immediately.  Not just for Firefox,
but for any web client which adopts the same scheme.

(By the way, although we're talking about administrative divides in
the DNS tree, a little thought might be given to administrative
divides in URL trees.  There are a fair number of sites containing
http://domain.com/user1/* and http://domain.com/user2/*, where those
prefixes indicates separately administered URL spaces.  Do similar
cookie issues apply?  Should a mechanism for publishing details of
administrative divides include URL spaces for the same reasons?)

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 10 Jun 2008 12:16:38 +0100

> else has pointed out, makes it (in my opinion) doomed.

Or you gather data and hard-code it as a starting point, but
simultaneously provide a mechanism for others to publish information
about themselves which you use in real time, which overrides the
hard-coded data if they use it.

-- Jamie

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 10 Jun 2008 13:45:54 +0200

> information, let me know.

It won't until someone specifies in how the data should be represented
in DNS. And DNS is where it belongs, in the zone it relates to.

Regards
Henrik

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 11 Jun 2008 00:10:40 +1200

From what I can tell:

a) the proposed problem is that of cookies being used across differently 
administered web sites.

b) the proposed solution involves mapping the boundary between privately 
and publicly administered DNS space.

I don't see how (b) addresses (a).  Web sites does not equal DNS.  
Private vs public DNS does not equal differently-administered websites. 

Furthermore keeping an accurate map of the DNS boundary is impossible.  
So to me it seems like the wrong tool for the job.

Given that this model has been chosen, in the knowledge that it's based 
on an assumption that the problem cases in (a) are addressed by (b), how 
well has that assumption been tested?  The boundary issues should be 
well known.  Several have been raised already on this list.  I'd be 
interested in seeing Mozilla's analysis of them.

My feeling is there will be a lot of false positives and negatives near 
the border, since the "solution" is in a different "space" to the 
problem.  Given the amount of work entailed in attempting to do (b), 
surely there's a responsibility to do this right?  I fear such a crude 
tool will not only cause problems for users, webmasters and TLD 
managers, but also leave ample room for people to circumvent its intent, 
leaving us worse off than we are now - still with cookies broken, still 
with privacy issues and XS issues, but now a major browser vendor 
causing DNS administrative havoc, and forcing people to rewrite their 
websites as well.  How to win friends and influence people.  And the 
justification for this is that it will.... Allow some "safe" cross-site 
cookies?  What happens when it doesn't do that?  Do people even care 
enough about that to live with this solution?

In a perfect world if this turns to custard, only Mozilla would suffer, 
but this isn't a perfect world, and actually I'm sure we'd all like 
Mozilla to live long and prosper.

In the end what will be the deciding factors?  I see users dumping FF3 
when it doesn't work with the websites they know and trust.  I see the 
reviews bemoaning compatibility issues.  Mozilla needs to be careful 
when introducing something like this that can create many compatibility 
issues where the previous version didn't have them.  In the end if some 
large jurisdictions refuse to play along, where does that leave 
Mozilla's users?  Looking for another browser perhaps..  Unless Mozilla 
feels it has too many users, I'd urge caution in that area.  As an 
absolute minimum a way to turn it off... even if it is buried deep in 
about:config (and you can't seriously expect us to believe that a 
required criterion for a setting being in there is that it can be 
understood by the majority of users).

Regards

Adrien

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 10 Jun 2008 13:32:03 +0100

Adrien de Croy wrote:
Allow some "safe" cross-site 
> enough about that to live with this solution?

I must admit, I don't see what's wrong with disabling cross-site
cookies entirely.

If two related domains want to transfer credentials, sessions etc.,
there are other mechanisms to do it.

> feels it has too many users, I'd urge caution in that area.

Perhaps the list should be used to implement a warning, easily
overridden per site, like the other cookie dialogs which Mozilla pops
up, rather than a hard block.

As a user I might prefer that.  I already like being able to say
"no thanks" to cookies on sites where I don't see any need.

-- Jamie

---

From: Florian Weimer <[email-masked]>
Date: Tue, 10 Jun 2008 21:05:56 +0200

> happy to accept co.zz cookies.

Right now, they're sharing that bit of information through one of
Google's web bug services.  Cross-domain cookies would at least provide
some level of transparency.

So this argument is a bit questionable.

> hand, open to suggestions about better ways to obtain it.

You need some sort of out-of-band service.  The information you are
looking for is not encoded in DNS.  Whether it's necessary to provide
automatic, non-code updates of the out-of-band data is a difficult
question.  However, this looks somewhat like the IP bogon prefixes list,
where hard-coding that ever-changing part into router configurations
turned out to be a big mistake.

For the DNS folks: The web security model requires that www.example.$TLD
and login.example.$TLD (where $TLD may contain multiple labels) can
share cookies (and probably HTTP requests, but I don't do that AJAX
stuff).  This must work by default, without explicit marking by the web
site operator, or tons of deployed applications will break.  At the same
time, it should not be possible to set cross-domain cookies (that is, a
cookie for login.example.$TLD by serving a HTTP request for
login.otherexample.$TLD).  Well-written web applications should be
immune to that, but lots of them apparently aren't.

This is the status quo.  Javascript is constantly enhanced with database
and stuff like that.  As a result, you aren't just protecting mere
cookies, but much more.  Obviously, this approach is not sound.  But
even with those later changes, some means to divine administrative
boundaries from DNS names are required for plain cookie management.

---

From: Florian Weimer <[email-masked]>
Date: Tue, 10 Jun 2008 21:18:41 +0200

> authoritative way to do so.

This is an bad idea because introducing a new zone at an existing name
should really, really be transparent to the rest of the world. (Thanks
to configuration options like (root-)delegation-only, this is already
not true to some extent, but there's no reason to repeat past mistakes.)

What's worse, bringing technical and administrative delegation into
agreement requires significant changes, which are unlikely to happen.
You need to take into account that this data is not just needed to make
new services secure on the surface, but also to deal with fairly old
protocol mishaps.

---

From: Florian Weimer <[email-masked]>
Date: Tue, 10 Jun 2008 21:22:27 +0200

* Stephane Bortzmeyer:

> for Internet Explorer.

Unfortunately, the need for this data doesn't go away if you don't talk
publicly about it.  It's a band-aid for extremely widespread protocol
misuse, and there's no way around it.  In other words, Internet Explorer
has got it's own list (and the operating system, too, for use in DNS
devolution).

---

From: Florian Weimer <[email-masked]>
Date: Tue, 10 Jun 2008 21:25:36 +0200

> use the hard-coded information you have gathered for that domain.

Isn't this the wrong direction, that is, should you start from the TLD?
(But don't forget to put that record into a separate zone. 8-P)

> cookie issues apply?

Yes.  I think Ebay suffers from these issues.

---

From: Florian Weimer <[email-masked]>
Date: Tue, 10 Jun 2008 21:39:01 +0200

* Stephane Bortzmeyer:

>  Andrew Sulli5Avan <[email-masked]> wrote 

Have a look at this file:

/usr/share/apps/khtml/domain_info

That's my last posting for today.  Sorry about the mail flood, I got
carried away a bit.

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 10 Jun 2008 22:43:50 +0200

> else has pointed out, makes it (in my opinion) doomed.

Not really. By proper design you can easily make cross-site cookies be
verifiable. Set out the goal that a site must indicate that cross-site
cookies is allowed for it to be accepted, and then work from there.
There is many paths how to get there, and the more delegated you make it
close to the owners and operators of the sites the better.

The big question is what that design should look like, but it's
certainly not a central repository with copies hardcoded into software.
It's also not likely DNS as DNS is hop-by-hop in the HTTP world and
cookie management is end-to-end.. (the user agent might not even have
DNS access)

Securing cookies by blacklisting is not the right approach for many
reasons, and should only be seen as a temporary patch along the path to
secure cookie management and at best input for a interim default policy
in the next step on the road to secure cross-site cookie management.
Blacklisting is not a very bad idea, but neither long term viable or
flexible enough to work out well. But on the positive site it's a small
step forward from what we have today and very unlikely to cause
problems. But on the bad side it hides the problem making it more likely
to bite unsuspecting owners of domains in public registries which for
some reason isn't in that list..

Delegated whitelisting is the only approach that has a reasonable chance
of working out well in the long run imho. There is so many public
registration points today, and it will significantly increase over time.
Preferably done at the HTTP level or at least using HTTP as transport,
and not relying on number of components stripped from the requested host
name and similar silly rules. It should be possible to set a cookie for
www.example.com and www.example.net in a single transaction.

Another alternative would be to finally rework the cookie system proper
addressing this and the many other shortcomings of the current cookie
system, Reworking the cookie system would be nice, but I don't see this
likely to happen until HTTP/2.0...

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 10 Jun 2008 22:45:52 +0200

> in DNS. And DNS is where it belongs, in the zone it relates to.

Some more brain cells fired in a later response and DNS is after all not
the proper location for this to work out in HTTP. See separate response.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 10 Jun 2008 22:52:42 +0200

On tis, 2008-06-10 at 21:05 +0200, Florian Weimer wrote:
> site operator, or tons of deployed applications will break. 

I seriously question this "will break" part. Sure, they will get
annoyed, but in nearly all possible solutions layering ontop of the
existing cookie system there will be easy ways for the owners of such
sites to make them behave well, and a transition period giving them
inciative and reasonable warning period to do so.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 10 Jun 2008 22:54:14 +0200

> Isn't this the wrong direction, that is, should you start from the TLD?

Not if done for the receiving site, but yes if done based on the site
setting the cookie..

Regards
Henrik

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 10 Jun 2008 23:31:00 +0200

On Tue, Jun 10, 2008 at 09:39:01PM +0200,
 Florian Weimer <[email-masked]> wrote 

> /usr/share/apps/khtml/domain_info

On my system (an up-to-date Ubuntu), it contains:

twoLevelTLD=name,ai,au,bd,bh,ck,eg,et,fk,il,in,kh,kr,mk,mt,na,np,nz,pg,pk,qa,sa,sb,sg,sv,ua,ug,uk,uy,vn,za,zw

I assume it is a list of TLD which register at the third level. If so,
it is questionable (.af, .dz, .fr register at the second and the
third level and I do not know how Konqueror handles it).
 
So, I got your point: other browsers have the same similar (and wrong)
policy. Bad news.

---

From: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 09:32:52 +0100

> Yes.  I think Ebay suffers from these issues.

Indeed. This is one of the reasons that livejournal switched from
www.livejournal.com/name to name.livejournal.com. It prevented rogue
code on user sites stealing the cookies of other users.

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 10:09:46 +0100

Jelte Jansen wrote:
> won't they run into the very same problem if only tld's (and their
> sld's) are marked as don't-set-cookies-here? Or is livejournal.com also
> supposed to get on the list of public suffixes?

No. They can set cookies for www.livejournal.com or
admin.livejournal.com (as opposed to livejournal.com), and these will
not be shared with name.livejournal.com.

This is somewhat of a red herring; the problem they had is one they
could fix using existing technology. It's not what the public suffix
list addresses.

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 10:10:04 +0100

Doug Barton wrote:
> Is it just me, or do those two statements seem to contradict one another?

I don't think so. Both are statements of truth.

If I had had time, I would have got this update mechanism sorted out
months ago. The fact that I didn't have time is not me saying that "I
don't want other people to have input into this process".

It's true that people saying "Please don't do anything like that" are
unlikely to be heeded. But that was just as true months ago as it is now.

> "We have already done 
> this, so if your data is accurate, fine. If not, you'll want to get 
> our list updated so that we may get it into the next version, whenever 
> that ships." 

Yep. In six to eight weeks, usually.

> The fact that your list seems to be missing some of the recent updates 
> to the IANA list does not fill me with hope.

I've added to my ToDo list an item to check that list against ours.
Although again I stress that just adding ".zz" to the list is the same
as having no entries, because it's just an explicit encoding of the
default behaviour.

> There's two problems with that statement. First, if I ran the JE 
> registry there's a pretty good chance that I'd be offended (not 
> speaking for them, just following your example). I don't know any TLD 
> operators who don't think that their domain has substantial 
> significance, even if it is "only" to their user community.

I didn't say anything about significance. It was merely a factual
statement about the number of websites. I don't have the ability to
determine how many sites there are in .je (I'm sure many people reading
this list do) but I'd wager it's four orders of magnitude less than the
number in .com, and at least two less than in .co.uk. And so ad-serving
companies are unlikely to be optimising their tracking systems to track
visitors across different sites in .com.je (even if that exists; I don't
know that it does). Perhaps I should continue to use ".xx" or ".zz" as
an example?

> The other, more important problem is that you're totally discounting 
> the possibility that the bad guys will simply move their websites to 
> TLDs that you don't have a policy for (or for whom your policy is too 
> permissive). 

I very much doubt that established businesses will change their domain
name just so they can track users more accurately. ("Welcome to
cnn.xx!") I think you overestimate the impact of this change.

> The audit trail for that is pretty interesting. First, I think it 
> would be useful for you to include a link to this discussion so that 
> your colleagues could read it for themselves. 
> http://www.ietf.org/mail-archive/web/dnsop/current/msg06100.html

Done; thank you.

> Second, the followup from Dave Townsend seems to indicate that at one 
> point in the past this data was being read from a file. Perhaps that 
> code could be resurrected?

To be entirely honest, I was under the impression that this was still
the case. I am looking into the question.

> Heh, if that's your criteria, then the options you have already would 
> be significantly reduced. :) 

There's always more work to do :-)

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 10:10:13 +0100

> inciative and reasonable warning period to do so.

Other list participants were warning about the possibility of people
abandoning Firefox in droves if there were cookie-related problems
caused by its use of public suffix list. You, on the other hand, are
suggesting that we can just make changes to the way cookies work and
expect broken sites to fix themselves. These seem to be two
irreconcilable views of the future.

Long history and experience has shown us that we can't just break
people's websites like that.

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 10:15:24 +0100

> /usr/share/apps/khtml/domain_info

Indeed. It looks like they do the same thing as us, but in a far more
approximate and erroneous fashion.

Persuading them to use the public suffix list would be an improvement.

Gerv

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 11 Jun 2008 11:41:43 +0200

On Tue, Jun 10, 2008 at 11:31:00PM +0200,
 Stephane Bortzmeyer <[email-masked]> wrote 

> third level and I do not know how Konqueror handles it).

Reported <http://bugs.kde.org/show_bug.cgi?id=163774>. Let's see if
Konqueror people react in the Mozilla way ("We decided and your
opinion does not matter")

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 11 Jun 2008 12:27:49 +0200

On Tue, Jun 10, 2008 at 09:22:27PM +0200,
 Florian Weimer <[email-masked]> wrote 
 a message of 10 lines which said:

> In other words, Internet Explorer has got it's own list (and the
> operating system, too, for use in DNS devolution).

According to this blog post, IE does it the other direction (SLD are
the rule and registration under the TLD the exception):

http://crisp.tweakblogs.net/blog/ie-and-2-letter-domain-names.html

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 11 Jun 2008 11:31:04 +0100

> not be shared with name.livejournal.com.

Oh?  How is this reconciled with earlier comments that
login.mybank.co.uk and accounts.mybank.co.uk are grouped together - or
is the Public Suffix List only for history grouping in browsers, not
for cookie sharing?

-- Jamie

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 11 Jun 2008 13:02:02 +0200

On ons, 2008-06-11 at 10:10 +0100, Gervase Markham wrote:

> caused by its use of public suffix list.

If you do this wronly yes.

> You, on the other hand, are

No. Neither users or sites are completely static in nature.

> people's websites like that.

Sites do break in upgrades. Problems arise if you break too many of them
and neither the site operators of users have an easy way around, or when
they do not understand why things broke. Fortunately the area we are
discussing is fundamentally broken by design, and sites do break today
differently in different browsers.

If you want something positive to come out of discussions like this you
have to have a little more open mind in looking where to find solutions.
There is at least 10 different solutions to the cookie domain problem,
of varying complexity and feasibility. Your proposed list is one, and
not a competely bad one, but very incomplete and too static to be
feasible as "the" solution to this problem. But it's a reasonable
interim step to patch things up while discussing how the actual problem
should be addressed.

In short the cookie problem is threefold:

a) Receivers of a cookie have no way of knowing who issued that cookie.

b) Receivers of cookies have no means of indicating who is allowed to
set cookies for them.

c) Issuers of cookies often want to issue a cookie to multiple domains
all of which is under their administrative control, but often have to
figth the very blunt domain based filters. As result we have many
designs using URL based transfer of the cookie details when moving from
one site to another when better operation would be seen if the cookie
could be managed as a single cookie valid for multiple sites. These "URL
based cookie tunnels" is often installed as a way around broken browser
cookie policies, and I would suspect they often create gaping security
issues from lacking awareness of why these policies even exists.

Regards
Henrik

---

From: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 13:13:18 +0100

> is the Public Suffix List only for history grouping in browsers, not

I'm not sure that either dnsop or ietf-http-wg are interested in a
discussion about the inner workings of cookies and Firefox's use of the
list. But briefly:

login.mybank.co.uk and accounts.mybank.co.uk can be grouped together
because we group by "public suffix + 1" - in this case, mybank.co.uk,
with the public suffix being .co.uk and so +1 being mybank.co.uk.
(Without the list, all .co.uk sites would be grouped together.)

Cookies are set for a particular domain or domain suffix, and are sent
to all sites with that domain suffix. So (under the current code)
www.mybank.co.uk can set cookies for either www.mybank.co.uk (shared
with foo.www.mybank.co.uk but not login.mybank.co.uk), mybank.co.uk
(shared with login.mybank.co.uk but not adserver.co.uk) or co.uk (shared
with adserver.co.uk but not with myorg.org.uk).

It is this latter use we want to prevent. We can do so by stopping
cookies being set for any domain which is a public suffix.

(Again, I comment that cookies are not the only way we are using this
information.)

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 13:45:28 +0100

Jeroen Massar wrote:
> If adserver.co.uk (as they are 'evil') sets a cookie for co.uk then
> indeed that cookie gets sent to mybank.co.uk too. What harm does/can
> this do? (Except that they might set a cookie identical of type to the
> bank one and maybe auto-login to their bank account!?)

<sigh>

Say adserver.co.uk has contracts with mybank.co.uk, mygrocer.co.uk,
mypetstore.co.uk to supply them with ads. adserver.co.uk can set the
ad-tracking cookie for .co.uk and build up a cross-site profile of a
particular user, perhaps augmented by information passed to them by one
or more of the sites concerned. This is a privacy issue. Therefore, they
should not be permitted to set such cookies. The only way to do that,
while continuing to allow foo.com to set cookies, is for the browser to
know the difference between co.uk and foo.com.

Gerv

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 11 Jun 2008 23:10:33 +1000

While this thread isn't necessarily off-topic for ietf-http-wg list,  
it's more relevant IMO to dnsop, and cross-posted high-volume  
discussions tend to be distracting.

So, please try to move discussion onto the dnsop list (I've set Reply- 
To accordingly).

Thanks,

--
Mark Nottingham     http://www.mnot.net/

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 11 Jun 2008 15:28:53 +0100

Gervase Markham wrote:
> under the current code ... www.mybank.co.uk can set cookies for
> ... co.uk (shared with adserver.co.uk but not with myorg.org.uk).
>

I'm not seeing how this is different from mybank.livejournal.com
setting cookies on livejournal.com which can be read by
adserver.livejournal.com.  livejournal.com needs to be on your Public
Suffix List to prevent that - if the content from subdomains can set
their own cookies.  Maybe not on Livejournal, but there are sites
where it's possible.

Even in mybank.co.uk, it's typical that login.mybank.co.uk and
thirdpartyinformation.mybank.co.uk will be somewhat independent.  The
latter should not be setting arbitrary cookies affecting the former,
imho - security, rather than privacy.

Regarding the "break the contract with adserver" argument, there are
plenty of ways for mybank.co.uk to pass tracking info to
adserver.co.uk by contract.  Banning cross-domain cookies in this case
just forces them to use another method.

> (Again, I comment that cookies are not the only way we are using this

I don't think anybody minds how you use the information to present
History dialogs and such.  Just whether it breaks applications that
come to depend on the structure of the list, and whether it adds
another barrier for site publishers who serve public content in a way
which resembles NICs.

-- Jamie

---

From: Florian Weimer <[email-masked]>
Date: Wed, 11 Jun 2008 22:16:03 +0200

* Gervase Markham:

> or more of the sites concerned. This is a privacy issue.

I'd love to see an official statement from the Mozilla Foundation that
cross-domain ad correlation is evil, and should be stopped by
technology.  Certainly this is not what you're trying to say here.

I guess the real issue is that by setting a cookie for co.uk, it's
possible to exploit session fixation vulnerabilities in web sites under
co.uk.  Unfortunately, the Public Suffix List web site is a bit unclear
in this regard.  It does not list a single protocol spec which requires
this sort of data.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 11 Jun 2008 13:55:02 -0700

Without speaking to the "evil" vs "not", see section 2.3.2.7 of the P3P 
Spec, in which we (over the lamentations of a certain unnamed vendor of 
deterministic consumer profiling data, now owned by a _major_ search 
engine service provider) required that linkages between cookies be 
disclosed in the cookie data collection policy.

I suspect the issue is disclosure, as there are market models which are 
based upon covert profiling using PII (information tending to identify 
uniquely an individual).

I'll update the draft Dan originally wrote (using PICS labels for the 
policy description language, for which I substituted a semantic subset 
with non-XML semantics and removed the digital signatures) and 
re-publish it an ID, with a note to the W3C's PLINK area people (the 
successors in interest to P3P). Its not the highest thing on my todo 
list, but as a namespace vendor there is some attraction in having a 
mechanism that allows better policing of cookies, independent of partial 
label matches.

As someone observed off-list, it doesn't have any apparent relationship 
to the problem and solution(s) suggested on the dnsop/http-wg lists, so 
I could be mistaken (again) about the necessity or sufficiency of 
policy+proof as payload for the http state management mechanism.

Eric