[NCAP-Discuss] [Ext] Re: Draft final Study 1 report

Wed Apr 29 00:17:31 UTC 2020

Danny,

Thanks for your feedback on the draft report and your clarification about the intent of your original message. No worries.

Here are my responses to your questions. I've copied the text of your original email below for reference.

1. I stated in the report that "there does not appear to be any recent academic research into the causes of name collisions or name collision mitigation strategies." You disagreed with that and cited nine examples of recent work. One was a 2020 posting to the NCAP mailing list from Jeff Schmidt about corp.com. One was a blog posting from 2019 on how pen testers can take advantage of name collisions. The other seven examples are from 2017 or earlier. Perhaps you and I are interpreting "recent" differently, but you haven't provided any examples of academic (or industry) research into name collisions from the past three years, and all the examples except the pen tester blog posting were already reviewed for the draft report. Would it be clearer if I reworded my statement to say, "There does not appear to be any academic or industry research during the past three years into the causes of name collisions or name collision mitigation strategies"?

2. I based my assertion about finding the causes for name collisions on evidence from previously identified causes. Sections 3.5 and 3.6 of the draft report contain most of this information. Causes mentioned include:
* Shortened name usage
* Search list processing
* User error and misconceptions
* Client software misconfiguration
* Browser prefetching
* Third-party applications or plug-ins
* Web crawlers
* Malware
* Web Proxy Auto-Discovery (WPAD) protocol
* Expired registrations
* Intentional acquisition of colliding names

There is no evidence that there's a single root cause of most name collisions. The evidence is overwhelming that there are many root causes, and that the types of root causes in the list above are not ones you would identify by analyzing datasets. Datasets might give you a starting point, but most of the analysis work would need to be carried out on a case-by-case basis outside those datasets. But I don't see any evidence that there's a substantial number of unexplained name collisions happening, let alone causing problems.

3. Regarding controlled interruption, Jeff Schmidt's email (https://mm.icann.org/pipermail/ncap-discuss/2020-April/000282.html) already said much of what I was going to say. Controlled interruption has been highly effective at mitigating name collisions--there's overwhelming evidence of that--and that encompasses all current root causes. Unless a major new root cause is identified that controlled interruption can't effectively mitigate, I do not see the need to study mitigation strategies other than controlled interruption. I don't even know *how* you would study mitigation strategies unless you know which root cause needs to be addressed and how controlled interruption is insufficient. I will state this more clearly in Section 6 of the report.

Karen

> Some specific comments, for Karen, I suppose:

> I find some statements in section 6 inaccurate and the conclusions
> unsupported, if this is based on what Karen thinks and feels warranted
> v. some poll and discussion of the WG then that should be clear, but I
> don't think that's what most of us signed up to.  For example:

> “The only known work on name collisions during the past few years has
> been from ICANN by the NCAP DG  and the New gTLD SubPro Working Group.
> There does not appear to be any recent academic research into the causes
> of name collisions or name collision mitigation strategies.”

> I know Verisign has published two peer reviewed academic papers in
> 2016[1] and 2017[2] that directly measure name collisions and identify
> various associated vulnerabilities. There have also been other industry
> publications directly talking about name collisions and similar
> vulnerabilities (just to name a few[3][4][5]).  In the last several
> years, we have also seen ORDINAL[6] come online and their analysis deck
> that was distributed on the NCAP mailing list[7]. Work has also been
> going on in the IETF[8].  There is also a patent[9] Verisign filed in
> 2017 for detecting and remediating highly vulnerable domain names that
> is an alternative or complementary system to Controlled Interruption. In
> all, Verisign alone provided over 50 citations all since 2013 (which is
> certainly fresh considering how long even this SSAC / NCAP work has been
> occurring), are you saying none of these have content that NCAP and
> ICANN should consider?

> “New causes for name collisions are far more likely to be found by
> investigating TLD candidates for potential delegation on a case by case
> basis.”

> How was this conclusion made? What evidence supports it? Broad studies
> are fundamental to understand the diversity and general behavior of a
> system. The DNS today is significantly different than the DNS in 2012.
> Without doing the work of Study 2, how are we sure that risk
> measurements and investigations are effective using an old dated
> baseline models?

> “Regarding Study 3, the review of prior work has not identified any new
> mitigation strategies for name collisions to be tested.”

> This statement puts the cart in front of the horse. This implies that
> all known causes of name collisions are well understood. Without a
> thorough understanding of the various reasons name collisions occur and
> how they behave, how can a mitigation strategy be designed properly?

> Further, no actual work has been done on the currently proposed
> mitigation with controlled interruption and the efficacy theref -
> apparently even in places where apparently SLDs such as corp.com are
> extremely risky (largely because of .CORP) the inventors didn't opt to
> use it when they controlled the domain.

> [1] https://www.ieee-security.org/TC/SP2016/program-papers.html#oakland16-81
> [2] https://dl.acm.org/doi/10.1145/3133956.3134084
> [3] https://www.us-cert.gov/ncas/alerts/TA16-144A
> [4] https://blog.trendmicro.com/trendlabs-security-intelligence/badwpad-doubtful-legacy-wpad-protocol/
> [5] https://blog.redteam.pl/2019/10/internal-domain-name-collision-dns.html
> [6] https://www.icann.org/en/system/files/files/presentation-ordinal-datasets-colliding-domains-13may17-en.pdf
> [7] https://mm.icann.org/pipermail/ncap-discuss/2020-February/000202.html
> [8] https://tools.ietf.org/html/rfc8244
> [9] Patent US20170279846A1

On 4/27/20, 9:26 AM, "NCAP-Discuss on behalf of Danny McPherson" <ncap-discuss-bounces at icann.org on behalf of danny at tcb.net> wrote:

    On 2020-04-24 15:42, Matt Larson wrote:

    >> 
    >>> We'd be grateful for your review and comment. We'll be following the
    >>> same process as we did with the draft version of the report: this
    >>> group has a chance to comment first and then the report will go out
    >>> for a formal Public Comment.
    >> 
    >> Are we commenting on what we believe are Karen's conclusions and what 
    >> she feels warranted by the "research" she's done?
    > 
    > You may comment on any aspect of the report that you choose, if you do
    > so in a respectful way. There's no need to write "research": it's a
    > cheap shot and I think you owe Karen an apology. Did she publish an
    > academic-style peer-reviewed paper? No. Did she spend hundreds of
    > hours reading many pages to come up to speed on a very technical
    > topic? Yes. If that's not research, I don't know what is.

    Matt I think you were taking me quoting research _way out of context, 
    there was nothing personal intended there.

    >> 
    >> Some specific comments, for Karen, I suppose:
    > 
    > I'll let Karen address these questions, but I will make one more 
    > comment:

    I look forward to Karen's responses regarding her executive summary and 
    conclusions.

    Thanks,

    -danny
    _______________________________________________
    NCAP-Discuss mailing list
    NCAP-Discuss at icann.org
    https://mm.icann.org/mailman/listinfo/ncap-discuss

    _______________________________________________
    By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.