[gnso-rpm-wg] Possible Technical Bug in URS implementations

[Kathy Kleiman]

Hi George,

You're absolutely right. One of my browsers did not resolve to the 
bcg.app site. Another of my browsers did resolve and properly showed the 
suspension message: "The Domain Name you’ve entered is not available. It 
has been taken down as a result of dispute resolution proceedings 
pursuant to the Uniform Rapid Suspension System (URS) or .us Rapid 
Suspension System (usRS) Procedure and Rules."

I think the policy is pretty clear, but the implementation is definitely 
lacking.

/Staff, could you kindly add this to the list of issues we should be 
considered on the URS? /Obviously, if a domain name is suspended, 
browsers should know.

Tx you, George!

Best, Kathy


On 6/4/2018 6:54 PM, George Kirikos wrote:
> The first URS case involving a .app domain was decided (in favour of
> the complainant), for bcg.app.
>
> http://www.adrforum.com/domaindecisions/1785973D.htm
>
> As I predicted earlier in this thread, the technical bug is evident,
> as there's no HTTPS page for bcg.app, i.e.
>
> https://bcg.app/
>
> doesn't serve up the suspension page. If one attempts to load the HTTP
> version of the page VIA AN OLDER BROWSER (i.e. one that doesn't
> observe the HSTS preload list), one can see the standard suspension
> page at:
>
> http://bcg.app/
>
> However, for a modern browser (e.g. the latest version of Chrome) that
> is enforcing the HSTS preload list which doesn't permit non-HTTPS
> pages for .app, the suspension page isn't loading.
>
> The need for either a better policy (one that more clearly requires
> both HTTPS and HTTP versions of the suspension page) and/or better
> implementation by the URS providers, is evident.
>
> Sincerely,
>
> George Kirikos
> 416-588-0269
> http://www.leap.com/
>
>
> On Wed, May 23, 2018 at 3:17 PM, George Kirikos <icann at leap.com> wrote:
>> Just to followup, according to the search tool at NAF:
>>
>> http://www.adrforum.com/SearchDecisions
>>
>> there are several URS disputes in progress for .app domains, including:
>>
>> bcg.app
>> skx.app
>> oliverwyman.app
>> skechers.app
>>
>> We should know relatively soon whether the suspension pages for these
>> domains (if decided in favour of the complainants) are served via
>> HTTPS, to be compatible with the HSTS preload setting that Google has
>> applied to the entire .app TLD.
>>
>> Sincerely,
>>
>> George Kirikos
>> 416-588-0269
>> http://www.leap.com/
>>
>>
>>
>> On Thu, May 17, 2018 at 8:31 AM, George Kirikos <icann at leap.com> wrote:
>>> Six days and no replies.....I'll just post the issue here, in the
>>> hopes it gets to the right people (and to highlight the policy issue).
>>>
>>> As members of this PDP are aware, after a complainant wins a URS
>>> dispute, the URS provider is supposed to create a suspension page for
>>> the domain name. For example, at 2 of the 3 URS providers (the 3rd
>>> doesn't seem to have any active suspensions at the moment):
>>>
>>> MFSD: http://reima.top
>>> NAF: http://wikipedia.kim
>>>
>>> However, Google recently launched .app, which has a unique feature,
>>> namely that the entire TLD is on the HSTS preload list:
>>>
>>> https://get.app
>>>
>>> "The .app top-level domain is included on the HSTS preload list,
>>> making HTTPS required on all connections to .app websites — no
>>> individual HSTS registration or configuration required."
>>>
>>> This means that unless the URS providers launch HTTPS versions of
>>> their suspension pages, the HTTP version won't be accessible for .app
>>> domains. Given the relatively high number of .app domains that were
>>> registered already, one would expect .app URS complaints to be
>>> forthcoming.
>>>
>>> One can easily check that the 2 URS providers don't appear to be
>>> serving HTTPS versions of their suspension pages at present, see:
>>>
>>> MFSD: https://reima.top (clicking through the SSL warnings takes ones
>>> to a MFSD page)
>>> NAF: https://wikipedia.kim (connection refused; presumably their
>>> webserver isn't listening at that port)
>>>
>>> As for ICANN policy, the URS Technical Requirements at:
>>>
>>> http://newgtlds.icann.org/en/applicants/urs/tech-requirements-17oct13-en.pdf
>>>
>>> merely say, on page 1:
>>>
>>> "A URS Suspended domain name will be redirected to a webpage that
>>> mentions that the domain name has been suspended because of a URS
>>> Complaint."
>>>
>>> It didn't specify whether the "webpage" should be delivered via HTTP,
>>> or HTTPS, or both. A clearer set of requirements here would have
>>> avoided the issue.
>>>
>>> There are likely still a few weeks before the first .app URS complaint
>>> is decided, so sufficient time for a fix. I figure this issue can be
>>> solved for under $20/month, for those who know what they're doing
>>> technically.
>>>
>>> By the way, the implementation of suspension pages seems to differ
>>> across providers. e.g. NAF wildcards (*.example.com) the subdomains,
>>> so that:
>>>
>>> http://gjkhjhg.wikipedia.kim
>>> http://anything.wikipedia.kim
>>>
>>> deliver the page. MFSD only handles the "www" subdomain (and the naked
>>> domain itself). Neither of the 2 handle "internal" pages beyond the
>>> "home" page, e.g.
>>>
>>> http://wikipedia.kim/lalala --- 404 error
>>> http://reima.top/lalala -- 404 error
>>>
>>> With minor configuration changes, those URLs currently serving up a
>>> 404 error could instead serve the suspension notice.
>>>
>>> Sincerely,
>>>
>>> George Kirikos
>>> 416-588-0269
>>> http://www.leap.com/
>>>
>>>
>>> On Fri, May 11, 2018 at 10:49 PM, George Kirikos <icann at leap.com> wrote:
>>>> Hi folks,
>>>>
>>>> I believe I've uncovered a technical bug in the URS implementation.
>>>> Does anyone here know the best method to report it? It might require a
>>>> policy change (due to the ambiguity of the policy's requirements on
>>>> providers) or updated documentation, as well as implementation changes
>>>> by providers, in order to fix it.
>>>>
>>>> The bug isn't manifesting itself at the moment, but is almost certain
>>>> to be visible to others in a short time.
>>>>
>>>> Sincerely,
>>>>
>>>> George Kirikos
>>>> 416-588-0269
>>>> http://www.leap.com/
> _______________________________________________
> gnso-rpm-wg mailing list
> gnso-rpm-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rpm-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rpm-wg/attachments/20180606/d8bfc904/attachment.html>