Re: [DNSOP] Public Suffix List

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

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

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

Finally, I'd like to make a suggestion that I know you will reject, but
I feel compelled to make it anyway. :)  You could solve this problem
much more easily by making the default policy to deny cookies, and ask
the user to choose to accept cookies from domains that they have a trust
relationship with. I have been using the CookieSafe extension for a long
time now (recently switched to CookieSafe Lite by the same author) and
it works great for me. If that functionality were included in the base
and enabled by default, it'd be a whole new world.
https://addons.mozilla.org/en-US/firefox/search?q=cookiesafe&cat=1%2C12

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

Regards,

Doug

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEAREDAAYFAkhNqHsACgkQyIakK9Wy8Pt3XQCgxzi1Pvv91eTyfPTEUBT7Zi95
ZMAAoLa3wDtmdb/nvLybhsjhCd0aeNF/
=WdS0
-----END PGP SIGNATURE-----
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop