Re: [DNSOP] Public Suffix List

[Brian Dickson]

Yngve Nysaeter Pettersen wrote:
> On Thu, 12 Jun 2008 14:54:32 +0200, Niall O'Reilly <[EMAIL PROTECTED]>  
> wrote:
>
>   
>> On 12 Jun 2008, at 12:25, Gervase Markham wrote:
>>
>> 
>>> 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.
>>>   
>>  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).
>> 
>
> 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.
>
>   

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

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

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

Re: [DNSOP] Public Suffix List

[Yngve Nysaeter Pettersen]

On Thu, 12 Jun 2008 15:56:13 +0200, Ted Lemon <[EMAIL PROTECTED]>  
wrote:

> On Jun 12, 2008, at 6:25 AM, Gervase Markham wrote:
>> Is there a particular reason that DNS is a better mechanism than HTTP,
>> 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.

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


-- 
Sincerely,
Yngve N. Pettersen

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

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

Re: [DNSOP] Public Suffix List

[Ted Lemon]

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

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

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.

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

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.

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

Re: [DNSOP] Public Suffix List

[Ted Lemon]

On Jun 12, 2008, at 6:25 AM, Gervase Markham wrote:
> Is there a particular reason that DNS is a better mechanism than HTTP,
> 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
> order of magnitude more complex.

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.

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

Re: [DNSOP] Public Suffix List

[Yngve Nysaeter Pettersen]

On Thu, 12 Jun 2008 14:54:32 +0200, Niall O'Reilly <[EMAIL PROTECTED]>  
wrote:

>
> On 12 Jun 2008, at 12:25, Gervase Markham wrote:
>
>> 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.
>
>   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).

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.


-- 
Sincerely,
Yngve N. Pettersen

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

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

Re: [DNSOP] Public Suffix List

[Niall O'Reilly]

On 12 Jun 2008, at 12:25, Gervase Markham wrote:


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.


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





PGP.sig
Description: This is a digitally signed message part
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

Ted Lemon wrote:
> On Jun 11, 2008, at 6:26 AM, Gervase Markham wrote:
>> 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.
> 
> 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?

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

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List - Please move discussion to dnsop

[Gervase Markham]

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List - Please move discussion to dnsop

[Antoin Verschuren]

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

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
E [EMAIL PROTECTED]
W http://www.sidn.nl/

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

Re: [DNSOP] Public Suffix List - Please move discussion to dnsop

[Stephane Bortzmeyer]

On Thu, Jun 12, 2008 at 09:47:36AM +0200,
 Antoin Verschuren <[EMAIL PROTECTED]> wrote 
 a message of 33 lines which said:

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

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

Re: [DNSOP] Public Suffix List - Please move discussion to dnsop

[Antoin Verschuren]

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

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
E [EMAIL PROTECTED]
W http://www.sidn.nl/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Dean Anderson]

On Wed, 11 Jun 2008, Gervase Markham wrote:

> Dean Anderson wrote:
> >> 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/
> 
> No-one can have control over and knowledge of everything their ISP does
> 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.
>
> 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."

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.

> >> That policy of ours should have no effect whatsoever on TLDs with a
> >> responsible attitude to homographs. Our registration requirements are
> >> not onerous.
> > 
> > ??? This statement doesn't seem very credible. What authority do you
> > 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/ .)

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

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 k

Re: [DNSOP] Public Suffix List

[SM]

Hi Gervase,
At 02:15 11-06-2008, Gervase Markham wrote:
>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?

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

At 04:25 11-06-2008, Gervase Markham wrote:
>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.

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

>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

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

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

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

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

Re: [DNSOP] Public Suffix List

[Ted Lemon]

On Jun 11, 2008, at 3:30 PM, Florian Weimer wrote:
> Failure to do this
> does not grant read access to arbitrary cookies in itself.  But as I
> wrote, it might expose session fixation problems.

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

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

Re: [DNSOP] Public Suffix List

[Florian Weimer]

* 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
> particular user.   With cross-site cookie theft, a malicious web site
> can gain access to your session cookie even if it was protected by
> 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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Ted Lemon]

On Jun 11, 2008, at 3:16 PM, Florian Weimer wrote:
> 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.

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

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

Re: [DNSOP] Public Suffix List

[Florian Weimer]

* Gervase Markham:

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

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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[David Conrad]

Gervase,

On Jun 11, 2008, at 4:26 AM, Gervase Markham wrote:
> 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.

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

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

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

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

Re: [DNSOP] Public Suffix List - Please move discussion to dnsop

[Joe Baptista]

On Wed, Jun 11, 2008 at 12:26 PM, Gervase Markham <[EMAIL PROTECTED]> wrote:


> > 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?
>
> I've answered it once to you privately and once to the list. Third time:
> "the same thing as now".
>

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

-- 
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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Brian Dickson]

Gervase Markham wrote:
> The difference is that the public suffix list is an (attempt at an)
> 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".
> 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?"
>   

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List - Please move discussion to dnsop

[Gervase Markham]

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.

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.

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

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

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

Re: [DNSOP] Public Suffix List - Please move discussion to dnsop

[Gervase Markham]

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.

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.

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

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

Gerv


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

Re: [DNSOP] Public Suffix List - Please move discussion to dnsop

[Ted Lemon]

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.


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

Re: [DNSOP] Public Suffix List

[Ted Lemon]

On Jun 11, 2008, at 6:26 AM, Gervase Markham wrote:
> 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.

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.

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

Re: [DNSOP] Public Suffix List - Please move discussion to dnsop

[Joe Baptista]

On Wed, Jun 11, 2008 at 11:18 AM, Gervase Markham <[EMAIL PROTECTED]> wrote:

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

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

-- 
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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List - Please move discussion to dnsop

[Gervase Markham]

[EMAIL PROTECTED] wrote:
>   that URL does not resolve in the way you might
>   expect.

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

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

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

Re: [DNSOP] Public Suffix List - Please move discussion to dnsop

[bmanning]

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

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

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

Re: [DNSOP] Public Suffix List - Please move discussion to dnsop

[Gervase Markham]

Edward Lewis wrote:
> Is the issue that a cookie needs to state for what domains it is 
> 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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Jamie Lokier]

Gervase Markham wrote:
> > 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?
>
> 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).
>
> 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.

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

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

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

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

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List - Please move discussion to dnsop

[Edward Lewis]

At 23:10 +1000 6/11/08, Mark Nottingham wrote:
>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).

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.

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

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

Re: [DNSOP] Public Suffix List

[Gervase Markham]

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List - Please move discussion to dnsop

[Mark Nottingham]

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/

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

Re: [DNSOP] Public Suffix List

[Joe Baptista]

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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Jeroen Massar]

Gervase Markham wrote:

Jeroen Massar wrote:

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




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.


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



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

Re: [DNSOP] Public Suffix List

[Gervase Markham]

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



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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Jeroen Massar]

Gervase Markham wrote:
[..]

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


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



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

Re: [DNSOP] Public Suffix List

[Gervase Markham]

Jamie Lokier wrote:
> 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?

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

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

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

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

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

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

Re: [DNSOP] Public Suffix List

[Gervase Markham]

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

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

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

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

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

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

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

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Henrik Nordstrom]

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

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

If you do this wronly yes.

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

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

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

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

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

In short the cookie problem is threefold:

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

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

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

Regards
Henrik


signature.asc
Description: This is a digitally signed message part
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Jamie Lokier]

Gervase Markham wrote:
> Jelte Jansen wrote:
> > won't they run into the very same problem if only tld's (and their
> > sld's) are marked as don't-set-cookies-here? Or is livejournal.com also
> > supposed to get on the list of public suffixes?
> 
> No. They can set cookies for www.livejournal.com or
> admin.livejournal.com (as opposed to livejournal.com), and these will
> not be shared with name.livejournal.com.

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Stephane Bortzmeyer]

On Tue, Jun 10, 2008 at 09:22:27PM +0200,
 Florian Weimer <[EMAIL PROTECTED]> 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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Stephane Bortzmeyer]

On Tue, Jun 10, 2008 at 11:31:00PM +0200,
 Stephane Bortzmeyer <[EMAIL PROTECTED]> wrote 
 a message of 16 lines which said:

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

Reported . Let's see if
Konqueror people react in the Mozilla way ("We decided and your
opinion does not matter")
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Stephane Bortzmeyer]

On Wed, Jun 11, 2008 at 10:15:19AM +0100,
 Gervase Markham <[EMAIL PROTECTED]> 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
), registrants also have to
go through the filter of browser authors.

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

Re: [DNSOP] Public Suffix List

[Gervase Markham]

Florian Weimer wrote:
> Have a look at this file:
> 
> /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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

Dean Anderson wrote:
>> 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/

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

>> That policy of ours should have no effect whatsoever on TLDs with a
>> responsible attitude to homographs. Our registration requirements are
>> not onerous.
> 
> ??? This statement doesn't seem very credible. What authority do you
> 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/ .)

> 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. 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

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

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

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

Henrik Nordstrom wrote:
> 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.

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

Doug Barton wrote:
> Gervase Markham wrote:
>> 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.
> 
> Is it just me, or do those two statements seem to contradict one another?

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

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

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

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

Yep. In six to eight weeks, usually.

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

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

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

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

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

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

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

Done; thank you.

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

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

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

There's always more work to do :-)

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

Re: [DNSOP] Public Suffix List

[Gervase Markham]

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

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

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

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

Re: [DNSOP] Public Suffix List

[Jelte Jansen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Gervase Markham wrote:
> Florian Weimer wrote:
>> * Jamie Lokier:
>> 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.
> 

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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIT4+T4nZCKsdOncURAqZkAKCOxkwMs6By3zxef2AhKU7nP9+0qgCbBJZd
sEApH+yga8r+DXQVN76qpMQ=
=SP/N
-END PGP SIGNATURE-
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

Florian Weimer wrote:
> * Jamie Lokier:
>> (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?
> 
> 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Doug Barton]

Gervase Markham wrote:
> Hi Doug,
> 
> Doug Barton wrote:
>> Coming as it does late in your development cycle (and especially given
>> the "enthusiastic" reaction you've received here today) the temptation
>> would be for you to dig your heels in and insist on moving forward as
>> planned. I urge you to resist that temptation.
> 
> Just as a matter of fact, Firefox 3 ships in a week; there is no
> possibility of further change in that release.
> 
> The fact that I am working on this question now is not to present a
> /fait accompli/; I've just been too busy to get to it.

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.

>> It may help you at least
>> update your current list, and help keep it up to date:
>> http://data.iana.org/TLD/tlds-alpha-by-domain.txt
> 
> Thank you. I believe something like that was used initially.

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

>> There is also another issue which I haven't seen addressed, although
>> admittedly it's a corner case, of TLD NICs that establish a firm policy
>> preventing user registration at the top level, but allow themselves to
>> operate sites such as www.nic.tld.
> 
> That would be fine if (again, using cookies as an example) they set them
> for www.nic.tld and not nic.tld. Or, they could add an exception to the
> public suffix data they submitted.

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

>> 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. :)  
> 
> If the scheme relied on getting explicit responses from them all, then
> 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
> to publish the information via DNS or some other mechanism is doomed.)
> But in the absence of their input, we can use public sources and
> deduction to make a good guess - or just not give them an entry. There
> aren't many ad networks who are setting cookies for .com.je to track
> visitors across different Jersey websites.

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.

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

Re: [DNSOP] Public Suffix List

[Stephane Bortzmeyer]

On Tue, Jun 10, 2008 at 09:39:01PM +0200,
 Florian Weimer <[EMAIL PROTECTED]> wrote 
 a message of 18 lines which said:

> /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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Henrik Nordstrom]

On tis, 2008-06-10 at 21:25 +0200, Florian Weimer wrote:

> 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


signature.asc
Description: This is a digitally signed message part
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Henrik Nordstrom]

On tis, 2008-06-10 at 21:05 +0200, Florian Weimer wrote:
> stuff).  This must work by default, without explicit marking by the web
> 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


signature.asc
Description: This is a digitally signed message part
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Henrik Nordstrom]

On tis, 2008-06-10 at 13:45 +0200, Henrik Nordstrom wrote:
> On mån, 2008-06-09 at 17:28 +0100, Gervase Markham wrote:
> 
> > It would be an appropriate mechanism; when it does contain this
> > 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.

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


signature.asc
Description: This is a digitally signed message part
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Henrik Nordstrom]

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

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

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


signature.asc
Description: This is a digitally signed message part
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Florian Weimer]

* Stephane Bortzmeyer:

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

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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Mark Foster]

Florian Weimer wrote:
> * Gervase Markham:
>
>   
>> 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.
>> 
>
> 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.
>   
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 PROTECTED]>  http://mark.foster.cc/


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

Re: [DNSOP] Public Suffix List

[Florian Weimer]

* Jamie Lokier:

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

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)

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

Yes.  I think Ebay suffers from these issues.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Mark Foster]

Florian Weimer wrote:
> * Gervase Markham:
>
>   
>> 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.
>> 
>
> 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.
>   
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 PROTECTED]>  http://mark.foster.cc/


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

Re: [DNSOP] Public Suffix List

[Florian Weimer]

* Stephane Bortzmeyer:

> Me, for instance. And, AFAIK, Microsoft did not announce such a scheme
> 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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Florian Weimer]

* Brian Dickson:

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

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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Florian Weimer]

* Gervase Markham:

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

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.

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

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

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

This is the status quo.  Javascript is constantly enhanced with database
and stuff like that.  As a result, you aren't just protecting mere
cookies, but much more.  Obviously, this approach is not sound.  But
even with those later changes, some means to divine administrative
boundaries from DNS names are required for plain cookie management.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Paul Hoffman]

At 11:10 AM +0100 6/10/08, Gervase Markham wrote:
>Kim Davies wrote:
>>  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.
>
>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.

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Wes Hardaker]

> On Tue, 10 Jun 2008 11:10:32 +0100, Gervase Markham <[EMAIL PROTECTED]> 
> 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.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[David Conrad]

Gervase,

On Jun 10, 2008, at 3:09 AM, Gervase Markham wrote:
> 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?

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

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

Re: [DNSOP] Public Suffix List

[Dean Anderson]

On Tue, 10 Jun 2008, Gervase Markham wrote:

> Kim Davies wrote:
> > 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. 

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/

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

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


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

Re: [DNSOP] Public Suffix List

[Jamie Lokier]

Adrien de Croy wrote:
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?

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.

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

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Adrien de Croy]

 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



Gervase Markham wrote:
> Jamie Lokier wrote:
>   
>> 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.
>> 
>
> 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
>
>   

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

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

Re: [DNSOP] Public Suffix List

[Henrik Nordstrom]

On mån, 2008-06-09 at 17:28 +0100, Gervase Markham wrote:

> It would be an appropriate mechanism; when it does contain this
> 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


signature.asc
Description: This is a digitally signed message part
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Jamie Lokier]

Gervase Markham wrote:
> Jamie Lokier wrote:
> > 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.
> 
> 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.

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Jamie Lokier]

Gervase Markham wrote:
> - "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:..."

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

Jamie Lokier wrote:
> 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.

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

Hi Doug,

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

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

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

> It may help you at least
> update your current list, and help keep it up to date:
> http://data.iana.org/TLD/tlds-alpha-by-domain.txt

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

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

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

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

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

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

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

Yngve probably knows more about this than me, though.

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

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

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

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

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

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

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

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

Thanks :-)

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

Re: [DNSOP] Public Suffix List

[Gervase Markham]

Kim Davies wrote:
> 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. 

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

Stephane Bortzmeyer wrote:
> * Difficulty of managing this list (and even worse if every browser
>   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.

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

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Gervase Markham]

David Conrad wrote:
> You're talking about essentially creating a registry of their registry
> policies and distributing it statically via your product.  I would
> imagine they might be interested and might even have some useful input
> to provide. 

We're about to ask them for their input.

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

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

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

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

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

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

OK - thanks.

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

Re: [DNSOP] Public Suffix List

[Jamie Lokier]

Gervase Markham wrote:
> Jamie Lokier wrote:
> > Gervase Markham wrote:
> >>> Wouldn't it be more appropriate for MyBank to _itself_ say the history
> >>> for these sites should be grouped?  E.g. in an HTTP response header,
> >>> or DNS record for mybank.co.uk?
> >> The total amount of effort required for this solution is mind-boggling.
> > 
> > How is it more work for them to publish over DNS or HTTP, than to send
> > you the information to publish, with the associated time lag etc?
> 
> Your solution requires every site to set HTTP response headers, or every
> ISP to contact their customers to get the correct values for the DNS
> records.
>
> My solution involves communicating with a far smaller group.

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.

> > You've asked for the same thing: for administrators of certain domains
> > to provide you with information about independent or related users of
> > those subdomains.
> 
> But the two plans are talking about two different sets of admins, one
> vastly larger than the other.

See above.

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

Re: [DNSOP] Public Suffix List

[Stephane Bortzmeyer]

On Mon, Jun 09, 2008 at 04:51:02PM -0700,
 Paul Hoffman <[EMAIL PROTECTED]> 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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Jeroen Massar]

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

Stephane Bortzmeyer wrote:

On Mon, Jun 09, 2008 at 04:53:01PM -0500,
 Ted Lemon <[EMAIL PROTECTED]> 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:

[..]

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



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

Re: [DNSOP] Public Suffix List

[Stephane Bortzmeyer]

On Mon, Jun 09, 2008 at 04:53:01PM -0500,
 Ted Lemon <[EMAIL PROTECTED]> 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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Public Suffix List

[Paul Hoffman]

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

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

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

Re: [DNSOP] Public Suffix List

[Doug Barton]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

Yngve and Gerv,

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [DNSOP] Public Suffix List

[Ted Lemon]

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

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

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

Re: [DNSOP] Public Suffix List

[Andrew Sullivan]

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

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

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

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

Best regards,

A

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

Re: [DNSOP] Public Suffix List

[Stephane Bortzmeyer]

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

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

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

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

Re: [DNSOP] Public Suffix List

[Stephane Bortzmeyer]

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

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

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

Re: [DNSOP] Public Suffix List

[Phil Regnauld]

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

Less radical...

about:config in firefox

search for IDN

disable network.IDN.whitelist for all listed TLDs.

Cheers,
Phil

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

Re: [DNSOP] Public Suffix List

[Joe Abley]

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

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

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


Joe

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

Re: [DNSOP] Public Suffix List

[Stephane Bortzmeyer]

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

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

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

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

Re: [DNSOP] Public Suffix List

[Stephane Bortzmeyer]

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

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

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

Re: [DNSOP] Public Suffix List

[Stephane Bortzmeyer]

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

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

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

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

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

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


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

Re: [DNSOP] Public Suffix List

[Paul Hoffman]

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

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

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

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

Re: [DNSOP] Public Suffix List

[Kim Davies]

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

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

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

kim

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

Re: [DNSOP] Public Suffix List

[David Conrad]

Gervase,

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

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

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

Regards,
-drc

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

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

Re: [DNSOP] Public Suffix List

[Eric Brunner-Williams]

Gervase,

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

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

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

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

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

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

Re: [DNSOP] Public Suffix List

[Eric Brunner-Williams]

Gervase,

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

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

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

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

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

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

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

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

Eric

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

___
DNSOP mailing list