Re: [DNSOP] Mitigation of name collisions

Danny McPherson <danny@tcb.net> Mon, 03 October 2016 23:03 UTC

Return-Path: <danny@tcb.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACB2129505 for <dnsop@ietfa.amsl.com>; Mon, 3 Oct 2016 16:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.897
X-Spam-Level:
X-Spam-Status: No, score=-104.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vw16OWd_puA1 for <dnsop@ietfa.amsl.com>; Mon, 3 Oct 2016 16:03:41 -0700 (PDT)
Received: from mail.tcb.net (mail.tcb.net [64.78.239.75]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9EA812958A for <dnsop@ietf.org>; Mon, 3 Oct 2016 16:03:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.tcb.net (Postfix) with ESMTP id 6EF5EB4; Mon, 3 Oct 2016 17:03:41 -0600 (MDT)
X-Virus-Scanned: Debian amavisd-new at mailnew.seatmates.net
Received: from mail.tcb.net ([127.0.0.1]) by localhost (mail.chasingbugles.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RdXQWSWcmhL; Mon, 3 Oct 2016 17:03:40 -0600 (MDT)
Received: from vagari.home (pool-108-44-249-113.clppva.fios.verizon.net [108.44.249.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id A6EC6AF; Mon, 3 Oct 2016 17:03:40 -0600 (MDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_E7362099-692E-48C9-AA3B-B9E36156390A"; protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <CAHw9_i+NaU8RtC3sraO2ZwDKQSiYtmtFOYXPGV=5q0bwTdkOpA@mail.gmail.com>
Date: Mon, 3 Oct 2016 19:03:44 -0400
Message-Id: <FA9160A7-F360-451A-B497-979F07EA3BAA@tcb.net>
References: <90CF5269-0443-45AB-83BA-BE9F9D03831A@vpnc.org> <CAHw9_i+NaU8RtC3sraO2ZwDKQSiYtmtFOYXPGV=5q0bwTdkOpA@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GjKck8WUXv6k1EW4wz4cMHu3WcA>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Mitigation of name collisions
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Oct 2016 23:03:43 -0000

> On Oct 3, 2016, at 6:31 PM, Warren Kumari <warren@kumari.net> wrote:
> 
> ... and just for the record, much much more could have been determined
> (and users better warned / informed) if the address handed out was a
> server which displayed an error / links to more information[0], or if
> the name-servers serving the wildcard were required to collect and
> publish information and statistics. This would have allowed analysis
> of the effectiveness of the mitigations, etc.
> 
> Yup, I'm beating a dead-horse here, but people keep rediscovering the topic.
> 
> W
> [0]: This could have a webserver which localized the page (based on IP
> / Accept-Language), a mailserver with a useful error, SSH / telnet
> banners, etc. I figured out ~20 protocols which allowed some sort of
> useful banner return. The logs could have been anonymized, or only
> statistics saved…

No surprise .. Warren and I still agree here!

Further, I still believe that enterprise network operators need safe haven name space (e.g., intuitively, perhaps, .corp, .home, and .mail, rather than the currently but [not assuredly] reserved .gnso, .icann, .iab, .rir, .ietf, and the like) if they don’t want to be tethered to the global DNS, for whatever reason.

Heck, then we could even allow internal names certificates again (in those name spaces, where appropriate) and not force leakage of internal system names via the likes of Certificate Transparency - since we just went through all that trouble to develop qname minimization et al.


-danny