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

Mark Andrews <marka@isc.org> Fri, 03 February 2017 21:09 UTC

Return-Path: <marka@isc.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 E9682129572 for <dnsop@ietfa.amsl.com>; Fri, 3 Feb 2017 13:09:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.099
X-Spam-Level:
X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 EfkA51M-06eA for <dnsop@ietfa.amsl.com>; Fri, 3 Feb 2017 13:09:31 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A80E129561 for <dnsop@ietf.org>; Fri, 3 Feb 2017 13:09:31 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id AA1D51FCACC; Fri, 3 Feb 2017 21:09:27 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 63CB0160046; Fri, 3 Feb 2017 21:09:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4B2AF160074; Fri, 3 Feb 2017 21:09:26 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id W5emVYgPMj1w; Fri, 3 Feb 2017 21:09:26 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id DC2DA160046; Fri, 3 Feb 2017 21:09:25 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7286C618213C; Sat, 4 Feb 2017 08:09:22 +1100 (EST)
To: Brian Dickson <brian.peter.dickson@gmail.com>
From: Mark Andrews <marka@isc.org>
References: <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@mail.gmail.com>
In-reply-to: Your message of "Fri, 03 Feb 2017 12:02:47 -0800." <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@mail.gmail.com>
Date: Sat, 04 Feb 2017 08:09:22 +1100
Message-Id: <20170203210922.7286C618213C@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LWxEkU_-hYv0ExKJ-J4-7WpMzlk>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
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: Fri, 03 Feb 2017 21:09:33 -0000

In message <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@mail.gmail.com>
, Brian Dickson writes:
> 
> Stephane wrote:
> 
> > On Wed, Feb 01, 2017 at 03:28:29PM -0500,
> >  Warren Kumari <warren at kumari.net> wrote
> >  a message of 103 lines which said:
> >
> > > or 2: request that the IANA insert an insecure delegation in the
> > > root, pointing to a: AS112 or b: an empty zone on the root or c"
> > > something similar.
> >
> > Here, people may be interested by draft-bortzmeyer-dname-root (expired
> > but could be revived). The main objection was the privacy issue
> > (sending user queries to the "random" operators of AS112.)
> >
> >
> My opinion on these issues are as follows, roughly:
> 
>    - I am in favor of AS112 for ALT
>    - For AS112, I prefer the AS112++ method (DNAME)
>    - I do not see why the DNAME would/should not be DNSSEC signed
>    - Any local use of ALT can be served locally and signed using an
>    alternative trust anchor
>    - I don't think there is any issue with having both the NXD from the
>       root, and the local assertion of existence, both present (in cache and 
> in
>       authoritative data respectively)
>       - Maybe there are issues with specific implementations?
>       - If anyone knows of such problems, it would be helpful to identify
>       them along with the implementation and version
>    - For AS112 privacy, perhaps someone should write up a recommendation to
>    set up local AS112 instances, to provide privacy, as an informational RFC?
>       - Even simply through resolver configurations, without a full AS112
>       "announce routes"?
>       - Do any resolver packages offer such a simple AS112 set-up?
>       - Maybe the efforts for privacy should start there (implement first,
>       then document)?
>       - Do any stub resolver packages include host-local AS112
>       features/configurations?
> 
> Overall, I'm obviously in favor of use of ALT, and for signing whatever is
> done for ALT, and for use of DNAME for ALT.
> 
> Brian "DNAME" Dickson

You need a insecure delegation for ALT for the purposes we want to
use ALT for.

Go setup a test rig where you have a signed root with ALT as you
described.  A validiting recursive server which also serves foo.alt.
A second validating recursive server which forwards all queries to
the first recursive server.  All servers are configured with a trust
anchor for the test root zone and are validating responses.  Try
to perform a lookup on foo.alt.

The second recursive server is the validating client that needs to
be able to get a answer other than BOGUS.  As we want to allow
foo.alt to be unsigned there can't be any other trust anchors,
including negative, configured.

Only solutions which allow content from the foo.alt zone to be
successfully resolved are acceptable.

The following will not work with the above rig:
* No delegation for ALT.
* A secure delegation for ALT.
* A DNAME for ALT in the root zone.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org