Re: [DNSOP] Mitigation of name collisions

David Conrad <drc@virtualized.org> Tue, 04 October 2016 00:33 UTC

Return-Path: <drc@virtualized.org>
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 97DD7129550 for <dnsop@ietfa.amsl.com>; Mon, 3 Oct 2016 17:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=virtualized-org.20150623.gappssmtp.com
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 HHViF_rGOBZy for <dnsop@ietfa.amsl.com>; Mon, 3 Oct 2016 17:33:52 -0700 (PDT)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D204A1293E0 for <dnsop@ietf.org>; Mon, 3 Oct 2016 17:33:52 -0700 (PDT)
Received: by mail-pa0-x232.google.com with SMTP id qn7so66097222pac.3 for <dnsop@ietf.org>; Mon, 03 Oct 2016 17:33:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=LRLx3vVkQumAfIB1Kw9EznD44lBPD8siwKJBviur5Wg=; b=tNeuGOZblXLPGgJtwaIyLB+e6IgE7I7oZ2NO+9EvWIxIxttHa6ltj5nBGbcJKms+Jh /S/iVYvAGPAgwICzByZvRvQkytulkbOdju3LvDuREIq+/uy59mbV3H6/+TUqLp740M5D 4umKINC0SX/XGpknI0EfUtdz1kJT2OkMozLkJ9pZDhKpiAfLVXseJV15wHeax8gOZ7mF Z167CHcaAk4g11f1GbagVY9duuPDjGXkpiJLKJx7X3F4Zubk9VGl5KyI8h70bDV3ivmJ d4/xwIihEo/tVJTf3rf1AyzDajrCepkWTy14BoyzCQ9ZBw5ndVySWwSzI2sJd3/jCBn+ FDGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=LRLx3vVkQumAfIB1Kw9EznD44lBPD8siwKJBviur5Wg=; b=flwRDuYE/pASVKIkvoq/f3mFolMCV4fX/K4QzgzVob47wPL0Dxr3oLW2ZkJVfr9tPx GUGj39wB5Gcs17Yu5psCcQ/cKMrQC9eQE23hfoF8k1l4L1TgWB6j/1h+aqyNyQZIsVFr G/Vz39f4YWcsOLWqGXz2qgEnrww0agUHxICEDPwJq9/U7I8sYqXiDZQDRvUb0y9KudHa gc/vVvc+3LJMBLFxG9eWIHMUqq7uoetlGGRvWplBvPGX+7z0vZr4fc8yuUAP5v6y3ClU +P0OEFUzj5Tx2Bw5vjPJ7331KCH3OxlIpWzxC25+zDpq9hSruy/YmEiFsLZgsgffLFjP mWfg==
X-Gm-Message-State: AA6/9RluGxmbUdHNGBDFI8oqnCIz9tIeT5mw3PSjO7ONUFN6Hwfe4gkVLSYUzq5rYv/ckQ==
X-Received: by 10.66.224.101 with SMTP id rb5mr1197261pac.45.1475541232258; Mon, 03 Oct 2016 17:33:52 -0700 (PDT)
Received: from DACO-4417.local.mail ([2605:e000:110f:337:fcb7:b29:da88:c5d7]) by smtp.gmail.com with ESMTPSA id d190sm49779014pfd.59.2016.10.03.17.33.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Oct 2016 17:33:51 -0700 (PDT)
Date: Mon, 03 Oct 2016 14:33:48 -1000
From: David Conrad <drc@virtualized.org>
To: Warren Kumari <warren@kumari.net>
Message-ID: <etPan.57f2f8ec.78e3fb2f.8936@virtualized.org>
In-Reply-To: <CAHw9_i+NaU8RtC3sraO2ZwDKQSiYtmtFOYXPGV=5q0bwTdkOpA@mail.gmail.com>
References: <90CF5269-0443-45AB-83BA-BE9F9D03831A@vpnc.org> <CAHw9_i+NaU8RtC3sraO2ZwDKQSiYtmtFOYXPGV=5q0bwTdkOpA@mail.gmail.com>
X-Mailer: Airmail (382)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="85C78071-7624-4B29-BAE9-ECC1B368BC61"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GWqeUOjrFi-cW3_4Mm_Y62fWeSM>
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: Tue, 04 Oct 2016 00:33:54 -0000

Warren,

On October 3, 2016 at 12:33:12 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],
I'm not particularly interested in beating the smudge on the ground that was the honey pot dead horse yet again. Here's an idea: if you can get Google lawyers to accept the full legal liability and privacy implications for running such a honey pot (regardless of how it is implemented and for what protocols), let me know and I'll argue that we should do an RFP to outsource the operation of such a honey pot in the next round. Until then, perhaps we can let the dead horse rest in peace?

 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. 

This, however, is more interesting and should another round occur, I think it'd make sense to do this in a staged fashion, first to ICANN name servers, then to the registry's name servers.

Of course, IIRC, people were arguing that you shouldn't ask questions when you aren't sure what you'll do with the answers... 

Regards,
-drc