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

Brian Dickson <brian.peter.dickson@gmail.com> Tue, 07 February 2017 05:50 UTC

Return-Path: <brian.peter.dickson@gmail.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 D884C129A3C for <dnsop@ietfa.amsl.com>; Mon, 6 Feb 2017 21:50:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1uEDrtWHQ9Da for <dnsop@ietfa.amsl.com>; Mon, 6 Feb 2017 21:50:28 -0800 (PST)
Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::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 38F3B129A33 for <dnsop@ietf.org>; Mon, 6 Feb 2017 21:50:28 -0800 (PST)
Received: by mail-pg0-x232.google.com with SMTP id 194so35497369pgd.2 for <dnsop@ietf.org>; Mon, 06 Feb 2017 21:50:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aEzg6I250X06CAweFF9qPcvU0mT6MeNG4xxl4QDGO70=; b=usgCQrS0VffSpnzPCd+DNAERpfREblC2uRkWIiWKN7jWZJsgl8b97rcZsWfxLRFCed FtpKJZbSbLqsI+0KAkrn5TGA+ySHR/hbLsYA9USFWw1sefpJkqJUdVn8jyw5fmo2yoJN uw+HOVYiokjnZeQJsuYIw57FXmWHxp5JKllIViWIgW/451oLN9/lwBpYa08CFSp5FH9z AeNgEsnwctQp6tTqoUxLQLCnHRRrhG88kVTk50HxfDVfx5gKvpx7uvOsIEQfW2rFXHYX TsaGcj/2StWaHAAjnzVl8ngExxvF61mBQMOjHnptRtwCvQjYL6GbjVq6RwMzDGzSpX6y 4EXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aEzg6I250X06CAweFF9qPcvU0mT6MeNG4xxl4QDGO70=; b=DlYodOThKu7ODuXfShaMHfHToTAXaOr6Z6CjPRG+6Wjmx84KuUkn+wEoNaS12YCqv6 yEpnk1GMAjbxZlpBOrP0U3hCwyG3f6C1Gtk1ajzaVNe1TPf7Jd02t98rn2rJ3xbNCDDK TxUzZyuiw3TBgal/ZjfhItm6kbYJYmtR6xBecj6Dj0PzTraqtLObQJ1dHcZ+DGUopm7G /fCgDVCnu4TcjF0PtBcI/OE1oFW7ZTEA6c9IgBYHSv8FVzXFDnrqZ08t9cCnjdHrpQ7l 8+PCEi5wmXvaYzhq0Ewsxz4sAeiOBaiusGfIJ40cgYEcCtOLB+9pTpdsOGfy38H6NSyv rFAA==
X-Gm-Message-State: AIkVDXJaJJ2ocv+HGh1t1gbBjdj64VIJ2+Kmb8bLrST2esY9/jWOw2RavIv6+THcWxdkiA==
X-Received: by 10.99.8.133 with SMTP id 127mr18398240pgi.42.1486446627502; Mon, 06 Feb 2017 21:50:27 -0800 (PST)
Received: from [192.168.5.105] (c-73-92-109-167.hsd1.ca.comcast.net. [73.92.109.167]) by smtp.gmail.com with ESMTPSA id f9sm7079776pfj.56.2017.02.06.21.50.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 21:50:26 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Brian Dickson <brian.peter.dickson@gmail.com>
X-Mailer: iPhone Mail (14D27)
In-Reply-To: <20170207040552.8BDCC632F192@rock.dv.isc.org>
Date: Mon, 6 Feb 2017 21:50:24 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com>
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>
To: Mark Andrews <marka@isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GQbMqj2zs7mwftw5alVffewmJxE>
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: Tue, 07 Feb 2017 05:50:30 -0000

Mark,

I don't think the use cases for most of the sandbox involving alt, and/or the homenet use case, requires support for validating stubs. If stubs aren't already validating, the incremental addition of a local alt, only requires distribution of the trust anchor to the resolvers. That is a solvable problem for most values of "local".

If use cases for non-local or validating stubs exits, IMHO that rises to the level of requiring something real, not an alt name.

If you think that is something that there is a demand for, I don't know if it might belong in a separate domain.

An insecure delegation from the root may be seen as an invitation for exploitation by squatters.

Sent from my iPhone

> On Feb 6, 2017, at 8:05 PM, Mark Andrews <marka@isc.org> wrote:
> 
> 
> In message <CAH1iCipKwcOsMQY3kjvSZ42LMK37GLD6GP2AVtnWK0c83k-RiA@mail.gmail.com>, Brian Dickson writes:
>> 
>> TL;DR: it is possible to have a signed DNAME in the root for alt (to
>> empty.as112.arpa), AND have a local signed alt. Things under this local alt
>> can be signed or unsigned.
> 
> So now there is the problem of distributing trust anchors for the
> locally signed .alt zone just to be able to generate a NXDOMAIN
> response locally so that you don't leak names to the root servers.
> 
> Note: we have no automatic solution to this problem and there is
> no possible solution.
> 
> A DNAME at the root is not the right solution to this.
> 
> Mark
> 
>>> On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews <marka@isc.org> wrote:
>>> 
>>> 
>>> In message <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@
>>> mail.gmail.com>
>>> , Brian Dickson writes:
>>>> 
>>>>   - 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
>>> 
>>> 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.
>>> 
>> 
>> I spent some time mocking up a variety of configurations.
>> 
>> My original assertion stands; the particulars on making it work are perhaps
>> not interesting to everyone.
>> However, it falls in the "pics or it didn't happen" category, so here's
>> what I did to make it work.
>> 
>> 1 - set up a general resolver with the standard ICANN root trust anchor.
>> Call it "X".
>> 2 - set up a local "fake root server" which delegates to a "local alt
>> server". Call this fake root server "F"
>> 3 - set up a local "alt server" which serves the local "alt" domain
>> (including any delegations, etc). Cal this "A".
>> 3 - set up a second resolver, with appropriate trust anchor(s), that uses a
>> "fake root server" instead of the real root. Call this "Y".
>> 4 - set up a forwarder, which is configured to always forward to "X",
>> except for the zone "alt", where it forwards to "Y". Make sure the
>> necessary trust anchors are configured. Call this "Z".
>> 
>> Z->Y if QNAME matches "alt" or "*.alt" (and validates with local trust
>> anchors)
>> Z->X otherwise (and validates using the ICANN root trust anchor).
>> 
>> When I do this, I get real answers for everything but "alt". For anything
>> at or under "alt", I get my own local copy.
>> 
>> Everything validates (or is from below an insecure delegation point).
>> 
>> 
>>> 
>>> 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.
>>> 
>> 
>> In the above scenario, you CAN have an unsigned foo.alt, and it will not
>> get BOGUS.
>> 
>> If you want me to send you configs, just drop me a line.
>> 
>>> 
>>> 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
>> 
>> 
>> The problem is with your set-up, not the ability to have a working
>> local-alt set-up.
>> 
>> You need to put "foo.alt" somewhere OTHER than on the validating recursive
>> server (which knows how to find the local "alt" stuff.)
>> 
>> TIL you can't mix authority and recursive on the same server, when you are
>> the target of a forwarder.
>> 
>> If the two are separated, it works correctly, including using an alternate
>> trust anchor for "alt".
>> 
>> Brian
>> 
>> --001a113fece272cf3b0547e877d3
>> Content-Type: text/html; charset=UTF-8
>> Content-Transfer-Encoding: quoted-printable
>> 
>> <div dir=3D"ltr">TL;DR: it is possible to have a signed DNAME in the root f=
>> or alt (to empty.as112.arpa), AND have a local signed alt. Things under thi=
>> s local alt can be signed or unsigned.<br><div class=3D"gmail_extra"><br><d=
>> iv class=3D"gmail_quote">On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews <span=
>> dir=3D"ltr">&lt;<a href=3D"mailto:marka@isc.org" target=3D"_blank">marka@i=
>> sc.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
>> margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
>> t:1ex"><br>
>> In message &lt;<a href=3D"mailto:CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebht=
>> SXoM13DTg@mail.gmail.com">CAH1iCiqXohb_7LsQ2EMo8ZB-<wbr>t20mKq_nUDS8vebhtSX=
>> oM13DTg@<wbr>mail.gmail.com</a>&gt;<br>
>> <span class=3D"gmail-">, Brian Dickson writes:<br>
>> &gt;<br>
>> </span>&gt;=C2=A0 =C2=A0 - I am in favor of AS112 for ALT<br>
>> &gt;=C2=A0 =C2=A0 - For AS112, I prefer the AS112++ method (DNAME)<br>
>> &gt;=C2=A0 =C2=A0 - I do not see why the DNAME would/should not be DNSSEC s=
>> igned<br>
>> &gt;=C2=A0 =C2=A0 - Any local use of ALT can be served locally and signed u=
>> sing an<br>
>> &gt;=C2=A0 =C2=A0 alternative trust anchor<span class=3D"gmail-"><br>
>> <br>
>> </span>You need a insecure delegation for ALT for the purposes we want to<b=
>> r>
>> use ALT for.<br>
>> <br>
>> Go setup a test rig where you have a signed root with ALT as you<br>
>> described.=C2=A0 A validiting recursive server which also serves foo.alt.<b=
>> r>
>> A second validating recursive server which forwards all queries to<br>
>> the first recursive server.=C2=A0 All servers are configured with a trust<b=
>> r>
>> anchor for the test root zone and are validating responses.=C2=A0 Try<br>
>> to perform a lookup on foo.alt.<br></blockquote><div><br></div><div>I spent=
>> some time mocking up a variety of configurations.</div><div><br></div><div=
>>> My original assertion stands; the particulars on making it work are perhap=
>> s not interesting to everyone.</div><div>However, it falls in the &quot;pic=
>> s or it didn&#39;t happen&quot; category, so here&#39;s what I did to make =
>> it work.</div><div><br></div><div>1 - set up a general resolver with the st=
>> andard ICANN root trust anchor. Call it &quot;X&quot;.</div><div>2 - set up=
>> a local &quot;fake root server&quot; which delegates to a &quot;local alt =
>> server&quot;. Call this fake root server &quot;F&quot;<br></div><div>3 - se=
>> t up a local &quot;alt server&quot; which serves the local &quot;alt&quot; =
>> domain (including any delegations, etc). Cal this &quot;A&quot;.</div><div>=
>> 3 - set up a second resolver, with appropriate trust anchor(s), that uses a=
>> &quot;fake root server&quot; instead of the real root. Call this &quot;Y&q=
>> uot;.</div><div>4 - set up a forwarder, which is configured to always forwa=
>> rd to &quot;X&quot;, except for the zone &quot;alt&quot;, where it forwards=
>> to &quot;Y&quot;. Make sure the necessary trust anchors are configured. Ca=
>> ll this &quot;Z&quot;.</div><div><br></div><div>Z-&gt;Y if QNAME matches &q=
>> uot;alt&quot; or &quot;*.alt&quot; (and validates with local trust anchors)=
>> </div><div>Z-&gt;X otherwise (and validates using the ICANN root trust anch=
>> or).</div><div><br></div><div>When I do this, I get real answers for everyt=
>> hing but &quot;alt&quot;. For anything at or under &quot;alt&quot;, I get m=
>> y own local copy.</div><div><br></div><div>Everything validates (or is from=
>> below an insecure delegation point).</div><div>=C2=A0</div><blockquote cla=
>> ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
>> rgb(204,204,204);padding-left:1ex">
>> <br>
>> The second recursive server is the validating client that needs to<br>
>> be able to get a answer other than BOGUS.=C2=A0 As we want to allow<br>
>> foo.alt to be unsigned there can&#39;t be any other trust anchors,<br>
>> including negative, configured.<br></blockquote><div><br></div><div>In the =
>> above scenario, you CAN have an unsigned foo.alt, and it will not get BOGUS=
>> .</div><div><br></div><div>If you want me to send you configs, just drop me=
>> a line.=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
>> px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>> <br>
>> Only solutions which allow content from the foo.alt zone to be<br>
>> successfully resolved are acceptable.<br>
>> <br>
>> The following will not work with the above rig:<br>
>> * No delegation for ALT.<br>
>> * A secure delegation for ALT.<br>
>> * A DNAME for ALT in the root zone.<br>
>> <span class=3D"gmail-HOEnZb"><font color=3D"#888888"><br>
>> Mark</font></span></blockquote><div><br></div><div>The problem is with your=
>> set-up, not the ability to have a working local-alt set-up.</div><div><br>=
>> </div><div>You need to put &quot;foo.alt&quot; somewhere OTHER than on the =
>> validating recursive server (which knows how to find the local &quot;alt&qu=
>> ot; stuff.)=C2=A0</div><div><br></div><div>TIL you can&#39;t mix authority =
>> and recursive on the same server, when you are the target of a forwarder.</=
>> div><div><br></div><div>If the two are separated, it works correctly, inclu=
>> ding using an alternate trust anchor for &quot;alt&quot;.</div><div><br></d=
>> iv><div>Brian</div></div></div></div>
>> 
>> --001a113fece272cf3b0547e877d3--
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org