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

I'll point out that the webauthn spec is currently strictly enforcing
same-origin (where origin is defined by scheme-host-port) by requiring that
the so-defined origin is included in the client data. An assertion
generated on one origin won't be valid on another origin.

The PSL dependency is there simply as a recommendation on how to scope key
pairs, meaning that two origins within the same public suffix may know the
client by the same public key. See my comment on the original github thread
as to why that is:
https://github.com/w3ctag/spec-reviews/issues/97#issuecomment-175766580

Dirk.


On Tue, Aug 2, 2016 at 7:28 AM Richard Barnes <rbarnes@mozilla.com> wrote:

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