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

Tue May 5 19:01:05 UTC 2020

Thanks, Eric, I’m looking forward to reading your review. You raise a valid point that the lack of recent academic research is not sufficient to say that there’s no need to try new remediation strategies. It would be more accurate for me to say that in the past three years, there has been minimal publicly observable activity outside ICANN regarding name collisions and remediation. To me this implies that only ICANN might be significantly concerned about name collisions or remediation in general (excepting the investigation of one-off instances like WPAD). Again, that doesn’t mean new remediation strategies aren’t needed, and it doesn’t mean ICANN shouldn’t be studying name collision remediation, but it indicates a general lack of interest in and concern for the topic. I think that’s a significant finding.

Karen

From: Eric Osterweil <lists at osterweil.net>
Date: Thursday, April 30, 2020 at 2:24 PM
To: Karen Scarfone <karen at scarfonecybersecurity.com>, "ncap-discuss at icann.org" <ncap-discuss at icann.org>
Subject: Re: [NCAP-Discuss] [Ext] Re: Draft final Study 1 report

Hi Karen,

Thanks for the detailed report and work.  I mentioned in another comment that I’m writing up a review of this document.  I hope to have that done soon.  Ahead of that, I wanted to make a couple of clarifications below:

On Apr 28, 2020, at 8:17 PM, Karen Scarfone <karen at scarfonecybersecurity.com<mailto:karen at scarfonecybersecurity.com>> wrote:

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<http://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”?

To me, it seems like there is a bit of an impedance mismatch here.  I mention this here because it seems (possibly) like it might be applicable to a number of emails exchanged recently.  I would not expect a lot of new research papers to be published on a topic until something changes (new results, change of incidence, etc.).  That perspective is (for better or worse) the nature of scientific literature.  From the literature’s perspective: a problem was published in 2016/2017 [1,2] and those papers even proposed several approaches to remediate (in Sections VII and 7, respectively).  I think the research community is (essentially) waiting to see what remediations get effectuated (or how results might change, etc.).  I think it might be false logic, imho, to anticipate new research results would be published that simply confirm ongoing incidences.  Perhaps it implicitly underscores the need for more effective diagnoses and remediation techniques for the problem (i.e. Studies two and three)?

Anyway, just my thoughts.  Thanks again for all the hard work in pulling together your writing.

Eric

[1] Chen, Qi Alfred, Eric Osterweil, Matthew Thomas, and Z. Morley Mao. "MitM attack by name collision: Cause analysis and vulnerability assessment in the new gTLD era." In 2016 IEEE Symposium on Security and Privacy (SP), pp. 675-690. IEEE, 2016.
[2] Qi Alfred Chen, Matthew Thomas, Eric Osterweil, Yulong Cao, Jie You, and Z. Morley Mao. 2017. Client-side Name Collision Vulnerability in the New gTLD Era: A Systematic Study. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (CCS ’17). Association for Computing Machinery, New York, NY, USA, 941–956. DOI:https://doi.org/10.1145/3133956.3134084

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<http://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<mailto:ncap-discuss-bounces at icann.org> on behalf of danny at tcb.net<mailto: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<mailto: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.

_______________________________________________
NCAP-Discuss mailing list
NCAP-Discuss at icann.org<mailto: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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ncap-discuss/attachments/20200505/9ad2973b/attachment-0001.html>