[NCAP-Discuss] ICANN’s thoughts on controlled interruption

Mon Feb 14 15:46:16 UTC 2022

Apologies, one additional point: GDPR and its global friends did not exist 7 years ago. I am not a lawyer but I strongly suspect the privacy-related requirements (and liabilities) associated with running such a honeypot globally (and subject to literally every global privacy jurisdiction) would be uneconomical at best and untenable at worst. Hard to imagine the proverbial juice being worth the squeeze.

Jeff

From: NCAP-Discuss <ncap-discuss-bounces at icann.org> on behalf of Jeff Schmidt via NCAP-Discuss <ncap-discuss at icann.org>
Reply-To: Jeff Schmidt <jschmidt at jasadvisors.com>
Date: Monday, February 14, 2022 at 10:37 AM
To: Justine Chew <justine.chew.icann at gmail.com>, Heather Flanagan <hlf at sphericalcowconsulting.com>
Cc: "ncap-discuss at icann.org" <ncap-discuss at icann.org>
Subject: Re: [NCAP-Discuss] ICANN’s thoughts on controlled interruption

I’m glad this is (again) coming up as it is a very important and subtle point.

Please see our (the JAS) report, page 22, section 3.1.6 entitled “Alternatives to Controlled Interruption”, specifically 3.1.8 “Honeypot Approaches” which includes what is being referred to here as “Enhanced Controlled Interruption”:

name-collision-mitigation-final-28oct15-en.pdf (icann.org)<https://www.icann.org/en/system/files/files/name-collision-mitigation-final-28oct15-en.pdf>

I would encourage everyone to (re-) read this section of the report (pp. 22-27) as it contains a thoughtful discussion of these issues, and little has changed in the ensuing 7 years. I will reproduce one relevant bullet:

There are collision scenarios where returning an Internet IP address will cause
traffic to be sent over the Internet that was never previously sent. Ever
conscious of “cure being worse than the disease” concerns, we certainly do not
want to open these hosts to new risks while we try to help them.
[. . . ]
Controlled interruption should not decrease the security posture of a
system, even temporarily. Or, as Verisign cleverly said in their public comment,
we don’t want to risk turning “Controlled Interruption” into “Controlled
Exfiltration!”

Verisign noted similar concerns circa 2015 (including their comments to the JAS report) regarding the exfiltration of data that any honeypotting (aka “enhanced controlled interruption”) would cause.

We also discussed several new liabilities that are created by honeypots – including causing information that would not have otherwise been transmitted over the Internet to be so transmitted (“but for the honeypot”), and the liabilities operators of the honeypot would face by creating lists of vulnerable hosts, capturing unknown and potentially sensitive data, etc. “Causing” honeypots may also subject others to various liabilities.

As we said in 2015, and I believe is still the case now: “. . . JAS believes the risk of operating such a honeypot does not justify the value and recommends against such an implementation.”

Said more bluntly, honeypots are one of those things that sound good in theory but become difficult in practice.

Jeff

From: NCAP-Discuss <ncap-discuss-bounces at icann.org> on behalf of Justine Chew <justine.chew.icann at gmail.com>
Date: Friday, February 11, 2022 at 10:41 PM
To: Heather Flanagan <hlf at sphericalcowconsulting.com>
Cc: "ncap-discuss at icann.org" <ncap-discuss at icann.org>
Subject: Re: [NCAP-Discuss] ICANN’s thoughts on controlled interruption

You don't often get email from justine.chew.icann at gmail.com. Learn why this is important<http://aka.ms/LearnAboutSenderIdentification>
Hi Heather,

Thanks for this.

I'd like to ask please, in your review of reports, advisories etc relevant to Controlled Interruptions and Enhanced Controlled Interruptions, did you come across any explanations (preferably not exclusively in technical language) of the privacy and legal risks associated with the honeypot approach? Might this have been highlighted in SAC 062 (although I didn't quite spot any in a quick scan of this), or perhaps in SAC 066 and/or the JAS report?

Thanks in advance for the assist,

Justine

On Fri, 11 Feb 2022 at 05:52, Heather Flanagan <hlf at sphericalcowconsulting.com<mailto:hlf at sphericalcowconsulting.com>> wrote:
In the chat of yesterday’s call, Ruben wanted to know why ICANN had decided against Enhanced Controlled Interruption in the past. The information I was thinking of is in their Name Collision Framework from July 2014:

"ICANN is interested in maintaining the reliability, security and stability of the DNS and the Internet.
As such, ICANN is interested in providing a good notification measure for those parties that may be
leaking queries intended for private namespaces to the public DNS. However, ICANN is also aware of
the privacy and legal risks associated with the honeypot approach described in SAC 062 and 066 and
the JAS report. ICANN has decided on balancing the good notification features  offered by  using  the
loopback address option with its superior privacy protection vs. the use of a honeypot. "

https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf

I think the text will need to be clear in our recommendations why the discussion group thinks this decision by ICANN must be revisted by the Board.

[Image removed by sender.]

Heather Flanagan
Spherical Cow Consulting
[Image removed by sender.]<http://linkedin.com/in/hlflanagan/>
[Image removed by sender.]<http://twitter.com/sphcow>

[Image removed by sender.]

Translator of Geek to Human
[Image removed by sender.]

hlf at sphericalcowconsulting.com<mailto:hlf at sphericalcowconsulting.com>

‌
_______________________________________________
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: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220214/20796674/attachment-0001.html>