[NCAP-Discuss] Last Call for NCAP Gap Analysis Brief

[Jeff Schmidt]

Team:

Sorry I’m late on this.  <Insert COVID excuse here>

This is a good paper and I’m generally supportive in current form.  A few big picture thoughts:

(1) Unicorn collisions vs noise

One concept I believe is missing is the importance of identifying “unicorn” collisions a-priori in future rounds.  There are normal “run of the mill” collisions that happen in every namespace and always will – these create some background noise and minor irritation but mature namespaces have evolved to tolerate this sort of noise.  They should be understood but are less “dangerous.”  This number will never get to zero and zero is not a realistic goal or expectation.

Then there are the unicorns that, for historical, technical, human factors, and/or other reasons have the capability to create “danger” on a larger scale than the noise collisions.  This is .corp and friends.  There are probably more that we haven’t found yet.  The single most important thing we can do to increase Global Internet SSR is to find those – I fear we often get distracted chasing noise collisions that don’t really move the needle.

(2) Education to developers and designers and a clear “right way”

A necessary prerequisite for a unicorn collision scenario is the lack of cryptographic authentication at the application layer.  When too much trust is put in the DNS response alone, these scenarios are possible.  When I have talked about collisions, I always emphasize to developers and architects the importance of application layer cryptographic authentication and in general not to trust the DNS response blindly (has nothing to do with DNSSEC).  This is particularly true of IoT/embedded designers/developers that in general don’t like crypto (uses battery/processor).  The education component of this is important.  Related: The IETF’s refusal to create a clear 1918-like DNS namespace and a clear “right way to do this” is deplorable.  We should call this/them out explicitly.  We have this problem largely because there is no clear “right way to do this.”  If IETF ignores/refuses, ICANN should consider doing it – a clear “right way to do this” is a necessary prerequisite to reducing non-intentional collisions, increasing Global Internet SSR, and other goodness.

(3) Intentional collisions

While I understand “intentional” collisions (drop catching et al) are a third rail of the ICANN universe, I think we do a disservice to the community by continuing to find ways to *not* address this elephant in the room issue.  This includes existing (non-new-G) DNS namespace.  Section 3 “Vulnerability Understanding and Mitigation Strategies” should contain a reference to intentional and watering-hole type attacks that leverage collisions in all areas of the DNS.  Without exception, the most dangerous collision scenario that exists today is intentional collisions leveraging WPAD and other outdated Microsoft protocols.  With people working remotely now during COVID and often connected to public resolvers instead of internal resolvers, this issue is even more heightened.  We’re doing a disservice to Global Internet SSR by perpetuating the ostrich head in sand approach to this part of the problem.

Thx,
Jeff


From: NCAP-Discuss <ncap-discuss-bounces at icann.org> on behalf of "Thomas, Matthew via NCAP-Discuss" <ncap-discuss at icann.org>
Reply-To: "Thomas, Matthew" <mthomas at verisign.com>
Date: Tuesday, April 21, 2020 at 7:15 AM
To: "ncap-discuss at icann.org" <ncap-discuss at icann.org>
Subject: Re: [NCAP-Discuss] Last Call for NCAP Gap Analysis Brief

All,

This announcement will serve as the closing of the request for comments and edits to the NCAP Gap Analysis Brief. Thanks to all who provided their input. The final version is attached to memorialize the output of the NCAP discussion group.

Matt Thomas
NCAP co-chair


From: "Thomas, Matthew" <mthomas at verisign.com>
Date: Friday, April 17, 2020 at 8:23 AM
To: "ncap-discuss at icann.org" <ncap-discuss at icann.org>
Subject: Last Call for NCAP Gap Analysis Brief

All,

As discussed on the last two NCAP calls, we are seeking any edits (please use suggestion mode) and or comments on the NCAP Gap Analysis Brief document.  I’ve attached a PDF version of the document and the URL is listed below[1].  This announcement will serve as the final call. Please have any edits or comments posted by April 20th, 2020.

Best,

Matt Thomas
NCAP co-chair

[1]https://docs.google.com/document/d/1Ri9LuGD8Gplz5ooyeVS6GahiiRuPNY80KaXcujopoac/edit

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ncap-discuss/attachments/20200421/138a4fbf/attachment.html>