Re: [DNSOP] ALT-TLD and (insecure) delgations.

Ted Lemon <mellon@fugue.com> Wed, 08 February 2017 15:05 UTC

Return-Path: <mellon@fugue.com>
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 24DF7129BBA for <dnsop@ietfa.amsl.com>; Wed, 8 Feb 2017 07:05:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.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 1YrVpd5LzJp6 for <dnsop@ietfa.amsl.com>; Wed, 8 Feb 2017 07:05:47 -0800 (PST)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 B2F60129BB7 for <dnsop@ietf.org>; Wed, 8 Feb 2017 07:05:46 -0800 (PST)
Received: by mail-qt0-x229.google.com with SMTP id w20so162465785qtb.1 for <dnsop@ietf.org>; Wed, 08 Feb 2017 07:05:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rrvY8ue0oTJxT3rLt0GWGTwBFASGOp0+9aBsvnmAf9Y=; b=s9W4SA+G1LuJ3E1nqM+WjPRibE/YxSjcEeLKgymYnJPvNFpwYFU2NOc1WGOyVV6YRI dgCKUuF0N0rp7LgvxdWXkuc4h77VGqIfrozXZiv+i08bTMaj2rlnMUTLM/qyiSSLwO1g b9kzKcTR48Ke68uhP7iIlRnmh4UcNyLBeoPwwRBU1nOg7jIoKFybXo7QIfQGpNOpYJa9 wX6Fj4BqmIK648xQ17mRL2c1oWuoIrwTDoQpwA66dnTrtX8rx7ODG/srk2GWtvGuyN7t 1NFt88c3Zk6NPsaG+qBq6X1MbqBAispvrQ+l0iGAQSWE0H/1kMEJbhvKAv9Cn7i+rjb5 UfYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=rrvY8ue0oTJxT3rLt0GWGTwBFASGOp0+9aBsvnmAf9Y=; b=bmMuGGlLhQQwgRrxv9JUhs7UacuoczDWa8NIZW6klrgr3V4MJ3bbS+RRRpYTXjHPfX fYza2zqVDDOYwbbeDF/28vjSCR15Z4bKwPnc+8K4LcIEpRLSRjaDyqYqVAFbt+GR1BGc fXo63btY5GFSWeYhTcX6ZrVkVZ4UzhDGVgjVF6q/XYkpaHtqRncgGOzbW67xEFYLcUDB chLKQO6dl7XexSI6h41VfhjfRBJURJy80UDeR2wzlIclgUGXa9k1aIsMbmpbpDk5+r2C yNrJoREPzU50aTfL/lUBcxbPyajJHPdmr99hBl8YIGlMjG5VBBHkpM2e6qRA2qvNxarQ kMaA==
X-Gm-Message-State: AMke39mLf6fuVqIi6pVsjAK9fpGA1r9ffqqFGFhrCo816aFNrdOqmUsxwg5HVAYwBUgshg==
X-Received: by 10.237.59.186 with SMTP id r55mr22488849qte.25.1486566345759; Wed, 08 Feb 2017 07:05:45 -0800 (PST)
Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id d52sm6408270qtc.2.2017.02.08.07.05.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 07:05:44 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <E0A42577-0984-4ADD-8658-91413CBE783D@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8130BE97-BDAE-449F-8AC3-4EA451992E2B"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 08 Feb 2017 10:05:42 -0500
In-Reply-To: <20170208060208.8C8E1635864D@rock.dv.isc.org>
To: Mark Andrews <marka@isc.org>
References: <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@mail.gmail.com> <20170203210922.7286C618213C@rock.dv.isc.org> <CAH1iCipKwcOsMQY3kjvSZ42LMK37GLD6GP2AVtnWK0c83k-RiA@mail.gmail.com> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <D4C0D518-A3ED-4555-93DA-2EA12D82A662@fugue.com> <CAHw9_iK7Vt+ZNw8=E-b+w9gGhwB9fZNqHYp2pqKqT__RgcDttQ@mail.gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <FB835756-2C46-40A9-88ED-2F8ADF812BA6@fugue.com> <20170208052544.862956356F33@rock.dv.isc.org> <FFAFD844-824C-44EA-A4B1-1AD28B4FE95C@fugue.com> <20170208060208.8C8E1635864D@rock.dv.isc.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/rfRyK-tSmLy-xU_mxdhJh_ccg4U>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, Brian Dickson <brian.peter.dickson@gmail.com>
Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations.
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: Wed, 08 Feb 2017 15:05:48 -0000

On Feb 8, 2017, at 1:02 AM, Mark Andrews <marka@isc.org> wrote:
> Which assumes agggressive negative caching.   I'm going to make a
> realistic assumption that it will take 10+ years for there to be
> meaningful (>50%) deployment of aggressive negative caching.

First of all, this probably isn't true, since most of the caches we care about are run by network operators, who tend to update more frequently for obvious reasons.   But the solution you propose, which causes a SERVFAIL, involves a specially-prepared resolver.   So if you get to _create_ the problem with a specially-prepared resolver, I get to solve it with a differently specially-prepared resolver.   If you want queries to .alt not to leak, you have to preload your cache with a proof of nonexistence for .alt, and you have to keep it up to date.   This is not terribly difficult to arrange.

>> Leaking a query to .alt is harmless.
> 
> Is it?  What reports are we going to see over the next 20 year of
> DITL data on *.alt.

How is that relevant?   Suppose we don't create .alt, and instead people just pick random top-level domains for their experiments, as they do now.   Will the number of bogus queries to the root be greater, or fewer?   Furthermore, queries for .alt are legitimate, in just the same way that queries for .com are.   They just have a different answer.