Re: [DNSOP] Public Suffix List

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