Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Brian Di
ckson writes:
> 
> Mark,
> 
> When I say, "never reaches the roots", this is what I mean:
> Resolution of "example.<homenet-label>" is, by design, intercepted by
> homenet resolvers, and never reaches the outside world.
> Do you concur with this statement?

Yes, but that isn't the complete picture.  "never" doesn't mean "most of the
time".  "never" means "never".
 
> Please stop conflating the issue of "the homenet namespace is local" (and
> thus not resolvable from outside starting at the DNS root) from the issue
> of the need for an insecure delegation IF homenet end systems do their own
> DNSSEC validation AND those same end systems don't special-case homenet
> from validation AND IF homenet is not signed with a separate trust anchor.

I want RFC 4035 compliant validating systems to be able to resolve
local names with the default homenet domain name when they are
connected to a homenet. That cannot happen without there being a
insecure delegation in the global namespace that breaks the DNSSEC
chain of trust.  Additionally the chosen name MUST exist in the
global namespace to avoid QNAME minimisation issues.

> Yes, IF validating stubs need to confirm the unsigned nature of homenet,
> THEN there is a need for retrieving the appropriate DNSSEC proof showing
> that there is a delegation out of the chain of trust anchored at the DNS
> root.
> 
> What that proof looks like is dependent on the issue under discussion,
> which is what the domain name for homenet should be, and why.

RFC 4035 states what that proof needs to look like.  That proof needs to
exist at whatever name is chosen.

> If the domain for homenet is "homenet." anchored in the root zone, then
> yes, "homenet/DS" will need to be obtained (or more correctly,
> "homenet/NSEC" proving no DS exists), signed by the ZSK of the root, along
> with the signed DNSKEY set (signed by the KSK of the root, i.e. the ICANN
> root trust anchor).
> 
> If the domain for homenet is something else, such as "homenet.arpa.", then
> the proof contains more elements, such as the DS for arpa, and the NSEC for
> homenet.arpa (proving no homenet.arpa/DS exists).
> 
> Brian
> 
> On Thu, Mar 30, 2017 at 12:20 AM, Mark Andrews <[e-mail]> wrote:
> 
> >
> > In message <CAH1iCiozhJ3CxRDXh8R1kfv40SZvA2MqPmsstx__+34BRowwUw@mail.
> > gmail.com>, Brian Dickson writes:
> > > On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley <[e-mail]>
> > wrote:
> > >
> > > >
> > > > > On Mar 29, 2017, at 10:07 AM, Michael Richardson
> > > <[e-mail]>
> > > > wrote:
> > > > >
> > > > >
> > > > > Terry Manderson <[e-mail]> wrote:
> > > > >> B) seek a .homenet special use domain WITHOUT the delegation reque=
> st
> > > > >> AND ask the IETF/IESG/IAB to commence the discussion with the ICAN=
> N
> > > > >> community to achieve an insecure delegation
> > > > >
> > > > >> c) seek a <SOMETHING>.arpa insecure special use delegation
> > > > >
> > > > >> d) go for "B" and if that doesn't work shift to "C"
> > > > >
> > > > > Is there some reason we can not proceed with "C", concurrently with
> > (B).
> > > >
> > > > I think that would require a new consensus call. There was a lot of
> > work
> > > > done to get to the point of agreeing on a path forward at the last
> > IETF,
> > > > and this path would be rather different than that.
> > > >
> > > > > This might cause stub resolvers to have to have two cases
> > > > > (SOMETHING.arpa, and .homenet) eventually, but at least we could
> > deploy
> > > > > and attempt interop with SOMETHING.arpa NOW, and it would more
> > clearly
> > > > > permit "home." to be removed from code.
> > > > >
> > > >
> > > > /chair-hat-off
> > > >
> > > > I don=E2=80=99t think we want to have two defaults in our specs. It=
> =E2=80=99s bad
> > enough
> > > > that we are already going to end up with .home and .homenet depending
> > on
> > > > the version of code used or forked from, I really don=E2=80=99t want =
> to do
> > anything
> > > > that could lead to a third if we can avoid it.
> > > >
> > > > - Mark
> > > >
> > >
> > > Taking a STRICTLY devil's advocate position here:
> > >
> > > Isn't it the case that the thing that knows what the <homenet> label is=
> ,
> > > should be able to masquerade on behalf of anything that isn't aware of
> > the
> > > divergence of the three possible values for <homenet>? If you end up wi=
> th
> > > some boxes thinking it is ".home", some ".homenet", and some
> > > ".homenet.arpa", as long as one of them knows about all three, it shoul=
> d
> > > be possible to resolve the differences.
> > >
> > > The scope of the namespace is "the home network", and never reaches the
> > > real DNS (roots), so at worst it would be folding the three fake
> > > namespaces into a unified (three-headed) fake namespace.
> >
> > Can we please stop with this "and never reaches the real DNS (roots)"
> > garbage.  Queries for homenet/DS *will* reach the roots.  That is
> > how DNSSEC validation is designed to work.  They *need* to be
> > answered with a signed NOERROR NODATA response.  Lots of Linux
> > distributions ship with DNSSEC validation enabled for on machine
> > clients and they are also configured to forward to the nameservers
> > that are returned by DHCP.
> >
> > These machines behave *exactly* like a validating stub resolver from
> > the DNSSEC perspective.  This isn't something that will be in the
> > future.  It is the PRESENT.
> >
> > > I.e. avoid it if you can, but if you can't, I think the issues are
> > > solvable, even if they get a little funky/ugly under the hood.
> > >
> > > None of that should be visible to users, I don't think.
> > >
> > > Brian
> > >
> > > P.S. Guide to implementers - never expose multiple handles for the same
> > > object; over-exuberant users may be tempted to try to "clean up" the
> > > duplicates.
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: [phone]                 INTERNET: [e-mail]
> >
> 
> --001a113ec618c0ed6c054bf663af
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr">Mark,<div><br><div><div>When I say, &quot;never reaches th=
> e roots&quot;, this is what I mean:</div><div>Resolution of &quot;example.&=
> lt;homenet-label&gt;&quot; is, by design, intercepted by homenet resolvers,=
>  and never reaches the outside world.=C2=A0</div><div>Do you concur with th=
> is statement?</div></div><div><br></div><div>Please stop conflating the iss=
> ue of &quot;the homenet namespace is local&quot; (and thus not resolvable f=
> rom outside starting at the DNS root) from the issue of the need for an ins=
> ecure delegation IF homenet end systems do their own DNSSEC validation AND =
> those same end systems don&#39;t special-case homenet from validation AND I=
> F homenet is not signed with a separate trust anchor.</div><div><br></div><=
> div>Yes, IF validating stubs need to confirm the unsigned nature of homenet=
> , THEN there is a need for retrieving the appropriate DNSSEC proof showing =
> that there is a delegation out of the chain of trust anchored at the DNS ro=
> ot.</div><div><br></div><div>What that proof looks like is dependent on the=
>  issue under discussion, which is what the domain name for homenet should b=
> e, and why.</div><div><br></div><div>If the domain for homenet is &quot;hom=
> enet.&quot; anchored in the root zone, then yes, &quot;homenet/DS&quot; wil=
> l need to be obtained (or more correctly, &quot;homenet/NSEC&quot; proving =
> no DS exists), signed by the ZSK of the root, along with the signed DNSKEY =
> set (signed by the KSK of the root, i.e. the ICANN root trust anchor).</div=
> ><div><br></div><div>If the domain for homenet is something else, such as &=
> quot;homenet.arpa.&quot;, then the proof contains more elements, such as th=
> e DS for arpa, and the NSEC for homenet.arpa (proving no homenet.arpa/DS ex=
> ists).</div><div><br></div><div>Brian</div></div></div><div class=3D"gmail_=
> extra"><br><div class=3D"gmail_quote">On Thu, Mar 30, 2017 at 12:20 AM, Mar=
> k Andrews <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]" target=3D"=
> _blank">[e-mail]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=
> uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
> x"><div class=3D"HOEnZb"><div class=3D"h5"><br>
> In message &lt;<a href=3D"mailto:CAH1iCiozhJ3CxRDXh8R1kfv40SZvA2MqPmsstx__%=
> [e-mail]">CAH1iCiozhJ3CxRDXh8R1kfv40SZv<wbr>A2MqPmsstx__+=
> 34BRowwUw@mail.<wbr>gmail.com</a>&gt;, Brian Dickson writes:<br>
> &gt; On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley &lt;<a href=3D"mailto:m=
> [e-mail]">[e-mail]</a>&gt; wrote:<br>
> &gt;<br>
> &gt; &gt;<br>
> &gt; &gt; &gt; On Mar 29, 2017, at 10:07 AM, Michael Richardson<br>
> &gt; &lt;<a href=3D"mailto:[e-mail]">[e-mail]</=
> a>&gt;<br>
> &gt; &gt; wrote:<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt; Terry Manderson &lt;<a href=3D"mailto:terry.manderson@icann.=
> org">[e-mail]</a>&gt; wrote:<br>
> &gt; &gt; &gt;&gt; B) seek a .homenet special use domain WITHOUT the delega=
> tion request<br>
> &gt; &gt; &gt;&gt; AND ask the IETF/IESG/IAB to commence the discussion wit=
> h the ICANN<br>
> &gt; &gt; &gt;&gt; community to achieve an insecure delegation<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt;&gt; c) seek a &lt;SOMETHING&gt;.arpa insecure special use de=
> legation<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt;&gt; d) go for &quot;B&quot; and if that doesn&#39;t work shi=
> ft to &quot;C&quot;<br>
> &gt; &gt; &gt;<br>
> &gt; &gt; &gt; Is there some reason we can not proceed with &quot;C&quot;, =
> concurrently with (B).<br>
> &gt; &gt;<br>
> &gt; &gt; I think that would require a new consensus call. There was a lot =
> of work<br>
> &gt; &gt; done to get to the point of agreeing on a path forward at the las=
> t IETF,<br>
> &gt; &gt; and this path would be rather different than that.<br>
> &gt; &gt;<br>
> &gt; &gt; &gt; This might cause stub resolvers to have to have two cases<br=
> >
> &gt; &gt; &gt; (SOMETHING.arpa, and .homenet) eventually, but at least we c=
> ould deploy<br>
> &gt; &gt; &gt; and attempt interop with SOMETHING.arpa NOW, and it would mo=
> re clearly<br>
> &gt; &gt; &gt; permit &quot;home.&quot; to be removed from code.<br>
> &gt; &gt; &gt;<br>
> &gt; &gt;<br>
> &gt; &gt; /chair-hat-off<br>
> &gt; &gt;<br>
> &gt; &gt; I don=E2=80=99t think we want to have two defaults in our specs. =
> It=E2=80=99s bad enough<br>
> &gt; &gt; that we are already going to end up with .home and .homenet depen=
> ding on<br>
> &gt; &gt; the version of code used or forked from, I really don=E2=80=99t w=
> ant to do anything<br>
> &gt; &gt; that could lead to a third if we can avoid it.<br>
> &gt; &gt;<br>
> &gt; &gt; - Mark<br>
> &gt; &gt;<br>
> &gt;<br>
> &gt; Taking a STRICTLY devil&#39;s advocate position here:<br>
> &gt;<br>
> &gt; Isn&#39;t it the case that the thing that knows what the &lt;homenet&g=
> t; label is,<br>
> &gt; should be able to masquerade on behalf of anything that isn&#39;t awar=
> e of the<br>
> &gt; divergence of the three possible values for &lt;homenet&gt;? If you en=
> d up with<br>
> &gt; some boxes thinking it is &quot;.home&quot;, some &quot;.homenet&quot;=
> , and some<br>
> &gt; &quot;.homenet.arpa&quot;, as long as one of them knows about all thre=
> e, it should<br>
> &gt; be possible to resolve the differences.<br>
> &gt;<br>
> &gt; The scope of the namespace is &quot;the home network&quot;, and never =
> reaches the<br>
> &gt; real DNS (roots), so at worst it would be folding the three fake<br>
> &gt; namespaces into a unified (three-headed) fake namespace.<br>
> <br>
> </div></div>Can we please stop with this &quot;and never reaches the real D=
> NS (roots)&quot;<br>
> garbage.=C2=A0 Queries for homenet/DS *will* reach the roots.=C2=A0 That is=
> <br>
> how DNSSEC validation is designed to work.=C2=A0 They *need* to be<br>
> answered with a signed NOERROR NODATA response.=C2=A0 Lots of Linux<br>
> distributions ship with DNSSEC validation enabled for on machine<br>
> clients and they are also configured to forward to the nameservers<br>
> that are returned by DHCP.<br>
> <br>
> These machines behave *exactly* like a validating stub resolver from<br>
> the DNSSEC perspective.=C2=A0 This isn&#39;t something that will be in the<=
> br>
> future.=C2=A0 It is the PRESENT.<br>
> <div class=3D"HOEnZb"><div class=3D"h5"><br>
> &gt; I.e. avoid it if you can, but if you can&#39;t, I think the issues are=
> <br>
> &gt; solvable, even if they get a little funky/ugly under the hood.<br>
> &gt;<br>
> &gt; None of that should be visible to users, I don&#39;t think.<br>
> &gt;<br>
> &gt; Brian<br>
> &gt;<br>
> &gt; P.S. Guide to implementers - never expose multiple handles for the sam=
> e<br>
> &gt; object; over-exuberant users may be tempted to try to &quot;clean up&q=
> uot; the<br>
> &gt; duplicates.<br>
> <br>
> </div></div><span class=3D"HOEnZb"><font color=3D"#888888">--<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"[phone]">+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:[e-mail]">[e-mail]</a><br>
> </font></span></blockquote></div><br></div>
> 
> --001a113ec618c0ed6c054bf663af--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]