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

Mon Feb 14 19:01:24 UTC 2022

I was going to say that but you draw first. While there were some privacy regimes back then, including some legislation based on the European Data Protection directive from 1995, they didn't have the teeth GDPR and similar regimes like Brazil's LGPD or California privacy law now have. 

So besides your original point about the information security soundness of a name collision honeypot, the liabilities in operating such a system are much higher now than the ones then existing. I wonder if any of the supporters of the idea would be able to convince their own employers of operating such a system, even considering some compensation to be involved. 

Rubens

> On 14 Feb 2022, at 12:46, Jeff Schmidt via NCAP-Discuss <ncap-discuss at icann.org> wrote:
> 
> 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 <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.
>>  
>> 
>> Heather Flanagan
>> Spherical Cow Consulting
>>  <http://linkedin.com/in/hlflanagan/>	
>>  <http://twitter.com/sphcow>
>>  
>>  
>>  
>> 
>>  
>> Translator of Geek to Human
>> 
>>  
>> 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 <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 <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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
> 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/5ebf525f/attachment-0001.html>