Subject: [http-state] Closing Ticket 3: Public Suffixes

From: Adam Barth <[email-masked]>
Date: Thu, 21 Jan 2010 16:09:41 -0800

Discussion about Ticket 3 seems to have quieted down.

== Summary of Discussion ==

No one supported the idea of a specific hard-coded list of public suffixes.

Corvid supported the approach of a recommend heuristic, but Yngve
argued that the proposed heuristic was sufficiently wrong as to be
harmful.

No one supported the idea of ignoring the issue entirely.

Yngve proposed the idea of using DNS queries for A records to deduce
the public suffix list but later agreed that NX ISPs (like comcast)
could cause this approach to fail in the future.

Yngve proposed reversing the domain semantics, but this is too great a
change to the semantics of the protocol for phase one.

Yngve proposed adding a $origin attribute to the cookie-string, but
this alters the syntax of the protocol, which is forbidden in phase
one.

The discussion generated a bunch of good idea that we should revisit
in phase two.

== Specification Change ==

[[
diff --git a/drafts/cookie.xml b/drafts/cookie.xml
index 5b1e393..7765b10 100644
--- a/drafts/cookie.xml
+++ b/drafts/cookie.xml
@@ -748,6 +748,22 @@ mystery         = <anything except a delimiter>
             domain-attribute, ignore the cookie entirely and abort these
             steps.</t>

+            <t>If the user agent is configured to use a "public suffix" list
+            and the domain-attribute is a public suffix, ignore the cookie
+            entirely and abort these steps.
+            <list style="empty">
+              <t>NOTE: A "public suffix" is a domain that is controlled by a
+              public registry, such as "com", "co.uk", and "pvt.k12.wy.us".
+              This step is essential for preventing attacker.com from
+              disrupting the integrity of example.com by setting a cookie with
+              a Domain attribute of "com". Unfortunately, the set of public
+              suffixes (also known as "registry controlled domains") changes
+              over time. If feasible, user agents SHOULD use an up-to-date
+              public suffix list, such as the one maintained by the Mozilla
+              project at http://publicsuffix.org/.</t>
+            </list>
+            </t>
+
             <t>Set the cookie's host-only-flag to false.</t>

             <t>Set the cookie's domain to the domain-attribute.</t>
]]

I've pushed a new version of the draft that includes this change:

http://www.ietf.org/id/draft-ietf-httpstate-cookie-02.txt

We can re-open the issue if someone presents material new information.

Adam

---

From: "Anne van Kesteren" <[email-masked]>
Date: Sat, 30 Jan 2010 17:28:16 +0100

> We can re-open the issue if someone presents material new information.

You seem to be including a non-normative part of the specification with  
normative language in it. (I.e. the SHOULD in the NOTE.) That seems wrong.  
Using "strongly encouraged" or some such is probably better.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Lisa Dusseault <[email-masked]>
Date: Sat, 30 Jan 2010 09:16:20 -0800

Just to clear up the "rules", a NOTE is not formally non-normative.
It can be a normative part of the spec -- the language "NOTE" can be
used informally to draw attention of the reader or organize thoughts
into main points and notable tangents.

Lisa

On Sat, Jan 30, 2010 at 8:28 AM, Anne van Kesteren <[email-masked]> wrote:
> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state
>

---

From: Ian Hickson <[email-masked]>
Date: Sat, 30 Jan 2010 21:50:45 +0000 (UTC)

On Sat, 30 Jan 2010, Anne van Kesteren wrote:
> normative language in it. (I.e. the SHOULD in the NOTE.) That seems 
> wrong. Using "strongly encouraged" or some such is probably better.

Actually right now the draft doesn't reference 2119, so it's not clear 
what the conformance criteria are. I would recommend adding a "Conformance 
Criteria" section that lists the conformance classes and the conventions 
used for specifying conformance criteria. HTML5 has a pretty thorough such 
section which can be used for inspiration:

   http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#conformance-requirements

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'