Subject: Re: [DNSOP] Mitigation of name collisions

From: Warren Kumari <[email-masked]>
Date: Mon, 3 Oct 2016 18:31:36 -0400

On Sun, Sep 18, 2016 at 6:03 PM, Paul Hoffman <[email-masked]> wrote:
> On 18 Sep 2016, at 14:10, John Levine wrote:
>
>>>> 4.2.4. Name Collision in the DNS ...
>>
>>
>>> This study is from before the new gTLD program.  The assumption in the
>>> report need to be tested against what actually happened in the round of
>>> new gTLDs before it can be included as part of the fact basis for this
>>> work.  We also need information on the degree of success that the
>>> various mitigation strategies had in overcoming possible problems to
>>> have a full picture of the problem as it has been shown in practice.
>>
>>
>> At a meeting a couple of weeks ago, I believe that someone said that
>> the junk traffic at the roots for each of .corp, .home and .mail still
>> greatly exceeds all of the traffic for the new gTLDs.  So I think it's
>> safe to say none of the mitigation strategies have worked.
>
>
> There is a difference between "mitigation" with "prevention". Few of use
> thought that publicity about upcoming collisions would have cause more than
> a few folks to fix the problem before it hit them.
>
>> The wildcard 127.0.53.53 and such are clever, but none of the domains
>> that have been delegated had significant collision issues to start
>> with so it's hard to argue they've been effective.
>
>
> It is impossible to measure the effectiveness without knowing how many
> collision queries are just noise (queries that will cause no noticeable
> damage if they started coming back with results). In the case of mitigation
> through wildcard-to-localhost, it is safe to assume that many organizations
> did in fact mitigate; we simply can't tell how many or when.

... and just for the record, much much more could have been determined
(and users better warned / informed) if the address handed out was a
server which displayed an error / links to more information[0], or if
the name-servers serving the wildcard were required to collect and
publish information and statistics. This would have allowed analysis
of the effectiveness of the mitigations, etc.

Yup, I'm beating a dead-horse here, but people keep rediscovering the topic.

W
[0]: This could have a webserver which localized the page (based on IP
/ Accept-Language), a mailserver with a useful error, SSH / telnet
banners, etc. I figured out ~20 protocols which allowed some sort of
useful banner return. The logs could have been anonymized, or only
statistics saved...

>
> --Paul Hoffman
>
> (Disclaimer: I'm now on ICANN staff, but well before I was, I wrote "Guide
> to Name Collision Identification and Mitigation for IT Professionals" for
> ICANN.)
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Danny McPherson <[email-masked]>
Date: Mon, 3 Oct 2016 19:03:44 -0400

> On Oct 3, 2016, at 6:31 PM, Warren Kumari <[email-masked]> wrote:
> 
> statistics saved…

No surprise .. Warren and I still agree here!

Further, I still believe that enterprise network operators need safe haven name space (e.g., intuitively, perhaps, .corp, .home, and .mail, rather than the currently but [not assuredly] reserved .gnso, .icann, .iab, .rir, .ietf, and the like) if they don’t want to be tethered to the global DNS, for whatever reason.

Heck, then we could even allow internal names certificates again (in those name spaces, where appropriate) and not force leakage of internal system names via the likes of Certificate Transparency - since we just went through all that trouble to develop qname minimization et al.

-danny

---

From: "John R Levine" <[email-masked]>
Date: 3 Oct 2016 19:24:14 -0400

>> ...

> server which displayed an error / links to more information[0],

Gee, I'd think you of all people would be aware that there's more to the 
Internet than the web.  A wildcard with a live IP in those domains would 
be a terrible idea for the same reason that *.com was.

> or if the name-servers serving the wildcard were required to collect and 
> publish information and statistics. This would have allowed analysis of 
> the effectiveness of the mitigations, etc.

That, on the other hand, would be a good idea.  Since all of the new TLDs 
use the same dozen back ends, I wonder if any of the back ends could be 
persuaded to release anonymized data.

R's,
John

---

From: Warren Kumari <[email-masked]>
Date: Mon, 3 Oct 2016 19:28:21 -0400

On Monday, October 3, 2016, John R Levine <[email-masked]> wrote:

> Internet than the web.

... Did you read the footnote?

W

>
>  A wildcard with a live IP in those domains would be a terrible idea for
> the same reason that *.com was.
>
>> publish information and statistics. This would have allowed analysis of the
>> effectiveness of the mitigations, etc.
>>
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: "John R Levine" <[email-masked]>
Date: 3 Oct 2016 19:35:52 -0400

> ... Did you read the footnote?

Yup.  It sounds like a way to collect vast amounts of interesting 
information that companies had no idea they were leaking.  Not every 
connection comes from something with a user watching a screen.  I wonder 
how many ssh connections are live users rather than rsync cron joba.

I realize that you, Warren, are virtuous and would not do anything bad 
with all of the secrets people fling at your server, but given the reality 
of the TLD ecosystem, how confident are you that nobody else running 
such a server would?

R's,
John

---

From: Danny McPherson <[email-masked]>
Date: Mon, 3 Oct 2016 19:41:19 -0400

> 
> I realize that you, Warren, are virtuous and would not do anything bad with all of the secrets people fling at your server, but given the reality of the TLD ecosystem, how confident are you that nobody else running such a server would?

Precisely why they ought to be notified of their vulnerability as soon as possible if the capability exists, no?  This was certainly the crux of the WPAD issue, for example.

-danny

---

From: David Conrad <[email-masked]>
Date: Mon, 3 Oct 2016 14:33:48 -1000

Warren,

On October 3, 2016 at 12:33:12 PM, Warren Kumari ([email-masked]) wrote:
... and just for the record, much much more could have been determined 
(and users better warned / informed) if the address handed out was a 
server which displayed an error / links to more information[0],
I'm not particularly interested in beating the smudge on the ground that was the honey pot dead horse yet again. Here's an idea: if you can get Google lawyers to accept the full legal liability and privacy implications for running such a honey pot (regardless of how it is implemented and for what protocols), let me know and I'll argue that we should do an RFP to outsource the operation of such a honey pot in the next round. Until then, perhaps we can let the dead horse rest in peace?

 or if 

This, however, is more interesting and should another round occur, I think it'd make sense to do this in a staged fashion, first to ICANN name servers, then to the registry's name servers.

Of course, IIRC, people were arguing that you shouldn't ask questions when you aren't sure what you'll do with the answers... 

Regards,
-drc

---

From: Rubens Kuhl <[email-masked]>
Date: Mon, 3 Oct 2016 22:00:26 -0300

> Of course, IIRC, people were arguing that you shouldn't ask questions when you aren't sure what you'll do with the answers... 

David,

Add to that starting doing controlled interruption as soon as next round reveal day, long before evaluation, contention set resolution and contract signing, and you will see lots of happy people in many sides of this problem. 

Rubens

---

From: Rubens Kuhl <[email-masked]>
Date: Mon, 3 Oct 2016 22:00:27 -0300

David,

Rubens