Re: [http-state] Ticket 3: Public Suffixes

["Yngve N. Pettersen (Developer Opera Software ASA)" <[e-mail]>]

On Sat, 16 Jan 2010 16:23:49 +0100, Daniel Stenberg <[e-mail]> wrote:

> On Sat, 16 Jan 2010, Yngve N. Pettersen (Developer Opera Software ASA)  
> wrote:
>
>> Alternative 4: Use a DNS based heuristic by only allowing cookies set  
>> to domains that have an IP address defined. If there is no IP address,  
>> remove the domain attribute
>>
>>  See my draft describing Opera's implementation:  
>> http://www.ietf.org/internet-drafts/draft-pettersen-dns-cookie-validate-05.txt
>
> That's a 404, but I found it here:

Sorry, thought it was still valid. Will renew shortly. Archive copies are  
also available from my homepage.

>
>    http://tools.ietf.org/html/draft-pettersen-dns-cookie-validate-05
>
> ... so Opera is actually using this now?

We have been using this method since v3.6, about 9-10 years.

> I know for a fact that there is at least one domain in .se that is  
> actually using one of the documented suffixlist domains for a company  
> (apparently it was baught and handed out more or less by mistake  
> but...). This actually makes it possible to resolve the name to an IP   
> even though browsers using the suffixlist will treat it as invalid. This  
> would speak FOR this concept. But likewise I can imagine there are sites  
> that own example.com but without IP and they use two subdomain sites  
> like foo.example.com and bar.example.com that both set cookies for  
> example.com...

These kind of sites is what is causing occasional problems. In Opera they  
can be worked around by setting an allow filter for the domain.

IMO this problem is alleviated by the common procedure by sites to use  
example.com as an alias for www.example.com.

> Unfortunately I don't have any particularly good idea on how to include  
> all this in our spec. I think perhaps the only thing to do is to include  
> a discussion about the problems and mention exactly this: a few ways  
> that current implmentations use.

I might note that the DNSop community have strong opinions against  
assuming anything about different levels of the DNS hierarchy. (My  
summary: They don't like the current method of domain specification in  
cookies, and they don't like public suffix)

>> Alternative 5: (which require an extensive change of the cookie  
>> specification)
>
> Right, but if changing the spec would even be considered we could easily  
> come up with many more alternatives... .-)

Some have suggested that clients probe servers for permission before  
sending cookies.

I think that long term domain owners should have a way define policies  
(such as cookies, scripting etc.) for their domain, possibly using a file  
format similar to what I have proposed for the public suffix system.

One way to proceed, what might be called alternative 6 in combination with  
other requirements, is that each cookie is associated with its origin  
hostname, for example in the form of a "$origin=server.example.com" value.  
This would allow the server to distinguish between valid and invalid  
cookies. This does however require an extension of the Cookie header  
syntax and semantics. It would IMO be easy to implement, and servers  
should ignore the values if they do not understand them.

Another way to proceed, which requires more changes to the spec, would be  
to deprecate "domain" for parent domain, and encourage adoption of  
domain=.hostname and/or a "subdomain=true" attribute, in combination with  
the $origin attribute



-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************