Subject: [DNSOP] 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,From [email-masked]  Mon Jun  9 03:00:58 2008
Date: Mon, 09 Jun 2008 11:00:39 +0100
From: Gervase Markham <[email-masked]>
To: [email-masked], [email-masked]
Subject: [DNSOP] Public Suffix List
Sender: [email-masked]

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

t, 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
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

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

[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 whenFrom [email-masked]  Mon Jun  9 04:33:45 2008
Date: Mon, 09 Jun 2008 13:34:11 +0200
From: Jeroen Massar <[email-masked]>
Organization: Unfix
To: Gervase Markham <[email-masked]>
OpenPGP: id33E7C23
Cc: [email-masked], [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)

[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 y 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 ;)

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

---

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

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

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

> Though, you will of course hit off on all the privacy folks when you are
> 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.

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

> 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: Gervase Markham <[email-masked]>
Date: Mon, 09 Jun 2008 12:48:19 +0100

Gerv

---

From: "Antoin Verschuren" <[email-masked]>
Date: Mon, 9 Jun 2008 14:02:05 +0200

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

---

From: "Antoin Verschuren" <[email-masked]>
Date: Mon, 9 Jun 2008 14:02:05 +0200

I must agree here.

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: bert hubert <[email-masked]>
Date: Mon, 9 Jun 2008 14:11:46 +0200

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

---

From: bert hubert <[email-masked]>
Date: Mon, 9 Jun 2008 14:11:46 +0200

Bert

---

From: "Antoin Verschuren" <[email-masked]>
Date: Mon, 9 Jun 2008 14:24:30 +0200

> -----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: "Antoin Verschuren" <[email-masked]>
Date: Mon, 9 Jun 2008 14:24:30 +0200

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, 9 Jun 2008 14:30:05 +0200

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: "Elmar K. Bins" <[email-masked]>
Date: Mon, 9 Jun 2008 14:30:05 +0200

Re Antoin,

Yours,
	Elmi.

--

---

From: Edward Lewis <[email-masked]>
Date: Mon, 9 Jun 2008 08:33:30 -0400

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

>You can't hijack something that does not exist though, which is what I think

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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 9 Jun 2008 08:33:30 -0400

---

From: bert hubert <[email-masked]>
Date: Mon, 9 Jun 2008 14:34:23 +0200

> 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: bert hubert <[email-masked]>
Date: Mon, 9 Jun 2008 14:34:23 +0200

Bert

---

From: bert hubert <[email-masked]>
Date: Mon, 9 Jun 2008 14:41:31 +0200

> 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

---

From: bert hubert <[email-masked]>
Date: Mon, 9 Jun 2008 14:41:31 +0200

Bert

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 9 Jun 2008 15:32:11 +0200

> contact for all TLDs. Yngve Pettersen at Opera suggested that I also  

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

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 9 Jun 2008 15:32:11 +0200

Patrik

---

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

> 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:41:31 +0100

Gerv

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 9 Jun 2008 15:56:01 +0200

> 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

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 9 Jun 2008 15:56:01 +0200

Patrik

---

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

---

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

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 09 Jun 2008 07:07:10 -0700

>>>>> On Mon, 09 Jun 2008 12:48:19 +0100, Gervase Markham <[email-masked]> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 09 Jun 2008 07:07:10 -0700

---

From: Edward Lewis <[email-masked]>
Date: Mon, 9 Jun 2008 10:17:36 -0400

>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 
scientifiFrom [email-masked]  Mon Jun  9 07:17:42 2008
Date: Mon, 9 Jun 2008 10:17:36 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Cc: Gervase Markham <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

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

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

---

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

Wes Hardaker wrote:
> 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:21:11 +0100

Gerv

---

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

> 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 s�&v{(��.�Ǭ��_���rn��;ێz�M<E�n�sڶg��[���zȞ��+�s���jT�v{(��܆+ޖ+-�'�~��
�b���u:"z�ڭ�]��)j�!������jk%r��yǢ��_���۽4�ZjXh��v�M5o'(��ښ�\�c������D�L���;p:�L�I�}���;ێzӽ4<4�:���v�N�g��\���jk%r��zX�z��N�g��\���jk%r��yǢ��_����ƥ��-���,�]��M[��+{v��W(��,����+a#>'x�������좗(��ښ�\�c(��n�m4�N��4�M
5Պ��IƧ��Z�������Z��\�eҥ����
9t�jd����뎗J��-�ޕt�jd�j۬6����뎭ju���}����*�w�^��X�=�@`D��n}��� "�4��m:0��@7D%C ��Ib�9mQyǢ��_���j)bz���׽=�}��ZjXh��(��ښ�\�mv�M5jf���g{
h��t�n0��DH�ωٱӓ�,�7��좗(��ښ�\�c(��n�m4�N�㝴�M
4^q�y��h޶l��'y�-��&��f��bq�����m}�m5�M9Ѽ����jk%r����_�"�13�wn8�]��.�~�ݞ�)��_���I�}���;ێ;ӽ4<4�yǢ��_����f����[�r���m��Mz���_vׯ5鼣zٲ��m欶�(����&��L���1�E -�� BHp7�Lb��t��J�"-�M:�=�2������M<ם�ӟ��Mz������=��N��M�8���+�6�x�'��n�m4�^v㝾�]4�&��jǌj�!jh����)ej��Rǫ��8n�׫n*��F�_]�M<ӝ;׃0E^�Ȩ�]�D��G&��l:F�G7G,;f�Z���~�n+ly�z��q�8���ӝ5ө��)ej���
8�P�0���@�]|��9A:�1;~�n+l{�8}�m7ӭ8���V��:`���n�@y���]�ߠwW롶�ǈ���$��6��6����5�m�p�~�n+lypei�jԩjd�����'��)��_��"z���p�
> 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 sugV6���fR�F�W�v�����WBW2���r����RF�BV&Ɩ77Vff����&r��"6��Wv�W&R��&R�ff�6��v���&V6��RF�R6��v�R6�W&6Rf�"F��2FFࠤvW'`������������������������������������������������D�4���Ɩ�rƗ7@�D�4��WFb��&p��GG3���wwr�WFb��&r�������Ɨ7F��f��F�6��h 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: Andrew Sullivan <[email-masked]>
Date: Mon, 9 Jun 2008 10:29:27 -0400

> ship in Firefox 3, but we'd like to verify and improve the quality of

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-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 9 Jun 2008 10:29:27 -0400

Best regards,
A

---

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

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

> 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 From [email-masked]  Mon Jun  9 07:37:51 2008
Date: Mon, 09 Jun 2008 16:38:05 +0200
To: "Wes Hardaker" <[email-masked]>, "Gervase Markham" <[email-masked]>
From: "Yngve Nysaeter Pettersen" <[email-masked]>
Organization: Opera Software
Cc: [email-masked], [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Reply-To: [email-masked]
Sender: [email-masked]

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

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

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

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

> subverted.  That's a problem with the cookies specification, which was

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.

> cookies. 

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

> being accepted, because the From [email-masked]  Mon Jun  9 07:43:47 2008
Date: Mon, 09 Jun 2008 15:43:29 +0100
From: Gervase Markham <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

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

Not that I know of.

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

> subverted.  That's a problem with the cookies specification, which was

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.

> cookies. 

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

> being accepted, because thtop 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

e 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: Andrew Sullivan <[email-masked]>
Date: Mon, 9 Jun 2008 11:40:02 -0400

> 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 behaviFrom [email-masked]  Mon Jun  9 08:39:49 2008
Date: Mon, 9 Jun 2008 11:40:02 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

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

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

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.

> 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

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

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

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.

> 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

---

From: David Conrad <[email-masked]>
Date: Mon, 9 Jun 2008 08:45:11 -0700

Gervase,

> 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

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.

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

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

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Mon, 9 Jun 2008 08:45:11 -0700

Gervase,

Regards,
-drc

---

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

Andrew Sullivan wrote:
> 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

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

> 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 From [email-masked]  Mon Jun  9 08:53:38 2008
Date: Mon, 09 Jun 2008 16:53:42 +0100
From: Gervase Markham <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

Andrew Sullivan wrote:
> 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

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

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

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?

> magical list of domains about which you'll have hard-coded

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

stem 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

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?

> magical list of domains about which you'll have hard-coded

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

---

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

> 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: Gervase Markham <[email-masked]>
Date: Mon, 09 Jun 2008 16:57:32 +0100

Gerv

---

From: David Conrad <[email-masked]>
Date: Mon, 9 Jun 2008 09:27:08 -0700

Gervase,

On Jun 9, 2008, at 8:57 AM, Gervase Markham wrote:
> 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

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

> Who says there's no vetting?

"Just by asking".

I gather I misunderstood.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Mon, 9 Jun 2008 09:27:08 -0700

Gervase,

"Just by asking".

Regards,
-drc

---

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

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

---

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

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 :-)

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

> 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: Gervase Markham <[email-masked]>
Date: Mon, 09 Jun 2008 17:34:16 +0100

Well, OK :-)

Gerv

---

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

-- Jamie

---

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

-- Jamie

---

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

_______________________________________________
DNSOP mailing list
DNSOP@ietfFrom [email-masked]  Mon Jun  9 09:37:15 2008
Date: Mon, 9 Jun 2008 17:36:59 +0100
From: Jamie Lokier <[email-masked]>
To: Gervase Markham <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

> 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

[email-masked]

tf.org

---

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: Gervase Markham <[email-masked]>
Date: Mon, 09 Jun 2008 17:50:03 +0100

Gerv

---

From: Brian Dickson <[email-masked]>
Date: Mon, 09 Jun 2008 12:57:00 -0400

> expect another solution to pop out of the woodwork now. But I'm open to

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

ButFrom [email-masked]  Mon Jun  9 09:56:52 2008
Date: Mon, 09 Jun 2008 12:57:00 -0400
From: Brian Dickson <[email-masked]>
To: Gervase Markham <[email-masked]>
Cc: [email-masked], David Conrad <[email-masked]>, [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

> expect another solution to pop out of the woodwork now. But I'm open to

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

, 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

---

From: Peter Koch <[email-masked]>
Date: Mon, 9 Jun 2008 19:42:55 +0200

Gervase,

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

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

---

From: Peter Koch <[email-masked]>
Date: Mon, 9 Jun 2008 19:42:55 +0200

Gervase,

-Peter {no hats}

---

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 From [email-masked]  Mon Jun  9 10:47:46 2008
Date: Mon, 09 Jun 2008 10:35:53 -0700
From: Eric Brunner-Williams <[email-masked]>
To: Gervase Markham <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

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 mamachine 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:
> the format of the list, and details for sending updates is at:
>

chine 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:
> the format of the list, and details for sending updates is at:
>

---

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:

> ...
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: Eric Brunner-Williams <[email-masked]>
Date: Mon, 09 Jun 2008 11:54:14 -0700

Gervase,

Eric

---

From: David Conrad <[email-masked]>
Date: Mon, 9 Jun 2008 11:56:05 -0700

Gervase,

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

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

---

From: David Conrad <[email-masked]>
Date: Mon, 9 Jun 2008 11:56:05 -0700

Gervase,

Regards,
-drc

---

From: Kim Davies <[email-masked]>
Date: Mon, 9 Jun 2008 12:09:09 -0700

> 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

---

From: Kim Davies <[email-masked]>
Date: Mon, 9 Jun 2008 12:09:09 -0700

kim

---

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
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinFrom [email-masked]  Mon Jun  9 12:31:03 2008
Date: Mon, 9 Jun 2008 12:31:13 -0700
To: Gervase Markham <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

>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

fo/dnsop

---

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 

> authoritative way to do so.

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:14:49 +0200

---

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

---

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

---

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

---

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

---

From: Joe Abley <[email-masked]>
Date: Mon, 9 Jun 2008 17:07:12 -0400

> authoritative way to do so.

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

---

From: Joe Abley <[email-masked]>
Date: Mon, 9 Jun 2008 17:07:12 -0400

Joe

---

From: Phil Regnauld <[email-masked]>
Date: Mon, 9 Jun 2008 23:07:23 +0200

> http://www.konqueror.org/

	Less radical...

	about:config in firefox

	search for IDN

	disable network.IDN.whitelist for all listed TLDs.

	Cheers,
	Phil

---

From: Phil Regnauld <[email-masked]>
Date: Mon, 9 Jun 2008 23:07:23 +0200

Less radical...

	about:config in firefox

	search for IDN

	Cheers,
	Phil

---

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

---

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

---

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 

> 	disable network.IDN.whitelist for all listed TLDs.

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

---

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

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 9 Jun 2008 17:42:16 -0400

> 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 oFrom [email-masked]  Mon Jun  9 14:42:03 2008
Date: Mon, 9 Jun 2008 17:42:16 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

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

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Jun 2008 16:53:01 -0500

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.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Jun 2008 16:53:01 -0500

---

From: Doug Barton <[email-masked]>
Date: Mon, 09 Jun 2008 15:02:35 -0700

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 a static
list that is built into the binary. Even assuming perfect uptake (which
we know won't happen) your update frequency cannot be high enough to
make this useful without annoying your users. And no matter how many
updates you make available, you will always have a substantial number (I
would expect a majority, but I could be wrong) of your users "stuck" at
an older version. For these reasons, and the others that have been
mentioned already, I encourage you to make the list dynamic so that
updates will happen for the user automatically in the background.

It should be fairly simple to do. Someone else already mentioned the
idea of piggybacking the check for this list with the browser update
check, which would substantially reduce the bandwidth needed. As long as
the frequency is no more than one week, that should suffice. I would
also suggest that if the user gets a hard fail for setting a cookie that
should trigger an update check, and reset the timer. How you implement
"dynamic" is an open question, but there are at least two obvious
answers in your complete control, https and dns(sec).

I would further suggest that this should be a user-configurable option.
Certainly it should be under some sort of "advanced" category, but I'm
concerned by the trend of less and less things being easily configured
by the user. That's not why I choose to use mozilla products. It's
always difficult balancing the user experience between advanced users
and those who want it to "just work." I hope you can find a middle way.

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. I have been using the CookieSafe extension for a long
time now (recently switched to CookieSafe Lite by the same author) and
it works great for me. If that functionality were included in the base
and enabled by default, it'd be a whole new world.
https://addons.mozilla.org/en-US/firefox/search?q=cookiesafe&cat=1%2C12

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.

Regards,

Doug

---

From: Doug Barton <[email-masked]>
Date: Mon, 09 Jun 2008 15:02:35 -0700

Yngve and Gerv,

Regards,

Doug

---

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

>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: Paul Hoffman <[email-masked]>
Date: Mon, 9 Jun 2008 16:51:02 -0700

--Paul Hoffman, Director
--VPN Consortium

---

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

On Mon, Jun 09, 2008 at 04:53:01PM -0500,
 Ted Lemon <[email-masked]> wrote 
 a message of 16 lines which said:

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

Your proposal solves *one* problem (the one well explained by Andrew
Sullivan), the difficulty of having an up-to-date list in the
installed browsers.
 
It leaves open the other problems:

* Difficulty of managing this list (and even worse if every browser
  vendor ask the TLD managers for a slightly different info)
* Administrative boundaries at lower levels (if we delegate under
  ".fr", it says nothing about x.example.fr and y.example.fr: are they
  in the same administrative domain?)
* Mozilla's methods of arm-twisting 
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsopFrom [email-masked]  Tue Jun 10 01:01:53 2008
Date: Tue, 10 Jun 2008 10:02:09 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: Ted Lemon <[email-masked]>
Organization: NIC France
Cc: [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

On Mon, Jun 09, 2008 at 04:53:01PM -0500,
 Ted Lemon <[email-masked]> wrote 
 a message of 16 lines which said:

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

Your proposal solves *one* problem (the one well explained by Andrew
Sullivan), the difficulty of having an up-to-date list in the
installed browsers.
 
It leaves open the other problems:

* Difficulty of managing this list (and even worse if every browser
  vendor ask the TLD managers for a slightly different info)
* Administrative boundaries at lower levels (if we delegate under
  ".fr", it says nothing about x.example.fr and y.example.fr: are they
  in the same administrative domain?)
* Mozilla's methods of arm-twisting 
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 10 Jun 2008 10:15:46 +0200

[three possible solutions below, thus keep on reading ;) ]

Stephane Bortzmeyer wrote:
>=From [email-masked]  Tue Jun 10 01:15:19 2008
Date: Tue, 10 Jun 2008 10:15:46 +0200
From: Jeroen Massar <[email-masked]>
Organization: Unfix
To: Stephane Bortzmeyer <[email-masked]>
OpenPGP: id33E7C23
Cc: [email-masked], Gervase Markham <[email-masked]>,
	Ted Lemon <[email-masked]>
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

[three possible solutions below, thus keep on reading ;) ]

Stephane Bortzmeyer wrote:
> 20
[..]

And of course the problem of privacy. Asking a mozilla.org or whatever 
remote domain not associated with the primary domain allows all 
mozilla.org (or whatever RBL domain is used) to see at least the domains 
I am locally using. This of course becomes funnier with local domains 
that are only on the Intranet. (Same goes for Email RBL's of course and 
using google and other search engines, every bit of information you 
disclose is a loss for your privacy, it all depends on what you like or 
not like)

As such, if one really wants to have these "LISTS" then let the Domain 
Admins publish them, as they know best. it is there domain after all.

(I) Thus, as I mentioned before, look at the SPF crowd: publish a TXT or 
most likely even better another special record which indicates what 
domains are associated with it, or actually you will want to describe 
which domains are NOT associated with it under that sublevel.

eg:

example.co.uk TXT "v=psl1 +example.co.uk -evil.example.co.uk-all"
example.org   TXT "v=psl1 +good.example.org -all"

(II) Then again, as others mentioned this is after all a HTTP issue, 
thus having a special HTTP header which encodes the above is already 
much better.

(III) Having that list in the cookie is of course another solution which 
solves the problem where it should be solved... and my vote would indeed 
be for the latter: better restrictions on cookie domains.

Yes, that does not resolve it 'directly' globally. But clearly the 
people using cookies don't care about it at the moment, otherwise they 
would be complaining and fixing the problem. If this new cookie 
mechanism is available though and people are made aware of it, they for 
sure are going to use it if they think it solves a part of their 
security issues.

Greets,
  Jeroen

---

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

---

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

---

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
_______________________________________________
DNSOP mailing list
[email-masked]
httpsFrom [email-masked]  Tue Jun 10 03:09:33 2008
Date: Tue, 10 Jun 2008 11:09:17 +0100
From: Jamie Lokier <[email-masked]>
To: Gervase Markham <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

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

/www.ietf.org/mailman/listinfo/dnsop

---

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

David Conrad wrote:
> to provide. 

We're about to ask them for their input.

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

> TLDs, expect quite a few bounces.  

OK - thanks.

Gerv

---

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

OK - thanks.

Gerv

---

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

>   vendor ask the TLD managers for a slightly different info)

We are making our data available for everyone to use, so we are trying
hard to make sure this doesn't happen.

>   in the same administrative domain?)

This problem exists today, so there is no difference between Firefox 2
and 3 on this question.

> * Mozilla's methods of arm-twisting 

We aren't twisting anyone's arm. We are making a request for help.

Gerv

---

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

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.

I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=438304 .

Gerv

---

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

Gerv

---

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

Kim Davies wrote:
> consultation. 

That's unfortunate; but I must say this upset was not communicated to me.

That policy of ours should have no effect whatsoever on TLDs with a
responsible attitude to homographs. Our registration requirements are
not onerous.

Gerv

---

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

Gerv

---

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

Hi Doug,

> 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

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

> 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 makFrom [email-masked]  Tue Jun 10 03:11:25 2008
Date: Tue, 10 Jun 2008 11:11:41 +0100
From: Gervase Markham <[email-masked]>
To: Doug Barton <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

Hi Doug,

> 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

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

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

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

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

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

> valuable. Please let me know if I can be of any further assistance.

Thanks :-)

Gerv

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

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

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

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

> 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:13:06 +0100

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, alFrom [email-masked]  Tue Jun 10 04:14:42 2008
Date: Tue, 10 Jun 2008 12:14:55 +0100
From: Jamie Lokier <[email-masked]>
To: Gervase Markham <[email-masked]>
Cc: [email-masked], David Conrad <[email-masked]>, [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

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

though 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: Jamie Lokier <[email-masked]>
Date: Tue, 10 Jun 2008 12:16:38 +0100

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

> 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

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

---

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

From what I can tell:

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: Jamie Lokier <[email-masked]>
Date: Tue, 10 Jun 2008 13:32:03 +0100

Adrien de Croy wrote:

-- Jamie

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 10 Jun 2008 09:19:06 -0700

>>>>> On Tue, 10 Jun 2008 11:10:32 +0100, Gervase Markham <[email-masked]> said:

>> * Mozilla's methods of arm-twisting 

GM> We aren't twisting anyone's arm. We are making a request for help.

Here's how you sound (with example quotes from your real text):

* We, mozilla, need to come up with a new administrative structure that
  encompasses every site out there and hard code it into a piece of
  software.

  "We are maintaining a list of all "Public Suffixes".

  "including a version of the list, is about to ship in Firefox 3"

* We, mozilla, obviously can't do this ourselves so you must do it for
  us or else negative things will happen (and you'll be at fault, not
  us, mozilla).  Please continue to do this work for us till the end of
  time.  Oh, and we need it immediately.

  "Any errors may either cause your customers (domain owners in your
  TLD) to not be able to set cookies when they should"

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

  "is about to ship in Firefox 3"

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

* We, mozilla, won't work on any other solution because we don't think
  it'll work or it'll take too much effort and we refuse to help out in
  those ventures even if they might be better.  Please stop talking
  about alternatives as we don't want your opinions on them.

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

You guys have done amazing work in the past, and will continue to do so
in the future I'm sure.  But the policy of "we're right; you're wrong;
please spend your energy the way we want" is not one that is going to go
over well.  Especially when it appears more people disagree with your
solution than agree with it.

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 10 Jun 2008 09:19:06 -0700

---

From: Dean Anderson <[email-masked]>
Date: Tue, 10 Jun 2008 12:26:01 -0400 (EDT)

> > introduce a hard-coded white-list of acceptable IDN TLDs without prior

Hard-coding something that dynamically changes is always a bad idea.  
While the notion of having a _dynamically_configured_ and
updateable/changeable list that mozilla uses might be OK, I'd hope that
it can be turned off by the user.

If Firefox is scheduled to ship with this serious flaw, I'd suggest that
maybe you might want to reconsider that schedule, and consider this a
show-stopper bug. Of course, one can always advise against using that
version of Firefox if it is shipped.  And if Mozilla.org insists on that
'flaw/feature', there is always the possibility of some group organizing
a new distribution without that 'flaw/feature'---this ability of change
is indeed a beautiful property of open source software. No one is locked
into what Mozilla.org decides.

> That's unfortunate; but I must say this upset was not communicated to me.

Probably that's because you are using SORBS to filter your email. SORBS
has an unusually high number of false positives, and for example,
falsely claims that that 130.105/16 and 198.3.136/21 are hijacked. You 
can find more information about SORBS on http://www.iadl.org/

> not onerousFrom [email-masked]  Tue Jun 10 09:27:31 2008
Date: Tue, 10 Jun 2008 12:26:01 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: Gervase Markham <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, David Conrad <[email-masked]>,
	"[email-masked]" <[email-masked]>
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

> > introduce a hard-coded white-list of acceptable IDN TLDs without prior

Hard-coding something that dynamically changes is always a bad idea.  
While the notion of having a _dynamically_configured_ and
updateable/changeable list that mozilla uses might be OK, I'd hope that
it can be turned off by the user.

If Firefox is scheduled to ship with this serious flaw, I'd suggest that
maybe you might want to reconsider that schedule, and consider this a
show-stopper bug. Of course, one can always advise against using that
version of Firefox if it is shipped.  And if Mozilla.org insists on that
'flaw/feature', there is always the possibility of some group organizing
a new distribution without that 'flaw/feature'---this ability of change
is indeed a beautiful property of open source software. No one is locked
into what Mozilla.org decides.

> That's unfortunate; but I must say this upset was not communicated to me.

Probably that's because you are using SORBS to filter your email. SORBS
has an unusually high number of false positives, and for example,
falsely claims that that 130.105/16 and 198.3.136/21 are hijacked. You 
can find more information about SORBS on http://www.iadl.org/

> responsible attitude to homographs. Our registration requirements are

??? This statement doesn't seem very credible. What authority do you
have to decide what a 'responsible attitude to homegraphs' would be?  
Mozilla.org doesn't represent the internet industry nor any government
or governing organization. Why should TLD's think they need to register
with Mozilla.org?  Since when did Mozilla.org take control of the
internet and the TLD responsibilities?  What legitimate governing body
decided what is responsible for TLD homographs? Adding questionable or
dubious blocking capabilities is one thing; Insisting on them by policy
is quite another.

		--Dean

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

.

??? This statement doesn't seem very credible. What authority do you
have to decide what a 'responsible attitude to homegraphs' would be?  
Mozilla.org doesn't represent the internet industry nor any government
or governing organization. Why should TLD's think they need to register
with Mozilla.org?  Since when did Mozilla.org take control of the
internet and the TLD responsibilities?  What legitimate governing body
decided what is responsible for TLD homographs? Adding questionable or
dubious blocking capabilities is one thing; Insisting on them by policy
is quite another.

		--Dean

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

---

From: David Conrad <[email-masked]>
Date: Tue, 10 Jun 2008 09:30:09 -0700

Gervase,

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

The concern I have isn't in collecting the data (others may feel  
differently), rather it is how you are proposing to distribute it (I  
have no comment on the use of the data because I don't understand the  
problem well enough).  The data you will be collecting will likely be  
out of data within a very short time after you cut a release and it  
requires you to re-release all the data every time there is an update,  
regardless of how small.  Presumably, you'll be batching up the list  
updates with other code updates, so the frequency of pushing out  
changes will likely be relatively low and thus, there will be periods  
when there is known bad data being used by every up-to-date  
implementation of Firefox.  Given the likely increase in the number of  
TLDs, this problem will only get worse over time.

Assuming there is an association of cookie trust policy with domain  
(which seems a bit of a reach to me, but again, I don't understand the  
problem well enough), then it would seem to me that a better way of  
proceeding would be as Jamie Lokier suggested (although I'd skip  
distributing the hard-coded list).  That is, probe for a policy  
statement for each level in the domain tree from the leaf up to the  
TLD.  As far as I can see, this would not introduce any additional  
privacy concerns and would resolve (pun intended) any data staleness  
issues.  It would also give zone administrators the ability to have  
fine grained control of cookie policy for names they administer.  Of  
course, the downside is the additional DNS lookups -- don't know how  
many lookups since I don't understand the problem well enough (but I  
have difficulty imagining the load would be that significant, all  
things considered).

FWIW.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 10 Jun 2008 09:30:09 -0700

Gervase,

FWIW.

Regards,
-drc

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Jun 2008 10:23:03 -0700

>responsible attitude to homographs. Our registration requirements are

For your IDN display technology, Mozilla decides which TLDs have a 
"responsible attitude". Mozilla enforces these rules as a "powerful 
incentive" for TLDs to do as Mozilla wishes. In doing so, Mozilla 
degrades the user experience of TLDs that don't go along with the 
Mozilla rules, such as .com/.net and ccTLDs throughout the world. The 
Mozilla "public suffix list" may prove to be similar.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Jun 2008 10:23:03 -0700

--Paul Hoffman, Director
--VPN Consortium

---

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 shoFrom [email-masked]  Tue Jun 10 12:05:44 2008
From: Florian Weimer <[email-masked]>
To: Gervase Markham <[email-masked]>
Date: Tue, 10 Jun 2008 21:05:56 +0200
Cc: [email-masked], [email-masked], Wes Hardaker <[email-masked]>
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

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

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

---

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

---

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

---

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

---

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

---

From: Mark Foster <[email-masked]>
Date: Tue, 10 Jun 2008 12:25:32 -0700

> So this argument is a bit questionable.
The problem is specific to HTTP cookies, not DNS or TLDs.
Mozilla (and anyone else who shares concern) should try to help fix the 
cookie SPEC (RFC 2107), not cook up ways to work-around it.

-- 
Some days it's just not worth chewing through the restraints...
Mark D. Foster, CISSP <[email-masked]>  http://mark.foster.cc/

---

From: Mark Foster <[email-masked]>
Date: Tue, 10 Jun 2008 12:25:32 -0700

---

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

---

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

---

From: Mark Foster <[email-masked]>
Date: Tue, 10 Jun 2008 12:25:45 -0700

---

From: Mark Foster <[email-masked]>
Date: Tue, 10 Jun 2008 12:25:45 -0700

---

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

---

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

---

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 theFrom [email-masked]  Tue Jun 10 13:43:42 2008
From: Henrik Nordstrom <[email-masked]>
To: Gervase Markham <[email-masked]>
Date: Tue, 10 Jun 2008 22:43:50 +0200
Cc: [email-masked], Jamie Lokier <[email-masked]>, [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

> 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
> 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:52:42 +0200

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: Henrik Nordstrom <[email-masked]>
Date: Tue, 10 Jun 2008 22:54:14 +0200

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

---

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

---

From: Doug Barton <[email-masked]>
Date: Tue, 10 Jun 2008 17:45:49 -0700

> /fait accompli/; I've just been too busy to get to it.

Is it just me, or do those two statements seem to contradict one another?

I would also like to point out that even if you sent the message you 
proposed to the admin and tech contacts of every TLD yesterday, you 
won't get a response from even a significant percentage of them before 
you ship. (That's not a pejorative statement, these are busy people.) 
So effectively what you'll be saying to them is, "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." I guarantee you, this will not be received well.

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

The fact that your list seems to be missing some of the recent updates 
to thFrom [email-masked]  Tue Jun 10 17:46:10 2008
Date: Tue, 10 Jun 2008 17:45:49 -0700
From: Doug Barton <[email-masked]>
To: Gervase Markham <[email-masked]>
OpenPGP: id=D5B2F0FB
Cc: [email-masked], [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

> /fait accompli/; I've just been too busy to get to it.

Is it just me, or do those two statements seem to contradict one another?

I would also like to point out that even if you sent the message you 
proposed to the admin and tech contacts of every TLD yesterday, you 
won't get a response from even a significant percentage of them before 
you ship. (That's not a pejorative statement, these are busy people.) 
So effectively what you'll be saying to them is, "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." I guarantee you, this will not be received well.

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

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

> public suffix data they submitted.

And what if they decide that it's not up to you to dictate how they 
set their cookie policy, and don't cooperate?

> yes, it would be doomed.

My impression is that you seem to think that having domains not on the 
list treated differently from domains on the list is Ok. I'm pretty 
sure most of us would disagree with you on that, but since you seem 
determined to press forward (and the value of what you're doing may 
outweigh that issue, not sure) then that's something that we'll have 
to live with.

The case that I don't think you're giving enough weight to is the one 
where you have published code that says, "You cannot set cookies for 
SLD.TLD, only SLD.$foo.TLD" and the registry changes their policy. Now 
every single domain that registers at the second level in that TLD 
will not be able to set cookies for their domain that your browser 
will permit. (Unless I've dramatically misunderstood the concept.) As 
both a user and as someone who deals with web sites, cookies, and 
domains on the administrative level, I regard that as a pretty serious 
problem. Several people have told you that this exact problem (or 
related problems) WILL be happening now, and WILL be happening with 
more frequency as time goes on.

> (That's why I think a model of getting the TLDs
> deduction to make a good guess - or just not give them an entry. There

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.

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). Given the fairly open registration policies at most TLDs 
I'd say that's a non-trivial issue. And since the data will be hard 
coded the bad guys will know what's there, and have a fairly well 
defined period of time in which to operate.

> Yngve probably knows more about this than me, though.

I'd love to see some references that define the scope of this problem. 
I'd also like to see some discussion of how large this problem is vs. 
the issue that someone else raised that there are other ways that 
theoretically bad actors can (and already do) use to share cookie 
data. (Hint: I would lay significthe IANA list does not fill me with hope.

> public suffix data they submitted.

And what if they decide that it's not up to you to dictate how they 
set their cookie policy, and don't cooperate?

> yes, it would be doomed.

My impression is that you seem to think that having domains not on the 
list treated differently from domains on the list is Ok. I'm pretty 
sure most of us would disagree with you on that, but since you seem 
determined to press forward (and the value of what you're doing may 
outweigh that issue, not sure) then that's something that we'll have 
to live with.

The case that I don't think you're giving enough weight to is the one 
where you have published code that says, "You cannot set cookies for 
SLD.TLD, only SLD.$foo.TLD" and the registry changes their policy. Now 
every single domain that registers at the second level in that TLD 
will not be able to set cookies for their domain that your browser 
will permit. (Unless I've dramatically misunderstood the concept.) As 
both a user and as someone who deals with web sites, cookies, and 
domains on the administrative level, I regard that as a pretty serious 
problem. Several people have told you that this exact problem (or 
related problems) WILL be happening now, and WILL be happening with 
more frequency as time goes on.

> (That's why I think a model of getting the TLDs
> deduction to make a good guess - or just not give them an entry. There

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.

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). Given the fairly open registration policies at most TLDs 
I'd say that's a non-trivial issue. And since the data will be hard 
coded the bad guys will know what's there, and have a fairly well 
defined period of time in which to operate.

> Yngve probably knows more about this than me, though.

I'd love to see some references that define the scope of this problem. 
I'd also like to see some discussion of how large this problem is vs. 
the issue that someone else raised that there are other ways that 
theoretically bad actors can (and already do) use to share cookie 
data. (Hint: I would lay signifant money down on a bet that there is 
already way more cross-site tracking done now affecting way more 
users, way more sites, and way more data than this cookie policy could 
ever hope to solve. Hint hint: It's a sucker bet, I already know the 
answer.)

> I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=438304 .

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

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?

Finally, there is a middle ground here. Ship what you have (since that 
seems inevitable), but disable the cookie policy portion of the code 
by default. Make it an about:config option so that those who want to 
try this feature (and are knowledgeable enough to judge the results) 
can do so, but don't enable it by default until you can get the list 
dynamically updated.

> of your users will be able to understand.

Heh, if that's your criteria, then the options you have already would 
be significantly reduced. :) Seriously though, my suggestion was to 
hide this on the Advanced page, which sounds reasonable to me, but 
it's your ball game. I do hope that there will be a config option for 
it at least (ala IDN?).

> is "safe" or not.

Yeah, that's why I didn't suggest making this a warning. Users would 
blow past it just like they blow past SSL warnings now.

> In one sense, they are all safe. You won't lose any

The CookieSafe plugin uses domain granularity by default, which is 
good enough for me. As for "safety," those of us for whom privacy is a 
concern would disagree with your assertion. But we can leave that bit 
aside, neither of us will be changing our minds. :)

>> valuable. Please let me know if I can be of any further assistance.

Whether we ultimately reach the same conclusions or not, it's obvious 
to me that you've been giving the discussion some thought, and for 
that I thank you as well.

Doug

icant money down on a bet that there is 
already way more cross-site tracking done now affecting way more 
users, way more sites, and way more data than this cookie policy could 
ever hope to solve. Hint hint: It's a sucker bet, I already know the 
answer.)

> I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=438304 .

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

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?

Finally, there is a middle ground here. Ship what you have (since that 
seems inevitable), but disable the cookie policy portion of the code 
by default. Make it an about:config option so that those who want to 
try this feature (and are knowledgeable enough to judge the results) 
can do so, but don't enable it by default until you can get the list 
dynamically updated.

> of your users will be able to understand.

Heh, if that's your criteria, then the options you have already would 
be significantly reduced. :) Seriously though, my suggestion was to 
hide this on the Advanced page, which sounds reasonable to me, but 
it's your ball game. I do hope that there will be a config option for 
it at least (ala IDN?).

> is "safe" or not.

Yeah, that's why I didn't suggest making this a warning. Users would 
blow past it just like they blow past SSL warnings now.

> In one sense, they are all safe. You won't lose any

The CookieSafe plugin uses domain granularity by default, which is 
good enough for me. As for "safety," those of us for whom privacy is a 
concern would disagree with your assertion. But we can leave that bit 
aside, neither of us will be changing our minds. :)

>> valuable. Please let me know if I can be of any further assistance.

Whether we ultimately reach the same conclusions or not, it's obvious 
to me that you've been giving the discussion some thought, and for 
that I thank you as well.

Doug

---

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 09:32:52 +0100

Gerv

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 11 Jun 2008 10:40:51 +0200

> code on user sites stealing the cookies of other users.

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?

And will they care? (well, livejournal might, but i could imagine some
others not to care enough to get themselves on it)

Jelte
_______________________________________________
DNSOP mailing list
DNSOP@ieFrom [email-masked]  Wed Jun 11 01:40:56 2008
Date: Wed, 11 Jun 2008 10:40:51 +0200
From: Jelte Jansen <[email-masked]>
To: Gervase Markham <[email-masked]>
Cc: [email-masked], Jamie Lokier <[email-masked]>,
	David Conrad <[email-masked]>, [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

> code on user sites stealing the cookies of other users.

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?

And will they care? (well, livejournal might, but i could imagine some
others not to care enough to get themselves on it)

Jelte
[email-masked]

.org

---

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

> 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:09:46 +0100

Gerv

---

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

> 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 
> that ships." 

Yep. In six to eight weeks, usually.

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

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

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

> http://www.ietf.org/mail-archive/web/dnsop/current/msg06100.html

Done; thank you.

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

> be significantly reduced. :) 

There's always more work to do :-)

Gerv

---

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

Done; thank you.

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:10:13 +0100

Gerv

---

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

Paul Hoffman wrote:
> incentive" for TLDs to do as Mozilla wishes. 

As are Microsoft's rules - which, sadly, are both different and IMO much
more likely to retard the growth of IDN. But that's another discussion.

> In doing so, Mozilla

The difference is that the public suffix list is an (attempt at an)
expression of fact, not policy. If you are concerned that we will
withhold changes or issue known-incorrect lists in order to conduct some
sort of vendetta against a particular TLD, all I can say is "why on
earth would we do that?"

Gerv

---

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

Gerv

---

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

> can find more information about SORBS on http://www.iadl.org/

No-one can have control over and knowledge of everything their ISP does
with relation to the services they provide. I confess I've only ever
vaguely heard the name SORBS, and had no idea that my provider was using
it. But I don't believe that using it makes me uncontactable. My phone
number and address are on my personal web page.

I can hardly imagine some TLD administrator saying "I'm so irritated
about Firefox's TLD IDN whitelist. I'm going to send Gerv a nasty email.
Hang on, my email's been rejected. Oh well, I guess I'll just have to
live with it."

> have to decide what a 'responsible attitude to homegraphs' would be?  

What's your answer to that question? (Hint: the answer "no-one" is
equivalent to the answer "the registries", which has been shown not to
work. See http://www.shmoo.com/idn/ .)

> or governing organization. 

No, we represent our users, and we make all sorts of security decisions
for them on a regular basis. One of the reasons Firefox is popular is
precisely because it doesn't wimp out of security decisions with
user-irritating popup questions they have no information to answer. But,
as someone else has said, if people don't like the decisions we make,
they can either become part of "we" and seek to change them, or they can
change or build their copy, or can distribute an alternative browser.

> Why should TLD's think they need to register
> with Mozilla.org? 

They don't have to. Why should TLDs think they have an automatic right
to have Firefox display domains they have issued which allow our users
to be fooled or defrauded?

Gerv

---

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

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: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 10:15:24 +0100

Gerv

---

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

On Wed, Jun 11, 2008 at 10:15:19AM +0100,
 Gervase Markham <[email-masked]> wrote 
 a message of 53 lines which said:

> Why should TLDs think they have an automatic right to have Firefox
> display domains they have issued which allow our users to be fooled
> or defrauded?

Interesting. It reminds me of the RIR which assign IP addresses
prefixes without being able to guarantee they will be routed.

I always assumed that the poor domain name registrant had only to
fight with the rules of the registrar/registry/ICANN/governement to
get his domain registered and used everywhere in the world. Now, I see
that besides registration rules (sometimes painful, see
<http://www.afnic.fr/obtenir/chartes_en>), registrants also have to
go through the filter of browser authors.

---

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

---

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

---

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

---

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

---

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

---

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: Jamie Lokier <[email-masked]>
Date: Wed, 11 Jun 2008 11:31:04 +0100

-- 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 weFrom [email-masked]  Wed Jun 11 04:03:10 2008
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 bsites 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 12:26:42 +0100

Wes Hardaker wrote:
> * We, mozilla, obviously can't do this ourselves

On the contrary. We have done it for ourselves.

>   so you must do it for

We don't need it immediately. The first Firefox 3 security release will
probably be in six to eight weeks.

>   about alternatives as we don't want your opinions on them.

It's not true that we won't work on any other solution. This is what we
have now, and there have been no alternative proposals which (to my
mind) look like producing anything workable in the short term.

Half this list seems to think that getting all the TLDs to agree on or
do anything is an enterprise doomed tFrom [email-masked]  Wed Jun 11 04:26:31 2008
Date: Wed, 11 Jun 2008 12:26:42 +0100
From: Gervase Markham <[email-masked]>
To: Wes Hardaker <[email-masked]>
Cc: [email-masked], Ted Lemon <[email-masked]>
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

Wes Hardaker wrote:
> * We, mozilla, obviously can't do this ourselves

On the contrary. We have done it for ourselves.

>   so you must do it for

We don't need it immediately. The first Firefox 3 security release will
probably be in six to eight weeks.

>   about alternatives as we don't want your opinions on them.

It's not true that we won't work on any other solution. This is what we
have now, and there have been no alternative proposals which (to my
mind) look like producing anything workable in the short term.

Half this list seems to think that getting all the TLDs to agree on or
do anything is an enterprise doomed to failure, and the other half seem
to think that we should be waiting for all the TLD operators to agree to
set up their own repositories of the data. There is a contradiction there.

Gerv

o failure, and the other half seem
to think that we should be waiting for all the TLD operators to agree to
set up their own repositories of the data. There is a contradiction there.

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 12:25:23 +0100

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 12:25:23 +0100

Gerv

---

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.From [email-masked]  Wed Jun 11 05:13:08 2008
Date: Wed, 11 Jun 2008 13:13:18 +0100
From: Gervase Markham <[email-masked]>
To: Jamie Lokier <[email-masked]>
Cc: [email-masked], David Conrad <[email-masked]>, [email-masked],
	Jelte Jansen <[email-masked]>
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

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

(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: Jeroen Massar <[email-masked]>
Date: Wed, 11 Jun 2008 14:22:27 +0200

Gervase Markham wrote:
[..]
> with foo.www.mybank.co.uk but not loginFrom [email-masked]  Wed Jun 11 05:21:53 2008
Date: Wed, 11 Jun 2008 14:22:27 +0200
From: Jeroen Massar <[email-masked]>
Organization: Unfix
To: Gervase Markham <[email-masked]>
OpenPGP: id33E7C23
Cc: [email-masked], Jelte Jansen <[email-masked]>,
	Jamie Lokier <[email-masked]>,
	David Conrad <[email-masked]>, [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

Gervase Markham wrote:
[..]
> with foo.www.mybank.co.uk but not log.mybank.co.uk), mybank.co.uk

With the real fix here simply being that mybank.co.uk only sets a cookie 
for mybank.co.uk and not for co.uk. The is thus a problem of the bank 
being stupid to set a cookie for co.uk.

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

Do you have an example where you actually need that Public Suffix List?

Greets,
  Jeroen

---

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

> 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: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 13:45:28 +0100

<sigh>

Gerv

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 11 Jun 2008 15:10:19 +0200

> know the difference between co.uk and foo.com.

Thus you are going to break the contract that mybank.co.uk has with 
adserver.co.uk? wow, now you are really getting into something...

That privacy issue is not a privacy issue, that is an issue with the 
bank in question which is compromising the privacy of its users. Solve 
the problem at the bank.

Greets,
  Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 11 Jun 2008 15:10:19 +0200

Greets,
  Jeroen

---

From: "Joe Baptista" <[email-masked]>
Date: Wed, 11 Jun 2008 09:10:18 -0400

Gerv:

I asked you a question earlier in this conversation but have yet to get a
response.  So I will ask it again.

What happens if a TLD is not on the Public Suffix list?

regards
joe baptista

-- 
Joe Baptista
www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.
----------------------------------------------------------------
Office: +1 (360) 526-6077 (extension 052)
Fax: +1 (509) 479-0084
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Joe Baptista" <[email-masked]>
Date: Wed, 11 Jun 2008 09:10:18 -0400

Gerv:

regards
joe baptista

---

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: Mark Nottingham <[email-masked]>
Date: Wed, 11 Jun 2008 23:10:33 +1000

Thanks,

---

From: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 14:23:02 +0100

Joe Baptista wrote:
> I asked you a question earlier in this conversation but have yet to get
> a response.  So I will ask it again.

You asked me by private mail, and I replied in private at 10/06/08 10:47
my time.

> What happens if a TLD is not on the Public Suffix list?

The same thing as now. It's treated as if (again, using cookies as an
example) cookies can be set all the way down to, but not including, ".xx".

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 14:23:02 +0100

Gerv

---

From: Edward Lewis <[email-masked]>
Date: Wed, 11 Jun 2008 10:15:01 -0400

>So, please try to move discussion onto the dnsop list (I've set Reply-

Odd to see this, I was about to say "what does this have to do with 
DNS operations?" and suggest that it move back to the HTTP group. 
Cookies aren't part of the DNS protocol.

Is the issue that a cookie needs to state for what domains it is 
valid?  Are you trying to relate domain names to a registrant? 
That's not a DNS issue, that's a WhoIs/IRIS issue, if you want to pin 
that into a protocol.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 11 Jun 2008 10:15:01 -0400

---

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 casFrom [email-masked]  Wed Jun 11 07:28:41 2008
Date: Wed, 11 Jun 2008 15:28:53 +0100
From: Jamie Lokier <[email-masked]>
To: Gervase Markham <[email-masked]>
Cc: [email-masked], David Conrad <[email-masked]>, [email-masked],
	Jelte Jansen <[email-masked]>
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

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

ase
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: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 16:18:34 +0100

Edward Lewis wrote:
> valid?  

No.

> Are you trying to relate domain names to a registrant? 

No.

I must confess it is somewhat frustrating when, having put up a website
explaining what this is all about, and having had a long discussion on
this list, people continually misunderstand the point while having shown
no evidence of attempting to read the existing explanations.

I even got one (private) mail basically saying "I can't be bothered to
read all that. Tell me, what are you trying to do?"

http://publicsuffix/learn/ has more info (and I've just checked in
another update, which should be visible in the next day or so. There's a
human in the update loop).

Gerv
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailmFrom [email-masked]  Wed Jun 11 08:18:26 2008
Date: Wed, 11 Jun 2008 16:18:34 +0100
From: Gervase Markham <[email-masked]>
To: Edward Lewis <[email-masked]>
Cc: [email-masked]
Subject: Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
Sender: [email-masked]

Edward Lewis wrote:
> valid?  

No.

> Are you trying to relate domain names to a registrant? 

No.

I must confess it is somewhat frustrating when, having put up a website
explaining what this is all about, and having had a long discussion on
this list, people continually misunderstand the point while having shown
no evidence of attempting to read the existing explanations.

I even got one (private) mail basically saying "I can't be bothered to
read all that. Tell me, what are you trying to do?"

http://publicsuffix/learn/ has more info (and I've just checked in
another update, which should be visible in the next day or so. There's a
human in the update loop).

Gerv
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailmanan/listinfo/dnsop

/listinfo/dnsop

---

From: [email-masked]
Date: Wed, 11 Jun 2008 15:31:30 +0000

> human in the update loop).

	that URL does not resolve in the way you might
	expect.

--bill

---

From: [email-masked]
Date: Wed, 11 Jun 2008 15:31:30 +0000

--bill

---

From: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 16:36:40 +0100

> 	that URL does not resolve in the way you might

Sorry :-) Cut and pasted from my browser without checking. That's my
local testing copy, of course.

http://www.publicsuffix.org/learn/

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 16:36:40 +0100

Gerv

---

From: "Joe Baptista" <[email-masked]>
Date: Wed, 11 Jun 2008 12:06:17 -0400

> read all that. Tell me, what are you trying to do?"

Listening would you mind explaining something here.  Do we work for you?
I'm pretty sure your being paid to promote your public suffix idea but we
are not.  There are many here who are too busy to spend time reading your
stuff, let alone go back to the web site for updates.

Now if you want to start paying for my time and the time of the group -
we'll gladly work for you.

Now Gerv focus.  You have come here for a reason and that is to promote a
protocol.  The people ere are giving very good advice.  It would be prudent
you pay attention and answer their questions.  Obviously this process is
having some benefit because it is forcing you to update your web site.

Gerv focus.  Kindly remember your position in his affair.  You are here on
behalf Mozilla to sell an idea and we are the people who have to be sold.
And it is in bad form for a salesman to complain.  You goal is to provide us
with the best customer service on behalf of Mozilla.  And if that means
going the extra mile - then go the extra mile.  Don't complain - that looks
bad.

A lot of people here are well known experts in their fields who are taking
the time to ask you questions.  You got to respect that and in turn respect
their time constraints.

Incidentally - have you answered by question yet - or put it on the web
site?  What happens to your web browsers behavior if I try to surf a TLD not
on the list?

cheers
joe baptista

---

From: "Joe Baptista" <[email-masked]>
Date: Wed, 11 Jun 2008 12:06:17 -0400

cheers
joe baptista

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Jun 2008 11:15:24 -0500

> mind) look like producing anything workable in the short term.

Putting the list in the DNS instead of in the browser isn't  
workable?   Serious question.   I think several proposals have been  
advanced here that /could/ work.   Mine has the virtue of being  
completely under your control.   The other one, where subdomains are  
called out in the zones of the domains that contain them, is not under  
your control, and wouldn't be a good interim solution, but sounds like  
a good long-term solution because it puts correctness in the hands of  
the people who suffer or benefit from it.

So what I would personally like to see here is a staged transition.    
In the first stage, mozilla.org would set up a TLD list in its own DNS  
space, or in some new subdomain they register with good anycast  
replication so that no individual server has to bear the entire  
load.   This list would be maintained by mozilla.org, using  
information from registries and domain owners, and also using your  
current ad-hoc system.

But you'd also implement the system that was proposed here where the  
registries themselves can publish this information in their own  
domains.   And over time, the hope would be that the number of TLDs  
you'd have to maintain in your list would slowly dwindle, to the point  
where it would become more of a quirks list than a registry of its  
own.  This could work because the incentives are in the right  
direction - sites that have problems with your ad-hoc registry can  
either contact you or fix their own DNS, and fixing their own DNS may  
well be easier.

I haven't heard you responding that either of these solutions wouldn't  
work, so I'm assuming they would, but perhaps I'm wrong.   It also may  
be the case that for reasons of practicality you need to start with a  
list embedded in the browser; as long as you have a plan to make the  
transition to a list that's maintained more dynamically, and as long  
as you actually execute that plan, it seems to me that this is harmless.

BTW, thanks for your reasoned responses to all these questions and  
accusations being thrown at you.   You seem to have really elicited a  
lot of energetic response with your initial request, and I hope that  
something good will come of it.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Jun 2008 11:15:24 -0500

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Jun 2008 11:22:23 -0500

On Jun 11, 2008, at 11:06 AM, Joe Baptista wrote:
> Listening would you mind explaining something here.  Do we work for  
> you?  I'm pretty sure your being paid to promote your public suffix  
> idea but we are not.  There are many here who are too busy to spend  
> time reading your stuff, let alone go back to the web site for  
> updates.

Joe, the problem description on the web site contains five paragraphs,  
two of which are a single sentence.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Jun 2008 11:22:23 -0500

---

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

Joe Baptista wrote:
> you?  I'm pretty sure your being paid to promote your public suffix idea
> but we are not.  There are many here who are too busy to spend time
> reading your stuff, let alone go back to the web site for updates.

That's fine. But please don't ask me questions about it then.

- "I don't have time to understand this." - Fine.

- "I do have time to understand this. Here is an intelligent question."
  - Fine.

- "I don't have time to understand this so I'm going to ask uninformed
  questions." - Not fine. Not just here, but in any walk of life where
  people respect other people's time.

> Now Gerv focus.  You have come here for a reason and that is to promote
> a protocol.

No. I came here because Yngve suggested that the membership of this list
would appreciate a heads-up.

> Gerv focus.  Kindly remember your position in his affair.  You are here
> on behalf Mozilla to sell an idea and we are the people who have to be
> sold. 

No. I don't need to sell you the idea. The idea doesn't stand or fall on
the opinion of this mailing list.

> site?  What happens to your web browsers behavior if I try to surf a TLD
> not on the list?

I've answered it once to you privately and once to the list. Third time:
"the same thing as now".

Gerv

---

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

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 17:21:29 +0100

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 17:21:29 +0100

Gerv

---

From: Brian Dickson <[email-masked]>
Date: Wed, 11 Jun 2008 12:32:51 -0400

Gervase Markham wrote:
> expression of fact, not policy.

I think is where you are encountering resistance, even though you may 
not realize it.

What you are doing is *publishing* something, which alleges to be a 
factual list.

Who is on it, who is not on it, and who uses it and how, matter a great 
deal.

If the list is 100% complete and 100% accurate and 100% timely, there 
are no problems.
Any deviation from that situation, regardless of how much and in what 
manner the deviation occurs,
puts the publisher of alleged facts at risk.

And relying on authoritative sources to push data to you, is a reverse 
onus that hundreds of years of case
law quite likely present a formidable obstacle, if it becomes necessary 
to defend your choice.

Here's a concrete analogy that may be suitable for demonstrating the issue.

Imagine a magazine dedicated to "Tires". It publishes an article on 
"Tire Safety".
It contains a list of "Tires (manufacturer/model) safe to use at 180 km/h".
Is the list accurate? Timely? Complete?

If a reader bases a safety decision (buys tires, drives 180 km/h) that 
goes badly, then what?

What about recalls?

Also: Publishing a list may be even *riskier* than publishing a single, 
but erroneous, "fact".

E.g. what about manufacturers not listed?
They have been implicitly or even explicitly defamed, even if you 
include a footnote to the effect that "this list is not complete".
> IFrom [email-masked]  Wed Jun 11 09:32:37 2008
Date: Wed, 11 Jun 2008 12:32:51 -0400
From: Brian Dickson <[email-masked]>
To: Gervase Markham <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

Gervase Markham wrote:
> expression of fact, not policy.

I think is where you are encountering resistance, even though you may 
not realize it.

What you are doing is *publishing* something, which alleges to be a 
factual list.

Who is on it, who is not on it, and who uses it and how, matter a great 
deal.

If the list is 100% complete and 100% accurate and 100% timely, there 
are no problems.
Any deviation from that situation, regardless of how much and in what 
manner the deviation occurs,
puts the publisher of alleged facts at risk.

And relying on authoritative sources to push data to you, is a reverse 
onus that hundreds of years of case
law quite likely present a formidable obstacle, if it becomes necessary 
to defend your choice.

Here's a concrete analogy that may be suitable for demonstrating the issue.

Imagine a magazine dedicated to "Tires". It publishes an article on 
"Tire Safety".
It contains a list of "Tires (manufacturer/model) safe to use at 180 km/h".
Is the list accurate? Timely? Complete?

If a reader bases a safety decision (buys tires, drives 180 km/h) that 
goes badly, then what?

What about recalls?

Also: Publishing a list may be even *riskier* than publishing a single, 
but erroneous, "fact".

E.g. what about manufacturers not listed?
They have been implicitly or even explicitly defamed, even if you 
include a footnote to the effect that "this list is not complete".
>f you are concerned that we will

No malice is needed on your part, for publishing a list to cause 
problems, esp. for you and the publisher (Mozilla).
I think you might not have considered that, yet.

Conclusion:

Regardless of the benign intent of the list, publishing it means needing 
to keep it timely, accurate,
and complete, and that is why the notion of updates based on volunteered 
data from registries,
updated only when software updates are performed, is a particularly bad 
idea.

I happen to think that the idea of maintaining such a list is probably 
not a bad idea itself.

It is the means by which the list is built, and distributed, that are of 
great concern.

Brian

 If you are concerned that we will
> sort of vendetta against a particular TLD, all I can say is "why on

No malice is needed on your part, for publishing a list to cause 
problems, esp. for you and the publisher (Mozilla).
I think you might not have considered that, yet.

Conclusion:

Regardless of the benign intent of the list, publishing it means needing 
to keep it timely, accurate,
and complete, and that is why the notion of updates based on volunteered 
data from registries,
updated only when software updates are performed, is a particularly bad 
idea.

I happen to think that the idea of maintaining such a list is probably 
not a bad idea itself.

It is the means by which the list is built, and distributed, that are of 
great concern.

Brian

---

From: "Joe Baptista" <[email-masked]>
Date: Wed, 11 Jun 2008 12:35:28 -0400

> I've answered it once to you privately and once to the list. Third time:

We must be having email issues.  Because I have neither received a private
email from you that I can find.  Will check my spam folder in case it ended
up there.  And I have not seen a response to my question on the list.  Its
been pretty busy here since you dropped this little bomb that has gotten us
so excited.

So please help me out here, I didn't get that answer.  So what is the answer
to the question ??? What happens to your web browsers behavior if I try to
surf a TLD not on the list?

Thanks in advance for your answer.
Joe Baptista

---

From: "Joe Baptista" <[email-masked]>
Date: Wed, 11 Jun 2008 12:35:28 -0400

---

From: David Conrad <[email-masked]>
Date: Wed, 11 Jun 2008 10:08:18 -0700

Gervase,

> mind) look like producing anything workable in the short term.

I guess it depends on what you mean by 'workable'.

> set up their own repositories of the data. There is a contradiction  

While I might agree that it is unlikely you'll get all the TLDs to  
agree on or do anything (they are a wildly varying bunch in pretty  
much every axis) I don't remember anyone suggesting you wait on the  
TLD operators to set up their own repositories.

What I do remember folks saying is that hardcoding a list in other  
contexts has caused lots of trouble in the past and that it is  
probably a mistake for you to do it in your product.  Some folks have  
even suggested alternatives (although I gather you do not consider  
them 'workable').

If I understand correctly, if there is no data (regardless of the  
solution), you get no change From [email-masked]  Wed Jun 11 10:07:57 2008
From: David Conrad <[email-masked]>
To: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 10:08:18 -0700
Cc: [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

Gervase,

> mind) look like producing anything workable in the short term.

I guess it depends on what you mean by 'workable'.

> set up their own repositories of the data. There is a contradiction  

While I might agree that it is unlikely you'll get all the TLDs to  
agree on or do anything (they are a wildly varying bunch in pretty  
much every axis) I don't remember anyone suggesting you wait on the  
TLD operators to set up their own repositories.

What I do remember folks saying is that hardcoding a list in other  
contexts has caused lots of trouble in the past and that it is  
probably a mistake for you to do it in your product.  Some folks have  
even suggested alternatives (although I gather you do not consider  
them 'workable').

If I understand correctly, if there is no data (regardless of the  
solution), you get no change inin behavior.   As such, doing a probe for  
policy data when it is needed would seem to be workable.  If there is  
no data available (for whatever reason), you get no change in  
behavior.  If there is data, you get the most up to date available.   
Whether or not you start with a static list that is then over-ridden  
by the response from the probe is an implementation choice that can be  
argued.

FWIW.

Regards,
-drc

 behavior.   As such, doing a probe for  
policy data when it is needed would seem to be workable.  If there is  
no data available (for whatever reason), you get no change in  
behavior.  If there is data, you get the most up to date available.   
Whether or not you start with a static list that is then over-ridden  
by the response from the probe is an implementation choice that can be  
argued.

FWIW.

Regards,
-drc

---

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.
_______________________________________________
DNSOP mailing list
[email-masked]
https:From [email-masked]  Wed Jun 11 13:16:08 2008
From: Florian Weimer <[email-masked]>
To: Gervase Markham <[email-masked]>
Date: Wed, 11 Jun 2008 22:16:03 +0200
Cc: [email-masked], Jamie Lokier <[email-masked]>,
	David Conrad <[email-masked]>,
	Jelte Jansen <[email-masked]>, [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

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

s://www.ietf.org/mailman/listinfo/dnsop

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Jun 2008 15:22:55 -0500

> in this regard.  It does not list a single protocol spec which  

It's kind of assumed that you would be aware of these issues, I  
guess.   Lots of web sites use cookies to associate a session with a  
particular user.   With cross-site cookie theft, a malicious web site  
can gain access to your session cookie even if it was protected by  
htFrom [email-masked]  Wed Jun 11 13:22:39 2008
From: Ted Lemon <[email-masked]>
To: Florian Weimer <[email-masked]>
Date: Wed, 11 Jun 2008 15:22:55 -0500
	<[email-masked]>	<[email-masked]>
	<[email-masked]>
X-Mailer: Apple Mail (2.924)
Cc: [email-masked]
Subject: Re: [DNSOP] Public Suffix List
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[email-masked]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Errors-To: [email-masked]

> in this regard.  It does not list a single protocol spec which  

It's kind of assumed that you would be aware of these issues, I  
guess.   Lots of web sites use cookies to associate a session with a  
particular user.   With cross-site cookie theft, a malicious web site  
can gain access to your session cookie even if it was protected by  
httptps encryption when you were talking to the legitimate site.

Of course there are ways to mitigate this risk, but the only knob the  
mozilla guys have to turn is preventing the cookie from being leaked  
in the first place.

s encryption when you were talking to the legitimate site.

Of course there are ways to mitigate this risk, but the only knob the  
mozilla guys have to turn is preventing the cookie from being leaked  
in the first place.

---

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

* Ted Lemon:

> It's kind of assumed that you would be aware of these issues, I guess.

But hardly anybody seems to be.

> Lots of web sites use cookies to associate a session with a
> https encryption when you were talking to the legitimate site.

Yes, but that's why cookies are associated with the host name of the
incoming request.  The cookie set operation controls which domains can
read the cookie.  No special data is required for that.

What's happening here is that a restriction is placed on the largest
possible subtree for which you can set a cookie.  Failure to do this
does not grant read access to arbitrary cookies in itself.  But as I
wrote, it might expose session fixation problems.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Jun 2008 15:37:38 -0500

On Jun 11, 2008, at 3:30 PM, Florian Weimer wrote:
> Failure to do this

Right, the point is that the mozilla guys can't force web site  
implementors to do the right thing, but they still get dinged for a  
security flaw if the web site implementors do the wrong thing.   The  
only knob they can turn is this one.   So it makes a great deal of  
sense for them to try to turn it.

Also, you discounted the privacy issue in youFrom [email-masked]  Wed Jun 11 13:37:17 2008
Date: Wed, 11 Jun 2008 15:37:38 -0500
	<[email-masked]>
	<[email-masked]>

On Jun 11, 2008, at 3:30 PM, Florian Weimer wrote:
> Failure to do this

Right, the point is that the mozilla guys can't force web site  
implementors to do the right thing, but they still get dinged for a  
security flaw if the web site implementors do the wrong thing.   The  
only knob they can turn is this one.   So it makes a great deal of  
sense for them to try to turn it.

Also, you discounted the privacy issue in yr previous message, but  
the point is that in some countries privacy is actually a legal  
requirement, one which the Mozilla folks, I think rightly, feel some  
obligation to honor.

our previous message, but  
the point is that in some countries privacy is actually a legal  
requirement, one which the Mozilla folks, I think rightly, feel some  
obligation to honor.

---

From: SM <[email-masked]>
Date: Wed, 11 Jun 2008 13:43:23 -0700

Hi Gervase,
>to be fooled or defrauded?

Does that mean that the new Firefox will never display domains that 
allow its users to be fooled or defrauded? :-)

>mind) look like producing anything workable in the short term.

If you push aside all the negative views, you won't see any 
alternative proposals.

>do anything is an enterprise doomed to failure, and the other half seem

That's because there are some people on this list who have attempted 
that before.

>to From [email-masked]  Wed Jun 11 13:43:19 2008
Date: Wed, 11 Jun 2008 13:43:23 -0700
To: Gervase Markham <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

Hi Gervase,
>to be fooled or defrauded?

Does that mean that the new Firefox will never display domains that 
allow its users to be fooled or defrauded? :-)

>mind) look like producing anything workable in the short term.

If you push aside all the negative views, you won't see any 
alternative proposals.

>do anything is an enterprise doomed to failure, and the other half seem

That's because there are some people on this list who have attempted 
that before.

>to ththink that we should be waiting for all the TLD operators to agree to

Maybe those people are not looking for a short-term fix.

By the way, the question of suffix lists has been discussed in other 
Internet areas before.  It's not restricted to cookies only.  The 
fact that nobody pointed you to a RFC suggests that there hasn't been 
an acceptable solution yet.

Quoting RFC 4085:

   "Products that rely on such embedded IP addresses initially may appear
    to be convenient to the product's designer and to its operator or user,
    but this dubious benefit comes at the expense of others in the Internet
    community."

Replace IP addresses with publish suffix and you'll see why your 
proposal generated so much controversy on this mailing list.

Regards,
-sm

ink that we should be waiting for all the TLD operators to agree to
>set up their own repositories of the data. There is a contradiction there.

Maybe those people are not looking for a short-term fix.

By the way, the question of suffix lists has been discussed in other 
Internet areas before.  It's not restricted to cookies only.  The 
fact that nobody pointed you to a RFC suggests that there hasn't been 
an acceptable solution yet.

Quoting RFC 4085:

   "Products that rely on such embedded IP addresses initially may appear
    to be convenient to the product's designer and to its operator or user,
    but this dubious benefit comes at the expense of others in the Internet
    community."

Replace IP addresses with publish suffix and you'll see why your 
proposal generated so much controversy on this mailing list.

Regards,
-sm

---

From: Dean Anderson <[email-masked]>
Date: Thu, 12 Jun 2008 00:03:15 -0400 (EDT)

On Wed, 11 Jun 2008, Gervase Markham wrote:

> with relation to the services they provide. 

Actaully, I looked into the 'Our ISP blocked our mail without our
knowledge' claim. [I'm always interested in the cases where this is
true]. In fact, Mozilla's email is handled by mailservers on
63.245.208/20, which is a /20 assigned to Mozilla.org. It struck me as
quite odd that quite strange that Mozilla.org has 4096 IP addresses, and
that it got this assignment in 2006, under what should have been very
strict usage and allocation rules...I wonder how Mozilla.org justifies
4k public IP addresses---Question for a different forum. Anyway, using
SORBS isn't a decision you can blame on your ISP. Its Mozilla.org's
mailserver, not an outsourced ISP mailserver.  Mozilla.org has control
over its email filtering, and it seems likely a Mozilla.org admin
configured SORBS. It was not their ISP.  This affects at least my view
of your credibility.

> I confess I've only ever vaguely heard the name SORBS, and had no idea
> that my provider was using it. But I don't believe that using it makes
> me uncontactable. My phone number and address are on my personal web
> page.
>
> about Firefox's TLD IDN whitelist. I'm going to send Gerv a nasty
> email. Hang on, my email's been rejected. Oh well, I guess I'll just
> have to live with it."

Well, somehow they managed to convey their upset'ness to ICANN, but not
convey that to Mozilla. I don't know exactly why that was.  But people
often don't try very hard to overcome communication problems to tell
someone that they are unreasonably off in the weeds.  A SORBS bounce
would tend to confirm the effort is pointless.

> work. See http://www.shmoo.com/idn/ .)

I don't see that the answer is "no-one", nor that "the registries" has
been shown not to work, as you claim.  However, if you think there is a
problem and you have a solution that should be imposed on the TLDs, you
should take the matter up with ICANN.  Your unilateral exercise is
certainly no solution.

> > Mozilla.org doesn't represent the internet industry nor any
> > government or governing organization.
> 
> No, we represent our users, and we make all sorts of security
> decisions for them on a regular basis.

Hmm. Worrisome, given the apparent lack of serious thought put into some
of those "security" decisions, and the lack of credible, serious thought
put into even anti-spam choices, and the blaming of things on your ISP.

> One of the reasons Firefox is popular is precisely because it doesn't
> wimp out of security decisions with user-irritating popup questions
> they have no information to answer.

I also use firefox, but certainly not for those reasons. I use it
because it came with Linux, and it displays HTML pretty reasonably. I
didn't know it might have other dubious agendas hard-coded.

> But, as someone else has said, if people don't like the decisions we
> make, they can either become part of "we" and seek to change them, or
> they can change or build their copy, or can distribute an alternative
> browser.

Actually, I said that. Perhaps others did, too.

> > Why should TLD's think they need to register with Mozilla.org?
> 

You have no justification to form that conclusion. The TLDs aren't
defrauding anyone; The TLDs aren't aiding in the fraud of anyone. And
your scheme isn't even shown to stop fraudulent websites. So Mozilla.org
seems to have little to no justification whatsoever for its extremely
unilateral actions.  

The people who register their domains with any certified TLD do have an
automatic right to have Firefox display their websites.  You have no
right to assert they are fraudulent when they aren't and you have no
evidence they are.

I don't get a good feeling about Mozilla.org, anymore.  The unrealistic,
unilateral attitude reminds me of other kinds of similar extremism, that
was also found to be unsubstantiated, and a great waste of effort.  
Indeed, the claim of blocking fraud with this scheme, appears to be the
deceptive claim. It reminds me of SPF proponents claims that SPF would
end spam.  Those were similarly false.

But I am beginning to think this thread doesn't really belong on DNSOP
(though it is relevant to TLD DNS operations), but probably should be on
an ICANN list devoted to TLD public policy issues. I have no idea what
list that would be, or if there is such a list.  Not that I oppose
continuing the thread here, but I am concerned that this is an important
public policy topic and the readers of this list are more engineering
oriented.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Thu, 12 Jun 2008 00:03:15 -0400 (EDT)

--Dean

---

From: "Antoin Verschuren" <[email-masked]>
Date: Thu, 12 Jun 2008 09:47:36 +0200

> the opinion of this mailing list.

Did you really say this ?
Did I read this correctly ?

No, can't be. I don't think Mozilla wants to insult all the IETF experts that have voluntarily helped them make a living in the first place...

But I'm tempted to make some additions to protocols in the form of "IF browser=Firefox THEN crash" in the layer 9 section of some RFC's.

Perhaps it's time to move back to promoting Opera again.
Oh, and I must remember to turn automatic updates off.
And tell my mother to do so 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

---

From: "Antoin Verschuren" <[email-masked]>
Date: Thu, 12 Jun 2008 09:47:36 +0200

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: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 12 Jun 2008 09:57:17 +0200

On Thu, Jun 12, 2008 at 09:47:36AM +0200,
 Antoin Verschuren <[email-masked]> wrote 

> Perhaps it's time to move back to promoting Opera again.

Are you sure that they do not do the same? I tried to promote
Konqueror but it has apparently the same (or even worse) bug than
Firefox. And my bug report for Konqueror was closed immediately, which
seems to indicate that the Mozilla people are not the only one with
deaf ears.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 12 Jun 2008 09:57:17 +0200

---

From: "Antoin Verschuren" <[email-masked]>
Date: Thu, 12 Jun 2008 10:10:23 +0200

> seems to indicate that the Mozilla people are not the only one with

Yes, but at least they "consulted" the IETF DNSOP WG, and not "insulted" them.
It's for the layer 9 issue, not for the bad code.

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: "Antoin Verschuren" <[email-masked]>
Date: Thu, 12 Jun 2008 10:10:23 +0200

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: Gervase Markham <[email-masked]>
Date: Thu, 12 Jun 2008 09:53:21 +0100

Antoin Verschuren wrote:
>> No. I don't need to sell you the idea. The idea doesn't stand or
>> fall on the opinion of this mailing list.
> 
> Did you really say this ? Did I read this correctly ?
> 
> No, can't be. I don't think Mozilla wants to insult all the IETF
> experts that have voluntarily helped them make a living in the first
> place...

Why is the above an insult? It's just a statement of fact. I didn't come
here to say "I have this idea. If you guys like it, we'll do it. If you
don't like it, we won't." I apologise if some people thought that this
is what I was saying. As I said, I came here because Yngve suggested
that you would appreciate being told about this scheme.

I've had some useful feedback, and food for thought. And I'm grateful to
those people who gave it to me.

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Thu, 12 Jun 2008 09:53:21 +0100

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Thu, 12 Jun 2008 12:25:52 +0100

Ted Lemon wrote:
> Putting the list in the DNS instead of in the browser isn't workable?  

Perhaps, but not in the short term.

> Serious question.   I think several proposals have been advanced here
> that /could/ work.   Mine has the virtue of being completely under your
> control. 

It does. I admit I hadn't thought of something like that, and would be
interested to see what Yngve makes of it. He's done the most work on
protocols for transmitting this information; see:
http://www.ietf.org/internet-drafts/draft-pettersen-subtld-structure-03.txt

Is there a particular reason that DNS is a better mechanism than HTTP,
in your view? Or is that an implementation detail?

> transition From [email-masked]  Thu Jun 12 04:25:32 2008
Date: Thu, 12 Jun 2008 12:25:52 +0100

Ted Lemon wrote:
> Putting the list in the DNS instead of in the browser isn't workable?  

Perhaps, but not in the short term.

> Serious question.   I think several proposals have been advanced here
> that /could/ work.   Mine has the virtue of being completely under your
> control. 

It does. I admit I hadn't thought of something like that, and would be
interested to see what Yngve makes of it. He's done the most work on
protocols for transmitting this information; see:
http://www.ietf.org/internet-drafts/draft-pettersen-subtld-structure-03.txt

Is there a particular reason that DNS is a better mechanism than HTTP,
in your view? Or is that an implementation detail?

> transition toto a list that's maintained more dynamically, and as long as
> you actually execute that plan, it seems to me that this is harmless.

The second question is one of resources and client complexity. I am
meeting resistance to the idea of having the existing list regularly
dynamically downloaded, which would be the simplest method of providing
more frequent updates than the six-to-eight week Firefox security
releases. An assemble-and-cache-the-data-from-DNS scheme would be an
order of magnitude more complex.

Gerv

 a list that's maintained more dynamically, and as long as
> you actually execute that plan, it seems to me that this is harmless.

The second question is one of resources and client complexity. I am
meeting resistance to the idea of having the existing list regularly
dynamically downloaded, which would be the simplest method of providing
more frequent updates than the six-to-eight week Firefox security
releases. An assemble-and-cache-the-data-from-DNS scheme would be an
order of magnitude more complex.

Gerv

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 12 Jun 2008 13:54:32 +0100

> order of magnitude more complex.

	I'm not sure why you would need to assemble anything.
	Couldn't you seize the data you need, on demand,From [email-masked]  Thu Jun 12 05:54:00 2008
Date: Thu, 12 Jun 2008 13:54:32 +0100
From: Niall O'Reilly <[email-masked]>
To: IETF DNSOP WG <[email-masked]>
Cc: Niall O'Reilly <[email-masked]>
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

> order of magnitude more complex.

	I'm not sure why you would need to assemble anything.
	Couldn't you seize the data you need, on demand, from
	the DNS (and cache at will).

	Best regards,

	Niall O'Reilly
	University College Dublin IT Services

	PGP key ID: AE995ED9 (see www.pgp.net)
	Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Thu, 12 Jun 2008 15:26:16 +0200

> 	the DNS (and cache at will).

DNS, or full DNS, is not always available.

There are at least two scenarios where this is the case:

  - Behind (very) closed firewalls, where all access go through a HTTP-only  
proxy. No DNS for external addresses is available. For that matter, when  
going through a proxy you have no way of knowing if the DNS available to  
you know anything about the address space you are accessing through the  
proxy.

  From [email-masked]  Thu Jun 12 06:25:55 2008
Date: Thu, 12 Jun 2008 15:26:16 +0200
To: "Niall O'Reilly" <[email-masked]>, "IETF DNSOP WG" <[email-masked]>
From: "Yngve Nysaeter Pettersen" <[email-masked]>
Organization: Opera Software
Subject: Re: [DNSOP] Public Suffix List
Reply-To: [email-masked]
Sender: [email-masked]

> 	the DNS (and cache at will).

DNS, or full DNS, is not always available.

There are at least two scenarios where this is the case:

  - Behind (very) closed firewalls, where all access go through a HTTP-only  
proxy. No DNS for external addresses is available. For that matter, when  
going through a proxy you have no way of knowing if the DNS available to  
you know anything about the address space you are accessing through the  
proxy.

  - - On a number of systems, in particular phone devices, the application  
does not even have access to DNS to do a name lookup, it must specify the  
hostname, and try to connect.

Additionally, a DNS-only solution would mean implementing a DNS client  
inside the application, since AFAICT the platform socket APIs usually do  
not provide the necessary functionality needed to access non-IPaddress  
data.

While I am not opposed to the data being available in DNS, there must be a  
simple way to collect and provide it to clients efficiently and for any  
use case, while reducing privacy issues (which a batch of data for a given  
TLD will solve neatly), and with respect to HTTP clients, HTTP is the only  
method we can rely on, and it will also be available to many specialized  
applications that use HTTP, perhaps through some library.

On a number of systems, in particular phone devices, the application  
does not even have access to DNS to do a name lookup, it must specify the  
hostname, and try to connect.

Additionally, a DNS-only solution would mean implementing a DNS client  
inside the application, since AFAICT the platform socket APIs usually do  
not provide the necessary functionality needed to access non-IPaddress  
data.

While I am not opposed to the data being available in DNS, there must be a  
simple way to collect and provide it to clients efficiently and for any  
use case, while reducing privacy issues (which a batch of data for a given  
TLD will solve neatly), and with respect to HTTP clients, HTTP is the only  
method we can rely on, and it will also be available to many specialized  
applications that use HTTP, perhaps through some library.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jun 2008 08:56:13 -0500

> in your view? Or is that an implementation detail?

The DNS occurred to me because it's already used for carrying domain  
names, and also because I've been doing DNS for a long time, so it's a  
comfortable tool for me.

HTTP would work as long as the queries were for specific domain  
names.   However, you would miss taking advantage of all the work DNS  
server implementors have done to make DNS lookups really fast.

Also, I suspect the overhead of an HTTP request is substantially  
higher than the overhead of a DNS request when you think about all the  
groovy headers that normalFrom [email-masked]  Thu Jun 12 06:56:25 2008
From: Ted Lemon <[email-masked]>
To: Gervase Markham <[email-masked]>
Date: Thu, 12 Jun 2008 08:56:13 -0500
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

> in your view? Or is that an implementation detail?

The DNS occurred to me because it's already used for carrying domain  
names, and also because I've been doing DNS for a long time, so it's a  
comfortable tool for me.

HTTP would work as long as the queries were for specific domain  
names.   However, you would miss taking advantage of all the work DNS  
server implementors have done to make DNS lookups really fast.

Also, I suspect the overhead of an HTTP request is substantially  
higher than the overhead of a DNS request when you think about all the  
groovy headers that normally get stuffed into HTTP, particularly if  
you want to use SSL.   With DNSSEC, the DNSSEC server signs a zone  
once and then just answers you with the signed data when you ask for  
it.  Whereas with HTTPS the HTTP server has to re-sign the data for  
every query.

Also if you use DNS you get to take advantage of peoples' DNS caches  
to reduce the load on your server.   If you use HTTPS, your server is  
going to see every query from every client.

> An assemble-and-cache-the-data-from-DNS scheme would be an

That really wasn't what I had in mind.   What I had in mind was more  
of a lazy evaluation scheme, where you look the data up when you need  
it, and if the lookup fails you fail safe (that is, treat the domains  
as if they are not equivalent).   I don't think either scheme is  
really all that complex, but I admit that I probably don't know what  
the issues are.   I guess you're trying to avoid the possibility of  
the lookup failing, which makes sense, but if you have good anycast  
coverage I don't think that's a real issue - if the DNS isn't working,  
the page fetch would have failed.

Please let me know if there's anything I can do to help.

ly get stuffed into HTTP, particularly if  
you want to use SSL.   With DNSSEC, the DNSSEC server signs a zone  
once and then just answers you with the signed data when you ask for  
it.  Whereas with HTTPS the HTTP server has to re-sign the data for  
every query.

Also if you use DNS you get to take advantage of peoples' DNS caches  
to reduce the load on your server.   If you use HTTPS, your server is  
going to see every query from every client.

> An assemble-and-cache-the-data-from-DNS scheme would be an

That really wasn't what I had in mind.   What I had in mind was more  
of a lazy evaluation scheme, where you look the data up when you need  
it, and if the lookup fails you fail safe (that is, treat the domains  
as if they are not equivalent).   I don't think either scheme is  
really all that complex, but I admit that I probably don't know what  
the issues are.   I guess you're trying to avoid the possibility of  
the lookup failing, which makes sense, but if you have good anycast  
coverage I don't think that's a real issue - if the DNS isn't working,  
the page fetch would have failed.

Please let me know if there's anything I can do to help.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jun 2008 09:05:51 -0500

On Jun 12, 2008, at 8:26 AM, Yngve Nysaeter Pettersen wrote:

>  - On a number of systems, in particular phone devices, the  
> application
> hostname, and try From [email-masked]  Thu Jun 12 07:06:35 2008
From: Ted Lemon <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 12 Jun 2008 09:05:51 -0500
Cc: IETF DNSOP WG <[email-masked]>, Gervase Markham <[email-masked]>
Subject: Re: [DNSOP] Public Suffix List
Sender: [email-masked]

On Jun 12, 2008, at 8:26 AM, Yngve Nysaeter Pettersen wrote:

>  - On a number of systems, in particular phone devices, the  
> application
> hostname, and try toto connect.

Ouch.   That's really painful.   For those devices I think you'd have  
to fall back to tunneling the DNS request over an HTTP channel.

> not provide the necessary functionality needed to access non-IPaddress

I think Mozilla already has its own DNS resolver.   It might need to  
be enhanced to support DNSSEC if it doesn't already.   The ISC has a  
resolver you can use that's under the BSD license.   The resolver  
isn't very big.   So I think this is a non-issue.

I can see why you're resisting doing it this way.   It does make for  
more work.   But what I'd be worried about if you *don't* do it this  
way is that you're going to wind up making a mistake in your static  
list that's not going to get corrected in time, and somebody's going  
to run into an issue that gets you dinged for another stupid security  
complaint.   And even though it was the fault of the site that allowed  
the bogus cookie, you're still going to get all the bad publicity.

With a just-in-time lazy lookup scheme, you can be much more responsive.

 connect.

Ouch.   That's really painful.   For those devices I think you'd have  
to fall back to tunneling the DNS request over an HTTP channel.

> not provide the necessary functionality needed to access non-IPaddress

I think Mozilla already has its own DNS resolver.   It might need to  
be enhanced to support DNSSEC if it doesn't already.   The ISC has a  
resolver you can use that's under the BSD license.   The resolver  
isn't very big.   So I think this is a non-issue.

I can see why you're resisting doing it this way.   It does make for  
more work.   But what I'd be worried about if you *don't* do it this  
way is that you're going to wind up making a mistake in your static  
list that's not going to get corrected in time, and somebody's going  
to run into an issue that gets you dinged for another stupid security  
complaint.   And even though it was the fault of the site that allowed  
the bogus cookie, you're still going to get all the bad publicity.

With a just-in-time lazy lookup scheme, you can be much more responsive.

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Thu, 12 Jun 2008 16:07:19 +0200

On Thu, 12 Jun 2008 15:56:13 +0200, Ted Lemon <[email-masked]>  
wrote:

> HTTP would work as long as the queries were for specific domain names.    
> However, you would miss taking advantage of all the work DNS server  
> implementors have done to make DNS lookups really fast.
>
> Also, I suspect the overhead of an HTTP request is substantially higher  
> than the overhead of a DNS request when you think about all the groovy  
> headers that normally get stuffed into HTTP, particularly if you want to  
> use SSL.   With DNSSEC, the DNSSEC server signs a zone once and then  
> just answers you with the signed data when you ask for it.  Whereas with  
> HTTPS the HTTP server has to re-sign the data for every query.

The way I envision a dynamically updated system for this (see my draft),  
the information would be grouped for each TLD in a single file that the  
client downloads every 30 days when needed. That means that the overhead  
is kept to a minimum.

Where the information in the file(s) comes from is a separate topic. It  
can be a database maintained somewhere, or it could be DNS (but in that  
case it would have to be traversable).

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Thu, 12 Jun 2008 16:07:19 +0200

---

From: Brian Dickson <[email-masked]>
Date: Thu, 12 Jun 2008 10:08:50 -0400

Yngve Nysaeter Pettersen wrote:
>   - On a number of systems, in particular phone devices, the application  

A DNS-based solution does not *need* to be a DNS-*only* solution.

As I understand it, your list associates suffixes with "true/false" 
state, i.e. whether they are public or not.

Imagine a tree of subdomains, all of which exist only to provide 
true/false information, rooted at, say,
suffix-list.mozilla.org. If a given subdomain exists, "true", otherwise 
"false". And for http-only scenarios,
have each of these subdomains be a CNAME pointing a static web page, say 
"true.suffix-lists.mozilla.org.",
which contains just the word "True".

Both the content of the pages, and the DNS entries, could be cached in 
their respective systems
(web browser cache, or DNS resolver cache). Timeliness of updates would 
be maintained by appropriate
mechanisms to tell the querying agent to check again (HTTP tag or DNS TTL).

The HTTP side of things does not require a separate DNS client. But, the 
updates to the list can
be made trivially by manipulation of DNS data alone, and use of DNS 
involves much less processing
on the client side if DNS client querying is possible (one UDP packet, 
generally).

Brian

---

From: Brian Dickson <[email-masked]>
Date: Thu, 12 Jun 2008 10:08:50 -0400

Brian