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

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 08 February 2017 00:00 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 0C0A6129514 for <dnsop@ietfa.amsl.com>; Tue, 7 Feb 2017 16:00:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 bpmobx5m73-b for <dnsop@ietfa.amsl.com>; Tue, 7 Feb 2017 16:00:10 -0800 (PST)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 A532F128B37 for <dnsop@ietf.org>; Tue, 7 Feb 2017 16:00:10 -0800 (PST)
Received: by mail-io0-x235.google.com with SMTP id j13so103525453iod.3 for <dnsop@ietf.org>; Tue, 07 Feb 2017 16:00:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Sy227/Rp3tzSXI0oAKExEg5gskuSP6+xXTDOti3mnio=; b=cpdiTvTv/kxu5iT30i0CLPlhFUXGyq8ibwgIMbSlcI9WAi+Cbmyljo/OWGzx3bJXu0 OQUOcpLh1vhD8/Mtx2wGW1TyA7GKupRfEYu4QBjVTNMoVQhG0rq+Mr9Mie6JlPPUvYXC VX5nBIJqiGHX4neB1zBqNH7JfK6Fg0jkIkfmHvT5tUKirGkCHj2KzC1Nwu6/3cnF4cbK nPRkkJMFCUuwmcQ9ObBWdG4HTaTBlQ0Ryu/YtPxWTLHVdG+dPt0FN807Prt8O2uVcyzk szuO9B03tII16BoM5ykf/VnQUIh/UROrQtz38xB95eZGHbLGv4vwQKFsCqFnH16EglA/ ORBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Sy227/Rp3tzSXI0oAKExEg5gskuSP6+xXTDOti3mnio=; b=XLr+ljDap7dxeTEy04Z3QUYeQC+4y4m3kQNwUxMUyqD8+uV4wycS9AA1sCKqOWcDBD foQrsBPUPQPpTKB86yYKmDMYTnfyRkcIMSl3IA5x6kFP+KCyh1Vt119wC8CX5BGuaRa7 pq7YrVHQ7rIaxOPVcNmv3/JRv3q9uD7r3UR6v/WVr2RY4it9H6IiM6sudNWBiMBMJ0Tm 891NUkzXTEhfSE4gccT1lyGO8s5ZouRQWdv7aNiyHfvDNczy9VjU8IX+wyWaCE8v3SGs U5sWEwkL8P/aLen3MZLXc3j4s7V27SXo6vX5JW8eDUFg8qMHGIC8yxVs7YBPwBCUkiEr L4dA==
X-Gm-Message-State: AMke39l9Kqqh0A6PMumpivbXh0yqCUj+H9R1tM32fIKP8deDQAVYhnFMyM/4pMrFIUjNEIT9J7aMez7iMdh+Jg==
X-Received: by 10.107.149.18 with SMTP id x18mr6385679iod.167.1486512009876; Tue, 07 Feb 2017 16:00:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.133.208 with HTTP; Tue, 7 Feb 2017 16:00:09 -0800 (PST)
In-Reply-To: <20170207234405.99248633D3CA@rock.dv.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> <CAH1iCip=JKo4-WiMttKDNs3v_8KzP0PTd13KSPtzL6N7pPHWWQ@mail.gmail.com> <20170207234405.99248633D3CA@rock.dv.isc.org>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Tue, 7 Feb 2017 16:00:09 -0800
Message-ID: <CAH1iCiq0bAiyZU0SqxWn7vH=GbHdhKn78Zs-1412DhAsFFO8Cw@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Content-Type: multipart/alternative; boundary=001a1140fee44d9e500547f98cf1
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/JDkx34X9kmbuOWrwO4RPPbqnD5c>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, Ted Lemon <mellon@fugue.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 00:00:13 -0000

On Tue, Feb 7, 2017 at 3:44 PM, Mark Andrews <marka@isc.org> wrote:

>
> In message <CAH1iCip=JKo4-WiMttKDNs3v_8KzP0PTd13KSPtzL6N7pPHWWQ@
> mail.gmail.com>
> , Brian Dickson writes:
> > --f403045fbba86cf7240547f82103
> > Content-Type: text/plain; charset=UTF-8
> >
> > On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews <marka@isc.org> wrote:
> >
> > >
> > > In message <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com>, Ted Lemon
> > > writes:
> > > > Hm.   When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL.
> > > > When I validate, I get a secure denial of existence.   This is the
> > > > correct behavior.   Why do you think we would get a SERVFAIL?
> > >
> > > Because your testing is incomplete.
> > >
> > > Go add a empty zone (SOA and NS records only) for alt to your
> > > recursive server.  This is what needs to be done to prevent
> > > privacy leaks.
> > >
> > >
> > Here are some possible alternatives (to having the empty zone be named
> > "alt.").
> >
> > First: make the locally served empty zone be "empty.as112.arpa".
> >
> > Or, second method: have the DNAME RDATA be "alt.empty.as112.arpa", and
> the
> > locally served zone be the same name.
>
> Which does not work.  If you are serving up a local
>
>         ALT. SOA ...
>         ALT. NS ...
>         ALT. DNAME alt.empty.as112.arpa.
>

No, I am saying the following:
In the root, assume the existence of "ALT. DNAME alt.empty.as112.arpa."

Locally, serve your desired content (for what would be reachable below
"alt") at:

ALT.EMPTY.AS112.ARPA SOA ...
ALT.EMPTY.AS112.ARPA NS ...
FOO.ALT.EMPTY.AS112.ARPA <RRTYPE> <RDATA>
etc

The second DNAME would be for convenience only, so your local zone name
isn't causing too much confusion.

It does not matter one whit what that zone name (as the DNAME RDATA) would
be, so long as it is not at or beneath a real global name.

Suppose you want to use "foo.x" instead of "foo.alt.empty.as112.arpa":
$ORIGIN alt.empty.as112.arpa.
foo DNAME foo.x.

foo.x. SOA ...
foo.x NS ...
$ORIGIN foo.x
bar TXT "I am bar.foo.x, reachable via bar.foo.alt.empty.as112.arpa or via
bar.foo.alt."

The first DNAME gets you default protection via the AS112 empty zone,
assuming (the generalized you) are not doing local "alt" things.

The local service of "alt.empty" over-rides the insecure empty zone, but
does not block the validation path down to it.

The second DNAME is for convenience only, or potentially for welding some
locally served "homenet" onto "homenet.alt".
(The latter I am pointing out the feasibility of, not advocating for.)

Brian


>
> then it will not have RRSIG records so it will not validate unless there
> is a INSECURE delegation for .ALT.
>
> I really don't see the point in having the DNAME there other than you
> seem to want a DNAME there.
>
> The public version of the insecure .ALT zone could have a DNAME but
> we are not talking about those contents at the moment.  We are
> talking about what goes into the root zone to make this work.
>
> > Or, third, have some other name for the zone (anything other than alt, or
> > really anything that doesn't collide with a global name),
>
> Nothing doesn't collide with a global name.  This is all about carving
> a namespace out of the global namespace.
>
> > and then use a
> > local DNAME from "empty.as112.arpa" (or "alt.empty,as112.arpa") to that
> > zone's name (e.g. "homenet" or "homenet.local" or whatever  you wish).
>
> Homenet is still part of the global namespace.  Once there is a delegation
> and a RFC which states that it is not part of the global namespace then
> you have other issues or should we start squatting on the homenet space?
>
> > Since all of the above occur at or below the transition to unsigned, they
> > should validate. (I need to test these, but I don't see why they wouldn't
> > work, and all of the above avoid leaking queries to the root or to AS112
> > servers.)
> >
> > Brian
> >
> >
> >
> > > Configure another recursive server to forward its queries to this
> > > server and enable validation.
> > >
> > > Now ask for foo.alt from this second server.
> > >
> > > Mark
> > > --
> > > Mark Andrews, ISC
> > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> > >
> >
> > --f403045fbba86cf7240547f82103
> > Content-Type: text/html; charset=UTF-8
> > Content-Transfer-Encoding: quoted-printable
> >
> > <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div
> class=3D"gmail_quo=
> > te">On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews <span
> dir=3D"ltr">&lt;<a h=
> > ref=3D"mailto:marka@isc.org" target=3D"_blank">marka@isc.org
> </a>&gt;</span>=
> >  wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
> .8ex;bor=
> > der-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div
> class=
> > =3D"h5"><br>
> > In message &lt;<a href=3D"mailto:18F2EB0D-5BD0-
> 4CC5-B02C-2E5EA0B8CC23@fugue=
> > .com">18F2EB0D-5BD0-4CC5-B02C-<wbr>2E5EA0B8CC23@fugue.com</a>&gt;, Ted
> Lemo=
> > n writes:<br>
> > &gt; Hm.=C2=A0 =C2=A0When I look for foo.alt, what I get is NXDOMAIN,
> not S=
> > ERVFAIL.<br>
> > &gt; When I validate, I get a secure denial of existence.=C2=A0
> =C2=A0This =
> > is the<br>
> > &gt; correct behavior.=C2=A0 =C2=A0Why do you think we would get a
> SERVFAIL=
> > ?<br>
> > <br>
> > </div></div>Because your testing is incomplete.<br>
> > <br>
> > Go add a empty zone (SOA and NS records only) for alt to your<br>
> > recursive server.=C2=A0 This is what needs to be done to prevent<br>
> > privacy leaks.<br>
> > <br></blockquote><div><br></div><div>Here are some possible
> alternatives (t=
> > o having the empty zone be named &quot;alt.&quot;).</div><div><
> br></div><di=
> > v>First: make the locally served empty zone be
> &quot;empty.as112.arpa&quot;=
> > .</div><div><br></div><div>Or, second method: have the DNAME RDATA be
> &quot=
> > ;alt.empty.as112.arpa&quot;, and the locally served zone be the same
> name.<=
> > /div><div><br></div><div>Or, third, have some other name for the zone
> (anyt=
> > hing other than alt, or really anything that doesn&#39;t collide with a
> glo=
> > bal name), and then use a local DNAME from &quot;empty.as112.arpa&quot;
> (or=
> >  &quot;alt.empty,as112.arpa&quot;) to that zone&#39;s name (e.g.
> &quot;home=
> > net&quot; or &quot;homenet.local&quot; or whatever =C2=A0you
> wish).</div><d=
> > iv><br></div><div>Since all of the above occur at or below the
> transition t=
> > o unsigned, they should validate. (I need to test these, but I don&#39;t
> se=
> > e why they wouldn&#39;t work, and all of the above avoid leaking queries
> to=
> >  the root or to AS112 servers.)</div><div><br></div>
> <div>Brian</div><div><b=
> > r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote"
> style=3D"margin:=
> > 0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> > Configure another recursive server to forward its queries to this<br>
> > server and enable validation.<br>
> > <br>
> > Now ask for foo.alt from this second server.<br>
> > <div class=3D"HOEnZb"><div class=3D"h5"><br>
> > Mark<br>
> > --<br>
> > Mark Andrews, ISC<br>
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> > PHONE: <a href=3D"tel:%2B61%202%209871%204742"
> value=3D"+61298714742">+61 2=
> >  9871 4742</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
> =C2=
> > =A0INTERNET: <a href=3D"mailto:marka@isc.org">marka@isc.org</a><br>
> > </div></div></blockquote></div><br></div></div>
> >
> > --f403045fbba86cf7240547f82103--
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
>