Public Suffix List: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
(→‎Outreach to Registries: added two tech day presentations to TLDs (gTLD, ccTLD) and the OCTO 11 document from ICANN as well as SAC70 from the ICANN Security and Stability Advisory Committee)
 
(19 intermediate revisions by 6 users not shown)
Line 1: Line 1:
The effective TLD list is an attempt to build a database of top-level domains and their policies on domain registrations at different levels.
The Public Suffix List (PSL) is an attempt to build a database of ''Top-Level Domains'' (TLDs) including the respective registry's policies on domain registrations at different levels.


Currently, most browsers, including Mozilla ones, use an algorithm which basically only denies setting cookies for top-level domains with no dots (e.g. com or org). However, this does not work for top-level domains where only third-level registrations are allowed (e.g. co.uk). In these cases, websites can set a cookie for co.uk which will be passed onto every website registered under co.uk.
While the Public Suffix List has no opinion on alternative root systems, the list recognizes as authoritative and complies with [http://www.icann.org/en/about/unique-authoritative-root ICP-3: A Unique, Authoritative Root for the DNS] (ICANN, September 2001), allowing TLDs under the ICANN Root as well as inclusive sub-domain entries, and cookie apexes that comply with ICP-3 in a non-discriminatory manner.


Clearly, this is a security risk as it allows websites other than the one setting the cookie to read it, and therefore potentially extract sensitive information.
Entries addition/updates/deletions are put through a loose process of vetting, curation, and validation by the community volunteers who help maintain the list.
 
== Purpose(s) ==
Previously, browsers used an algorithm which basically only denied setting wide-ranging cookies for top-level domains with no dots (e.g. com or org). However, this did not work for top-level domains where only third-level registrations are allowed (e.g. co.uk). In these cases, websites could set a cookie for co.uk which will be passed onto every website registered under co.uk.
 
Clearly, this was a security risk as it allowed websites other than the one setting the cookie to read it, and therefore potentially extract sensitive information.


Since there is no algorithmic method of finding the highest level at which a domain may be registered for a particular top-level domain (the policies differ with each registry), the only method is to create a list of all top-level domains and the level at which domains can be registered. This is the aim of the effective TLD list.
Since there is no algorithmic method of finding the highest level at which a domain may be registered for a particular top-level domain (the policies differ with each registry), the only method is to create a list of all top-level domains and the level at which domains can be registered. This is the aim of the effective TLD list.


As well as being used to prevent cookies from being set when they shouldn't be, the list can also potentially be used for other applications where the registry controlled and privately controlled parts of a domain name need to be known, for example when grouping by top-level domains.
As well as being used to prevent cookies from being set where they shouldn't be, the list can also potentially be used for other applications where the registry controlled and privately controlled parts of a domain name need to be known, for example when grouping by top-level domains.


== Data collection ==
== Website ==


Maintaining an up-to-date list of all top-level domains and policies is clearly a vast task, and therefore each registry will be asked to maintain their own section of the database and post any changes to the effective TLD list maintenance team, who will then merge it with the master database and make the updated file available at regular intervals.
The website for the Public Suffix List is at [http://publicsuffix.org/ http://publicsuffix.org/].
Updates and maintainence is conducted on GitHub at the following URL: [https://github.com/publicsuffix/list/ https://github.com/publicsuffix/list/]


Once details have been sorted out, registries for all top-level domains will be contacted and directed to a website that will inform them of the intentions of the effective TLD list, how to participate and formats for data files.
== Registries ==


== Tasks to do ==
Maintaining an up-to-date list of all top-level domains and policies is clearly a vast task, and therefore each registry has been asked to maintain their own section of the database and email any changes to the effective TLD list maintenance team, who will then merge it with the master database.


# Choose a name for the effective TLD list to present to the registries
# Make the website for registries
# Sort out a contact email address
# Define the file format for the effective TLD list
# Find a way of easily contacting all registries
# Author an email and send it to all registries
# Monitor the email address regularly and manage changes
# Update pages below marked with (update)
# Make the effective TLD list file available to other browser manufacturers


== Possible names ==
=== Outreach to Registries ===
Some outreach has been performed to help expand the awareness of the Public Suffix List within the ICANN Community - to bridge the divide between registries and the PSL community.  Here are some presentations that have been made to the ccTLD community and to gTLDs at ICANN meetings since 2011.
* ccTLD Tech Day, June 2011 - ICANN #41, Singapore [http://ccnso.icann.org/ar/node/25139]
* ccTLD Tech Day, November 2013 - ICANN #48, Buenos Aires, Argentina [http://buenosaires48.icann.org/en/schedule/mon-tech/presentation-psl-18nov13-en]
* Tech Day, March 2017 - ICANN #58, Copenhagen, Denmark
* Tech Day, March 2019 - ICANN #64, Kobe, Japan


* Public Suffix List
=== ICANN Reviews ===
* Verified TLD List
====The ICANN Office of the CTO (OCTO)====
* Authoritative TLD List
Members of the OCTO collaborated with the PSL Volunteers to make a document available
that helps inform Registries on the process of reviewing and maintaining their PSL entries.
* OCTO 11 [[user:PaulHoffman]]: "The Public Suffix List: A Guide for TLD Administrators" [https://www.icann.org/en/system/files/files/octo-011-18may20-en.pdf]


== Possible content ==
==== ICANN Security and Stability Advisory Committee (SSAC) ====
ICANN has a Security and Stability Advisory Committee [https://www.icann.org/resources/pages/ssac-role-2018-02-06-en], with the role of advising the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems.


* What is the Effective TLD List?
They created a working group which convened 2014-2015 to review the use of Public Suffix Lists, and how to impliment them within software, in security, and in language libraries and other systems.  This ultimately resulted in '''SAC070''', an advisory on the use of Public Suffix Lists.
* Format to submit records and examples
* Email address for submissions


== Things to remember ==
Although it is slightly dated and not current and entirely applicable to the Mozilla PSL, it does contain good practices and advise.  Please familiarize yourself with their findings and consider them in your use of these lists. The review included [[User:Jothan|u:jothan]] and [[User:Gerv]]


* A single point of contact for all browser makers
* SAC070 (In Japanese / 日本語) [https://www.icann.org/ja/system/files/files/sac-070-ja.pdf]
* Clear, obvious instructions as to what information to submit
* SAC070 (In English) [https://www.icann.org/en/system/files/files/sac-070-en.pdf]
* Clear documentation of the format to use


== Links ==
== Links ==
* [http://publicsuffix.org/ The Public Suffix List]
* [http://www.icann.org/en/about/unique-authoritative-root ICP-3: A Unique, Authoritative Root for the DNS]


=== TLD Lists ===
=== TLD Lists ===


* [http://lxr.mozilla.org/mozilla/source/netwerk/dns/src/effective_tld_names.dat?raw=1 Current Effective TLD List] (update)
* [http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1 Current Effective TLD List] (use [http://publicsuffix.org/ http://publicsuffix.org/] instead)
* [http://en.wikipedia.org/wiki/List_of_Internet_top-level_domains Wikipedia: List of Internet top-level domains]
* [http://en.wikipedia.org/wiki/List_of_Internet_top-level_domains Wikipedia: List of Internet top-level domains]
* [http://wiki.mozilla.org/TLD_List TLD list - MozillaWiki] (update)
* [http://www.iana.org/domains/root/db/ IANA Root Zone Database]


=== Mozilla Bug Reports ===
=== Mozilla Bug Reports ===
Line 58: Line 62:
* [https://bugzilla.mozilla.org/show_bug.cgi?id=252342 Bug 252342 - fix cookie domain checks to not allow .co.uk]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=252342 Bug 252342 - fix cookie domain checks to not allow .co.uk]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=342314 Bug 342314 - Need effective-TLD file]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=342314 Bug 342314 - Need effective-TLD file]
=== Internet Drafts ===
* [http://files.myopera.com/yngve/blog/draft-pettersen-dns-cookie-validate-00.txt Enhanced validation of domains for HTTP State Management Cookies using DNS]
* [http://files.myopera.com/yngve/blog/draft-pettersen-subtld-structure-00.txt The TLD Subdomain Structure Protocol and its use for Cookie domain validation]


=== Articles ===
=== Articles ===
Line 69: Line 68:
* [http://weblogs.mozillazine.org/gerv/archives/2006/10/dns_structure.html Hacking for Christ: DNS Structure]
* [http://weblogs.mozillazine.org/gerv/archives/2006/10/dns_structure.html Hacking for Christ: DNS Structure]
* [http://weblogs.mozillazine.org/gerv/archives/2007/01/effective_tld_list_help_wanted.html Hacking for Christ: "Effective TLD" List: Help Wanted]
* [http://weblogs.mozillazine.org/gerv/archives/2007/01/effective_tld_list_help_wanted.html Hacking for Christ: "Effective TLD" List: Help Wanted]
* [http://my.opera.com/yngve/blog/show.dml/267415 How to make sure the cookies don't burn your fingers? - Implementer's notes - by Yngve Nysaeter Pettersen]
* [https://vivaldi.net/blogs/entry/how-to-make-sure-the-cookies-don-t-burn-your-fingers How to make sure the cookies don't burn your fingers? - Implementer's notes - by Yngve Nysaeter Pettersen]

Latest revision as of 22:18, 19 November 2020

The Public Suffix List (PSL) is an attempt to build a database of Top-Level Domains (TLDs) including the respective registry's policies on domain registrations at different levels.

While the Public Suffix List has no opinion on alternative root systems, the list recognizes as authoritative and complies with ICP-3: A Unique, Authoritative Root for the DNS (ICANN, September 2001), allowing TLDs under the ICANN Root as well as inclusive sub-domain entries, and cookie apexes that comply with ICP-3 in a non-discriminatory manner.

Entries addition/updates/deletions are put through a loose process of vetting, curation, and validation by the community volunteers who help maintain the list.

Purpose(s)

Previously, browsers used an algorithm which basically only denied setting wide-ranging cookies for top-level domains with no dots (e.g. com or org). However, this did not work for top-level domains where only third-level registrations are allowed (e.g. co.uk). In these cases, websites could set a cookie for co.uk which will be passed onto every website registered under co.uk.

Clearly, this was a security risk as it allowed websites other than the one setting the cookie to read it, and therefore potentially extract sensitive information.

Since there is no algorithmic method of finding the highest level at which a domain may be registered for a particular top-level domain (the policies differ with each registry), the only method is to create a list of all top-level domains and the level at which domains can be registered. This is the aim of the effective TLD list.

As well as being used to prevent cookies from being set where they shouldn't be, the list can also potentially be used for other applications where the registry controlled and privately controlled parts of a domain name need to be known, for example when grouping by top-level domains.

Website

The website for the Public Suffix List is at http://publicsuffix.org/. Updates and maintainence is conducted on GitHub at the following URL: https://github.com/publicsuffix/list/

Registries

Maintaining an up-to-date list of all top-level domains and policies is clearly a vast task, and therefore each registry has been asked to maintain their own section of the database and email any changes to the effective TLD list maintenance team, who will then merge it with the master database.


Outreach to Registries

Some outreach has been performed to help expand the awareness of the Public Suffix List within the ICANN Community - to bridge the divide between registries and the PSL community. Here are some presentations that have been made to the ccTLD community and to gTLDs at ICANN meetings since 2011.

  • ccTLD Tech Day, June 2011 - ICANN #41, Singapore [1]
  • ccTLD Tech Day, November 2013 - ICANN #48, Buenos Aires, Argentina [2]
  • Tech Day, March 2017 - ICANN #58, Copenhagen, Denmark
  • Tech Day, March 2019 - ICANN #64, Kobe, Japan

ICANN Reviews

The ICANN Office of the CTO (OCTO)

Members of the OCTO collaborated with the PSL Volunteers to make a document available that helps inform Registries on the process of reviewing and maintaining their PSL entries.

ICANN Security and Stability Advisory Committee (SSAC)

ICANN has a Security and Stability Advisory Committee [4], with the role of advising the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems.

They created a working group which convened 2014-2015 to review the use of Public Suffix Lists, and how to impliment them within software, in security, and in language libraries and other systems. This ultimately resulted in SAC070, an advisory on the use of Public Suffix Lists.

Although it is slightly dated and not current and entirely applicable to the Mozilla PSL, it does contain good practices and advise. Please familiarize yourself with their findings and consider them in your use of these lists. The review included u:jothan and User:Gerv

  • SAC070 (In Japanese / 日本語) [5]
  • SAC070 (In English) [6]

Links

TLD Lists

Mozilla Bug Reports

Articles