[NCAP-Discuss] Fwd: [Ext] JAS no-bid on NCAP Study 1

Tue Sep 3 17:31:13 UTC 2019

And I see Warren says there was an attempt within SSAC to do exactly this
but it failed for lack of sufficient interest.  From my point of view, this
is an *ICANN* problem.  We now have two attempts to deal this problem to
others, i.e. the IETF and SSAC.  But neither is obligated to take this on.
So that leaves ICANN continuing to wrestle with this.  It seems to me that
if ICANN has the budget for our NCAP work and for the contracts it expects
to fund, there should surely be room to support the development of a
1918-like protected namespace.

Steve

On Tue, Sep 3, 2019 at 1:17 PM Warren Kumari <warren at kumari.net> wrote:

> On Tue, Sep 3, 2019 at 12:47 PM Matt Larson <matt.larson at icann.org> wrote:
> >
> > Dear colleagues,
> >
> > David Conrad and I thought the email below from Jeff Schmidt (who is
> known to most of you based on his firm's previous work on name collisions)
> was worth forwarding to this group, which we are doing with Jeff's
> permission.
> >
> > Matt
> >
> >
> > Begin forwarded message:
> >
> > From: Jeff Schmidt <jschmidt at jasadvisors.com>
> > Subject: [Ext] JAS no-bid on NCAP Study 1
> > Date: August 27, 2019 at 11:25:49 AM EDT
> > To: Roy Arends <roy.arends at icann.org>, Matt Larson <
> matt.larson at icann.org>, David Conrad <david.conrad at icann.org>
> >
> > Hello Team ICANN!
> >
> > JAS elected not to bid on the NCAP Study 1; thank you for the invitation
> and please keep us in mind for Study 2 if such a study occurs.
> >
> > Our primary rationale for not bidding on Study 1 is simply that we don’t
> believe we have anything useful to add to the discussion given the limited
> scope of Study 1.  We believe that at this point DNS namespace collisions
> are well understood (albeit by a relatively small technical community) and
> that any further work product from JAS would largely be a restatement of
> our October 2015 Final Report.  In the three years since our Final Report,
> our conclusions have been shown to be largely correct and the mitigation
> strategy we proposed (“Controlled Interruption”) has had the desired
> effects. Many TLDs have been delegated and used in a variety of fashions at
> this point and – as we suggested – the few problems that surfaced were
> isolated and not serious.  Our definition of DNS namespace collisions and
> the causes/etiology as described in Sections 4 and 5 of our report still
> hold.  At the end of the day, we can’t take your money if we don’t believe
> we have anything useful to add.  ;-)
> >
> > The one glaring failure and our great disappointment is that the IETF
> has refused to take-up our Recommendation #1 to clearly create an RFC
> 1918-like protected namespace for local use.  Until this happens, DNS
> namespace collisions will continue to occur; however, increased awareness
> should reduce the risk of widespread serious future problems (with the
> “corp-like” exception noted below).  Given the lack of clarity of RFC 6762
> (including errata), this issue will persist until folks are told
> unambiguously the *right* way to do this.
>
> Some background / update on Recommendation #1:
>
> I wrote an Internet Draft proposing just this --
> https://www.ietf.org/archive/id/draft-wkumari-dnsop-internal-00.txt
> Here are slides:
> http://slides.com/wkumari/deck-f68ee558-abac-4af2-9357-5669734d3445-5-8#/
>
> These were presented at (at least) DNS-OARC 27 (San Jose, Sept 2017),
> and IETF 100 (November 2017, Singapore).
>
> My recollection of the consensus was that DNSOP was generally
> supportive of the concept, but felt that the right venue for this was
> to do it in ICANN (unlike other proposals, like for .alt, this is
> quite similar to a TLD). I brought it to ICANN SSAC, where it got a
> number of people showing interest in working on it, but not enough
> that a work party was formed. I'd raised the idea a few more times,
> and mentioned it to a few more people, but never got much support, and
> so I got discouraged and gave up...
>
> W
>
> >
> > We believe the datasets available to research collisions are also fairly
> well known – the DNS-OARC DITL data, data that may be made available from
> large recursive operators, and authoritative data acquired by
> acquiring/hosting known colliding domains (the 30+ such domains JAS owns,
> Mike O’Connor’s corp.com, etc).  While these datasets have been available
> for years, extremely limited research interest (essentially zero) has been
> shown in collision-related topics.
> >
> > JAS remains concerned about the security implications of a small number
> of “special” domains – like .corp – including the ones that have not yet
> been discovered.  The special nature of the string “corp” was not
> predictable a-priori and highly esoteric; all future TLD application rounds
> should contain steps to identify potential corp-like “special” strings
> requiring exceptional treatment.  JAS also remains concerned about the
> practice of “drop catching” which is essentially the intentional discovery
> and monetization of DNS namespace collisions and referenced this practice
> in our Final report and in Recommendation #14.  We would very much
> appreciate the opportunity to assist with these issues at some future point.
> >
> > Happy to chat further feel free to reach out of course; just wanted to
> make sure I closed the loop since you invited a bid from us.  Please do let
> whomever you select to perform Study 1 know that we’re happy to chat with
> them and provide whatever historical information/assistance we can.
> >
> > Thank you!
> > 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
> _______________________________________________
> 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: <http://mm.icann.org/pipermail/ncap-discuss/attachments/20190903/4d99eb5e/attachment.html>