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

On Tue, Aug 2, 2016 at 3:55 AM, <jeff.hodges@kingsmountain.com> wrote:

>
> 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.


I'm not sure how you arrive at that conclusion.  What I meant was that for
new stuff like this, it's better to avoid the PSL dependency than to try to
claw it back later.


>
> 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.
>

That's even worse! :)  If devs are going to write code to this
specification, they need to know in which cross-origin cases things will
work.  So whether it's eTLD+1, same-origin, or something else, we need to
lock it in now.  And given past experience with evolving the web, it's far,
far easier to start with something conservative and make it work in more
cases over time, rather than having to break things when we realize we were
too liberal.

--Richard


>
> 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/
>
>
>
>
>