[NCAP-Discuss] Honeypot refresher

Thu Apr 30 17:53:17 UTC 2020

On Thu, Apr 30, 2020 at 11:24 AM Danny McPherson <danny at tcb.net> wrote:
>
> On 2020-04-30 10:35, Jeff Schmidt via NCAP-Discuss wrote:
> > We are stuck in a Groundhog Day cycle of re-litigation on ancient
> > issues.
>
> I'll defer to Warren on his comments here but there are pros and cons,
> certainly.
>
> Some comments inline.
>
> > Some suggest (repeatedly) that Controlled Interruption was designed
> > the way it was because we don’t like data and honeypots (redirecting
> > colliding lookups to some Internet host controlled by “good guys”)
> > would generate the data panacea we always wanted but never had.
> > Suddenly all of our questions would be answered, toast would never
> > burn, and the coronavirus would be cured.  This is wrong.  Honeypots
> > create significant new risks; we concluded that the risks created by a
> > honeypot approach were worse than the rewards and suggested
> > (Recommendation 12) alternative approaches to gathering more data.
> > This issue was discussed extensively in the JAS Phase 2 report.
>
> Jeff, while I certainly understand the primitives was any actual legal
> analysis done on JAS's conclusion there?  I don't see any citations and
> have always wondered if while intuitive, did this benefit from any legal
> advice?
>
> Further, I am familiar with large scale honeypots, as previously noted,
> e.g.,:
>
> Tracking Global Threats with the Internet Motion Sensor
> https://pdfs.semanticscholar.org/5ac5/c8dab89963c69198a7597d4a81a7bad980b3.pdf
>
> The Zombie Roundup: Understanding, Detecting, and Disrupting Botnets
> https://www.usenix.org/legacy/event/sruti05/tech/full_papers/cooke/cooke.pdf
>
>

I didn't open the honey-pot can of worms this time -- I had said that
controlled interruptions did not collect data that would be useful for
evaluating the impact, and next rounds -- I was meaning things like
the number of queries resulting in the CI response; the number of
unique addresses; the number of AS#; the top N names within these;
overlap between these and known discovery tools (e.g: wpad); the
geographical distribution; etc.

But seeing as the can-o-worms has been opened, I will repeat my
argument from last time...

Yes, I'm *sure* ICANN does not want this liability - but, ICANN *not*
taking actions which could have protected people seems like an even
more dangerous decision.
A well designed honeypot will not log the payload, and can be audited
to attest to this - if I'm affected by a collision (e.g:
accounting.foo) and connect to a honeypot, I'd be unhappy - but, at
least I've been informed; can understand what the impact has been; and
more importantly, ICANN has taken action to prevent a much worse
outcome.
If ICANN does not run a honeypot, when the TLD is delegated and an
attacker registers accounting.foo, I have a much much worse outcome
--- ICANN could easily have prevented harm, and I'd think I have much
more reason to sue.

It was clear that people didn't understand what "127.0.53.53" was
supposed to mean, and in many cases would never have seen the address,
or failure - an obvious example of this is mail, where multiple MX
servers will be tried on "failure", but many of the discovery
protocols (like wpad), etc will also fail silently...

So, yes, I'm *sure* ICANN doesn't want liability of running a
webserver saying "If you see this, you have an issue - here is how to
fix it!", but surely there is liability in playing ostrich as well?
And it not legal liability, there sure seems like an ethical
liability... ICANN could run the 127.0.53.53-style CI for N weeks to
catch the "breaking change" stye collisions -- and then, if people are
so sure that this has been effective, either 1: the remainder will be
nonexistent or 2: would have been caught by attackers once
delegated...

W

> > Verisign in their public comments, agreed with us (quoting from
> > Section 2 of their comment to the JAS Phase 2 Report):
> >
> > <Verisign quote>
> >
> > Verisign maintains its position that directing requesters to an
> > internal address during the controlled interruption period is
> > preferable to an external honeypot, because as previously stated, it
> > avoids “controlled exfiltration” where sensitive traffic from an
> > installed system – without the advance consent of the user or system
> > administrator – may be drawn outside the local network. This risk is
> > acknowledged in Google Registry’s comments advocating for the
> > external honeypot [5]:
> >
> > “Unfortunately, some protocols will send sensitive information
> > unsolicited (e.g., login.example/login.php?user=fred and HTTP
> > cookies). The honeypot will specifically not log this sort of
> > information, but this doesn't change the fact that the information has
> > been communicated over the Internet.”
> >
> > </Verisign quote>
>
> Indeed, I recall that text and don't disagree, but would love to see a
> study of the legal risks and liabilities as opposed to the risks of not
> doing something that may occur downstream.
>
>
> > https://forum.icann.org/lists/comments-name-collision-26feb14/pdfTWUAZM3gBN.pdf
> >
> >
> > Please refer to section 3.1.6 “Alternatives to Controlled
> > Interruption” for a detailed discussion of Honeypot (Section 3.1.8)
> > (and other) approaches:
> >
> > https://www.icann.org/en/system/files/files/name-collision-mitigation-final-28oct15-en.pdf
>
> As stated in the document, JAS selected the Controlled Interruption
> solution "that offers the most value with the least risk".  I think
> revisiting this is not Groundhog Day.  That was a unilateral decision by
> JAS and ICANN and I understand why it was expeditious and convenient
> given the backlog of applicants and businesses awaiting delegation
> (because this work didn't happen before applications were accepted), but
> it was not a community decision and the occurrence and risks of
> collisions still persist, and are arguably worse in some areas with more
> internet-connected devices that may present new risks (or opportunities)
> that use the DNS for rendezvous and service discovery functions.
> Further, what labels should be reserved v. the "constrained" set in the
> original AGB (e.g., at TLD or SLD level).
>
>  From your no-bid justification it's apparent that you didn't think this
> work should happen at all and yet you acknowledge in your brief
> yesterday, as well as the actions with corp.com (that _are largely the
> result of .CORP) that there are significant risks of collisions, even in
> F20 companies that are surely the best resourced.  With these positions
> seem conflicted to me?
>
> The whole point of this work is to provide some predictably to
> applicants when applying for new gTLDs (and solidifying what to do with
> CORP, HOME, and MAIL).  The is to Neuman's "give me a test and some
> predictably please" which I wholly agree with and have all along, and
> continue to believe that the work such as label-based analysis affords
> the best _proactive predictability -- and can measurably be impacted
> with outreach to query sources (e.g., developers, operators, etc...) IF
> necessary.  What data enables this and what are the considerations that
> should be factored (e.g., availability, negative caching, forwarders,
> recursive, and other intermediaries, local roots, operators that
> synthesize responses, stringent and increasing privacy implications and
> data masking/anonymization, and qname minimization) are but some
> examples of an evolving landscape.
>
>
> -danny
>
> > Jeff
>
>
> _______________________________________________
> 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.

-- 
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