Re: wrt deprecating eTLD+1 (was: Can we remove the PSL dependency?)

Quoting Richard Barnes <rbarnes@mozilla.com>:
>
> On Thu, Jul 28, 2016 at 6:06 PM, <jeff.hodges@kingsmountain.com> wrote:
>
>>
>> Quoting Richard Barnes <rbarnes@mozilla.com>:
>>
>>>
>>> ... this spec ... is dependent on the Public Suffix List (via eTLD+1), a
>>> technology that we are trying hard to deprecate.
>>>
>>
>> hm, by "we" do you mean browser vendors?  Or other parties?   Or other
>> parties possibly including browser vendors?
>>
>> If browser vendors are trying hard to deprecate the Cookie Same Origin
>> Policy's dependence upon the eTLD+1 notion and its manifestation as the
>> so-called Public Suffix List, it'd be great if you could point to or share
>> information regarding such.
>>
>
> See, e.g.:
>
> https://datatracker.ietf.org/wg/dbound/charter/ (developing PSL
> alternatives)
> https://tools.ietf.org/html/draft-ietf-httpbis-cookie-prefixes-00#section-3.2
> (removing the PSL dependency from cookies)
> https://github.com/w3c/webappsec-secure-contexts/issues/10 (forbidding
> document.domain usage, which requires the PSL, with [SecureContext])
>
> "Trying hard" might be an overstatement.

indeed, hence my questions. note that the ietf dbound working group  
chairs had this to say recently...

     ... We perceive it to be unlikely that a solution produced by this
     working group for the web security issue would be adopted in short
     order by any of the browser producers.  They simply have not
     expressed a desire to contribute and adopt, or even concur that
     there's a serious problem that needs to be solved.  ...

     https://www.ietf.org/mail-archive/web/dbound/current/msg00665.html

     [ In my and Andrew Sullivan's view, the msg cited above is proposing
       to unfortunately settle for a sub-optimal approach due to the
       observed lack of interest on the part of browser folk, as we
       expressed in reply to the above msg. ]


> Cookies and document.domain have
> too much usage to be able to make much change very quickly.

agreed, and that is why we decided, pre-W3C-submission, that it is  
extremely important to rely upon eTLD+1 for notions of authn.


> But it
> certainly seems to me that the general wisdom right now is that when we
> have relied on the PSL in the past, it has had bad repercussions, and we
> shouldn't do it again.

relying upon the PSL (aka eTLD list), from a specification  
perspective, is only a "may" or "should" (c.f. RFC6265 [1], and [2])  
in specification practice, which will allow implementations of the  
specs to transition to "something else" (if we ever devise something  
else), even though it is present implementation practice.

hth,

=JeffH

[1] RFC6265 aka "the cookie spec"
     https://tools.ietf.org/html/rfc6265#section-5.3, see NOTE in step 5...

             NOTE: ... 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/>.

..note that PSL is effectively an example as it is referred to as  
"..such as.."


[2] http://identitymeme.org/http-cookie-processing-algorithm-etlds/

Received on Tuesday, 2 August 2016 08:23:01 UTC