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

[George Kirikos]

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/