RFC6265bis: Address Dnsdir issues

The DNS Directorate review, https://lists.w3.org/Archives/Public/ietf-http-wg/2025JanMar/0140.html, surfaced a number of issues.

Primarily this PR:

- Adds a new name resolution section to clarify the spec's stance on name resolution (ASCII only, DNS default)
- Tightens the canonicalization sub-algorithm to only operate on the expected label types
- Adds a new PSL security consideration section

Author: sbingler

draft-ietf-httpbis-rfc6265bis.md

@@ -351,9 +351,8 @@ A domain's "public suffix" is the portion of a domain that is controlled by a
 public registry, such as "com", "co.uk", and "pvt.k12.wy.us". A domain's
 "registrable domain" is the domain's public suffix plus the label to its left.
 That is, for `https://www.site.example`, the public suffix is `example`, and the
-registrable domain is `site.example`. Whenever possible, user agents SHOULD
-use an up-to-date public suffix list, such as the one maintained by the Mozilla
-project at {{PSL}}.
+registrable domain is `site.example`. See {{public-suffix-list-security}} for security
+considerations.
 
 The term "request", as well as a request's "client", "current url", "method",
 "target browsing context", and "url list", are defined in {{FETCH}}.
@@ -364,6 +363,17 @@ cookies, such as a web browser API that exposes cookies to scripts.
 The term "top-level navigation" refers to a navigation of a top-level
 traversable.
 
+## Name Resolution System
+
+While this document does not strictly prescribe any specific name resolution
+system for use with cookies it does require that the system uses only
+{{USASCII}} characters or uses an ASCII-compatible encoding (ACE). As the Domain
+Name System (DNS) is a typical and conventional example this document will
+reference name resolution in terms of DNS.
+
+Name resolution systems that directly expose non-ASCII characters, such as
+Unicode, are out of scope of this document.
+
 # Overview
 
 This section outlines a way for an origin server to send state information to a
@@ -737,11 +747,10 @@ user agent).
 
 The Domain attribute specifies those hosts to which the cookie will be sent.
 For example, if the value of the Domain attribute is "site.example", the user
-agent will include the cookie in the Cookie header field when making HTTP requests to
-site.example, www.site.example, and www.corp.site.example. (Note that a
-leading %x2E ("."), if present, is ignored even though that character is not
-permitted.)  If the server omits the Domain attribute, the user agent
-will return the cookie only to the origin server.
+agent will include the cookie in the Cookie header field when making HTTP
+requests to site.example, www.site.example, and www.corp.site.example. If the
+server omits the Domain attribute, the user agent will return the cookie only
+to the origin server.
 
 WARNING: Some existing user agents treat an absent Domain attribute as if the
 Domain attribute were present and contained the current host name. For
@@ -1051,12 +1060,20 @@ A canonicalized host name is the string generated by the following algorithm:
 
 1.  Convert the host name to a sequence of individual domain name labels.
 
-2.  Convert each label that is not a Non-Reserved LDH (NR-LDH) label, to an
-    A-label (see {{Section 2.3.2.1 of RFC5890}} for the former and latter).
+2. All labels must be one of U-label, A-label, or Non-Reserved LDH (NR-LDH)
+   label (see {{Section 2.3.1 of RFC5890}}). If any label is not one of these
+   then abort this algorithm and fail to canonicalize the host name.
+
+3.  Convert each U-label to an A-label (see {{Section 2.3.2.1 of RFC5890}}).
 
-3.  Concatenate the resulting labels, separated by a %x2E (".") character.
+4. If any label is a Fake A-label then abort this algorithm and fail to
+   canonicalize the host name.
 
-### Domain Matching
+5.  Concatenate the resulting labels, separated by a %x2E (".") character.
+
+### Domain Matching {#domain-matching}
+
+Note: This algorithm expects that both inputs are canonicalized.
 
 A string domain-matches a given domain string if at least one of the following
 conditions hold:
@@ -1688,8 +1705,12 @@ user agent MUST process the cookie as follows:
 9.  If the user agent is configured to reject "public suffixes" and the
     domain-attribute is a public suffix:
 
-    1.  If the domain-attribute is identical to the canonicalized
-        request-host:
+    1. Let request-host-canonical be the canonicalized request-host.
+
+    2. If request-host fails to be canonicalized then abort this algorithm and
+       ignore the cookie entirely.
+
+    3.  If the domain-attribute is identical to the request-host-canonical:
 
         1.  Let the domain-attribute be the empty string.
 
@@ -1702,8 +1723,8 @@ user agent MUST process the cookie as follows:
 
 10. If the domain-attribute is non-empty:
 
-    1.  If the canonicalized request-host does not domain-match the
-        domain-attribute:
+    1.  If request-host-canonical does not domain-match
+        (see {{domain-matching}}) the domain-attribute:
 
         1.  Abort this algorithm and ignore the cookie entirely.
 
@@ -1717,7 +1738,7 @@ user agent MUST process the cookie as follows:
 
     1.  Set the cookie's host-only-flag to true.
 
-    2.  Set the cookie's domain to the canonicalized request-host.
+    2.  Set the cookie's domain to request-host-canonical.
 
 11. If the cookie-attribute-list contains an attribute with an
     attribute-name of "Path", set the cookie's path to attribute-value of
@@ -1751,8 +1772,8 @@ user agent MUST process the cookie as follows:
 
     2.  Their secure-only-flag is true.
 
-    3.  Their domain domain-matches the domain of the newly-created cookie, or
-        vice-versa.
+    3.  Their domain domain-matches (see {{domain-matching}}) the domain of the
+        newly-created cookie, or vice-versa.
 
     4.  The path of the newly-created cookie path-matches the path of the
         existing cookie.
@@ -1926,18 +1947,23 @@ is "non-HTTP".
 Given a cookie store and a retrieval, the following algorithm returns a
 cookie-string from a given cookie store.
 
-1. Let cookie-list be the set of cookies from the cookie store that meets all
+1. Let retrieval-host-canonical be the canonicalized host of the retrieval's URI.
+
+2. If the host of the retrieval's URI fails to be canonicalized then abort this
+   algorithm.
+
+3. Let cookie-list be the set of cookies from the cookie store that meets all
    of the following requirements:
 
    * Either:
 
-     *   The cookie's host-only-flag is true and the canonicalized
-         host of the retrieval's URI is identical to the cookie's domain.
+     *   The cookie's host-only-flag is true and retrieval-host-canonical is
+         identical to the cookie's domain.
 
      Or:
 
-     *   The cookie's host-only-flag is false and the canonicalized
-         host of the retrieval's URI domain-matches the cookie's domain.
+     *   The cookie's host-only-flag is false and retrieval-host-canonical
+         domain-matches (see {{domain-matching}}) the cookie's domain.
 
      *  The cookie's domain is not a public suffix, for user agents configured
         to reject "public suffixes".
@@ -1971,7 +1997,7 @@ cookie-string from a given cookie store.
      * The target browsing context of the HTTP request associated with the
        retrieval is the active browsing context or a top-level traversable.
 
-2. The user agent SHOULD sort the cookie-list in the following order:
+4. The user agent SHOULD sort the cookie-list in the following order:
 
    *  Cookies with longer paths are listed before cookies with shorter
       paths.
@@ -1983,10 +2009,10 @@ cookie-string from a given cookie store.
    reflects common practice when this document was written, and, historically,
    there have been servers that (erroneously) depended on this order.
 
-3. Update the last-access-time of each cookie in the cookie-list to the
+5. Update the last-access-time of each cookie in the cookie-list to the
    current date and time.
 
-4. Serialize the cookie-list into a cookie-string by processing each cookie
+6. Serialize the cookie-list into a cookie-string by processing each cookie
    in the cookie-list in order:
 
    1.  If the cookies' name is not empty, output the cookie's name followed by
@@ -2471,6 +2497,17 @@ necessarily provides fewer protections against CSRF. Ultimately, the provision
 of such an enforcement mode should be seen as a temporary, transitional measure
 to ease adoption of "Lax" enforcement by default.
 
+## Public Suffix List {#public-suffix-list-security}
+
+The boundaries of cookies depend on a site's "registrable domain" which in turn
+depends on the public suffix of the domain.
+
+Whenever possible, user agents SHOULD use an up-to-date public suffix list,
+such as the one maintained by the Mozilla project at {{PSL}}.
+
+Failure to do so could allow malicious or sensitive cookies to leak between
+registrable domains.
+
 # IANA Considerations
 
 ## Cookie {#iana-cookie}