ICANN Remit: Security & Stability of the DNS System

[Olévié Kouami]

Greetings all,

It's a very interesting debate here.
I would like to know the position of the RrSG on this concern too. What are
they think about ? Ans what could they done ?

Warm regards
Olevie
Le 24 janv. 2019 09:53, "James Gannon" <james at cyberinvasion.net> a écrit :

> Agree I think RIPE or IGF are ripe forums for taking up this challenge =)
>
> On 24 Jan 2019, at 10:47, Nick Shorey <lists at nickshorey.com> wrote:
>
> I think the majority of solutions may lay elsewhere, but ICANN community
> forums are a good place to for a cross-section people to discuss issues,
> without leading to any direct ICANN policy or regulations.
>
> In my experience RIPE NCC meetings have been a bit more limited in extent
> and breadth of participation, which could maybe be widened.
>
> I also think these issues are well-placed for community discussion and
> best practice recommendations through the IGF, which will help strengthen
> the standing of this forum.
>
> Kind regards,
>
> Nick
>
> On 24 Jan 2019, at 09:24, Vladimer Svanadze <00000585df4969dc-dmarc-
> request at listserv.syr.edu> wrote:
>
> Thanks James,
>
> My opinion for this issue is other. ICANN will not return to back, and
> ICANN will not be "The administration of certain responsibilities
> associated with Internet DNS root zone management" (IANA).
>
> I think that Security and Stability of DNS is a new challenge for us, for
> countries, for all community. DNS became a target for attacks, and this
> process will be grow, and grow, and this is threat not only for nations,
> also it is globally threat (https://www.zdnet.com/google-
> amp/article/iranian-hackers-suspected-in-worldwide-dns-
> hijacking-campaign/?fbclid=IwAR2uJ5pG_fcWKccaUz1te9oyUKKGppFjQ-
> sWhtgsduPdFQkMkH9129tkPdw).
>
> ICANN may be to begin a discussion around this issue, and ICANN can be as
> an organization, which will give ONLY recommendation (and not
> administration) for register and providers. I think that this process will
> reduce threats at Cyber Space. Almost all experts are talking about this
> problem, and if ICANN do not do anything, I think will be not so good, when
> ICANN works directly with register and providers.
>
> Thank you, It is my opinion.
>
> Hope I could put clearly my opinion with my poor English.
>
> Lado
>
>
> *From:* NCSG-Discuss [mailto:NCSG-DISCUSS at LISTSERV.SYR.EDU
> <NCSG-DISCUSS at LISTSERV.SYR.EDU>] *On Behalf Of *James Gannon
> *Sent:* Thursday, January 24, 2019 12:52 PM
> *To:* NCSG-DISCUSS at LISTSERV.SYR.EDU
> *Subject:* Re: ICANN Remit: Security & Stability of the DNS System
>
> My personal opinion is we spent a huge amount of political capital
> fighting for a limited mandate and for ICANN to stay out of areas not
> related to the root zone during the IANA transition, if we now turn around
> and say the opposite because its something we are interested in I think we
> burn a lot of creditability I think.
>
>
> On 24 Jan 2019, at 09:25, David Cake <dave at davecake.net> wrote:
>
> What ICANN can contractually mandate, and what it can discuss, or consider
> in policy creation, best practice docs, comments, etc are very different
> things. And also, ICANN communities overlap with over Internet communities
> of practice quite a bit - no reason discussions in ICANN can’t comment on
> what goes on elsewhere.
> Also, how registrars operate with regards to RDAP totally is being
> considered within ICANN at this point, and is not a 100% disjoint
> discussion.
>
> David
>
>
> On 24 Jan 2019, at 4:19 pm, James Gannon <james at cyberinvasion.net> wrote:
>
> I think that if ICANN tried to define how a registarar operates or
> mandates 2FA for their clients we would see quite quickly that that is very
> much outside of the bylaws interpretation in my opinion =)
>
> Not saying its not important, just out of scope for ICANN.
>
>
> On 24 Jan 2019, at 09:16, David Cake <dave at davecake.net> wrote:
>
> Registrar procedures are kind of within ICANN scope, or at least on the
> edges of it - but certainly procedures of groups that are definitely
> outside ICANNs remit have definitely been considered as part of ICANN
> policy processes. That is, ICANN may not in any way control processes like
> CAs, but it can (and does) consider the needs of such providers when
> looking at policy issues like RDS.
>
> David
>
>
> On 24 Jan 2019, at 4:03 pm, James Gannon <james at CYBERINVASION.NET> wrote:
>
> DNS below the root is out of scope for ICANN so I don’t agree that that is
> even a possibility.
>
>
> On 24 Jan 2019, at 08:59, Vladimer Svanadze <00000585df4969dc-dmarc-
> request at LISTSERV.SYR.EDU> wrote:
>
> Hello,
>
> Thank you, Sam, for your email, and information provided us.
>
> I agree with David in sort of around the edges of ICANNs remit, but
> security of DNS is a very important process, and also it is a main target
> for criminals in the near future. This problem is not only National level,
> it is a globally problem, and challenge for all DNS Community.
>
> It is not a problem only for the US, it is problem for every
> infrastructure. I think that will be very important for a stability and
> security of infrastructure of all countries, if registrar use more
> technical tools with Unified International Standards of protection, and
> include secure authentication, multi-factor authentication, as David say.
>
> Also I would like to add that will be good if around of ICANN will be a
> discussion about Security and Stability of DNS, and ICANN will develop
> policy/strategy with recommendation for DNS SSR, as a National, also as a
> Global level.
>
> And once again I absolutely agree with David in issues of DNS SSR can be
> tackled solely at the ICANN level.
>
> Lado
>
>
>
> *From:* NCSG-Discuss [mailto:NCSG-DISCUSS at LISTSERV.SYR.EDU
> <NCSG-DISCUSS at LISTSERV.SYR.EDU>] *On Behalf Of *David Cake
> *Sent:* Wednesday, January 23, 2019 10:47 AM
> *To:* NCSG-DISCUSS at LISTSERV.SYR.EDU
> *Subject:* Re: ICANN Remit: Security & Stability of the DNS System
>
> Thanks for brining this up, Sam. Some of this is sort of around the edges
> of ICANNs remit, but I think very useful for the DNS community to discuss.
>
> These are issues for US infrastructure of  course, but the same attacks,
> and the same mitigations, apply to all DNS use. It is important for all
> registrar services to include secure authentication, multi-factor
> authentication, etc. And supporting Certificate Transparency is definitely
> outside ICANNs direct remit, but a very interesting topic for discussion.
>
> A valuable reminder that DNS security is a real, and complex, issue even
> if many aspects of it are at the edges of ICANNs mission, and not all DNS
> SSR issues can be tackled solely at the ICANN level.
>
> David
>
>
>
>
> On 23 Jan 2019, at 9:44 am, Sam Lanfranco <lanfran at YORKU.CA> wrote:
>
> Excuse me if this is too far off base. It does serve as a quick primer on
> the kinds of threats that the DNS system is up against on a daily basis.
>
> As we work within the ICANN remit it might be useful to on occasion look
> out there at the ongoing daily threats to the security and stability of the
> DNS system. We are keenly aware of when various actors "turn off" the
> Internet but most of us are less aware of the other forms of attack on DNS
> security and stability. Here is a link to, and a few words from, the U.S.
> Department of Homeland Security on recent attacks on the DNS system.
>
> https://cyber.dhs.gov/ed/19-01/
>
>
> This page contains a web-friendly version of the Cybersecurity and
> Infrastructure Security Agency’s Emergency Directive 19-01
> <https://cyber.dhs.gov/assets/report/ed-19-01.pdf>, “*Mitigate DNS
> Infrastructure Tampering*”.
>
> *Excerpts: **CISA Emergency Directive on DNS Infrastructure Tampering
> <https://www.us-cert.gov/ncas/current-activity/2019/01/22/CISA-Emergency-Directive-DNS-Infrastructure-Tampering>*
> *01/22/2019 06:48 PM EST*
>
> Original release date: January 22, 2019
> The U.S. Department of Homeland Security (DHS) Cybersecurity and
> Infrastructure Security Agency (CISA) issued an emergency directive to
> address ongoing incidents associated with global Domain Name System (DNS)
> infrastructure tampering. CISA is aware of multiple executive branch agency
> domains that were impacted by the tampering campaign and has notified the
> agencies that maintain them. The directive requires Federal agencies to
> take specific steps and comply with reporting procedures to mitigate risks
> from undiscovered tampering, prevent illegitimate DNS activity, and detect
> unauthorized certificates.
> Federal agencies should review Emergency Directive 19-01
> <https://cyber.dhs.gov/ed/19-01/> for required actions and reporting
> procedures.
> Background
> In coordination with government and industry partners, the Department of
> Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency
> (CISA) is tracking a series of incidents1
> <https://cyber.dhs.gov/ed/19-01/#fn:1> involving Domain Name System (DNS)
> infrastructure tampering. CISA is aware of multiple executive branch agency
> domains that were impacted by the tampering campaign and has notified the
> agencies that maintain them.
> Using the following techniques, attackers have redirected and intercepted
> web and mail traffic, and could do so for other networked services.
>
>    1. The attacker begins by compromising user credentials, or obtaining
>    them through alternate means, of an account that can make changes to DNS
>    records.
>    2. Next, the attacker alters DNS records, like Address (A), Mail
>    Exchanger (MX), or Name Server (NS) records, replacing the legitimate
>    address of a service with an address the attacker controls. This enables
>    them to direct user traffic to their own infrastructure for manipulation or
>    inspection before passing it on to the legitimate service, should they
>    choose. This creates a risk that persists beyond the period of traffic
>    redirection.
>    3. Because the attacker can set DNS record values, they can also
>    obtain valid encryption certificates for an organization’s domain names.
>    This allows the redirected traffic to be decrypted, exposing any
>    user-submitted data. Since the certificate is valid for the domain, end
>    users receive no error warnings.
>
> To address the significant and imminent risks to agency information and
> information systems presented by this activity, this emergency directive
> requires the following near-term actions to mitigate risks from
> undiscovered tampering, enable agencies to prevent illegitimate DNS
> activity for their domains, and detect unauthorized certificates.
> See: Emergency Directive 19-01 <https://cyber.dhs.gov/ed/19-01/>
> Posted by: Sam L. NPOC
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20190124/2ab61a8b/attachment.htm>