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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>
, Brian Dickson writes:
> 
> On Thu, Feb 9, 2017 at 2:48 PM, Mark Andrews <[e-mail]> wrote:
> 
> >
> > In message <[e-mail]>, Ted Lemon
> > writes:
> > >
> > > On Feb 9, 2017, at 3:45 PM, Mark Andrews <[e-mail]> wrote:
> > > > At the moment we have Ted saying that if you want privacy you MUST
> > > > also turn on DNSSEC validation and implement QNAME minimisation and
> > > > implement agressive negative caching (still a I-D).
> > >
> > > No, I am _not_ saying that.   I am saying that an unsigned delegation
> > > doesn't help with privacy unless you also specially configure your local
> > > resolver, and if you are going to specially configure your local
> > > resolver, then there are several options for how to do that.   The only
> > > reason you need DNSSEC is that if you specially configure your local
> > > resolver to lie, then DNSSEC validation will break that.   If you aren't
> > > doing DNSSEC validation, you can say any old thing in your local resolver
> > > and the stub will believe it.
>
> Suppose a signed delegation for alt, to some widely operated, centrally
> managed servers (say, the arpa servers).

All delegations from the root are signed as the root zone is signed.
The difference is it a secure delegation (with DS record) or a
insecure delegation (proof of non existance of the DS).

I'd insecurely delegate alt to the root servers themselves.  There
is no point in spreading the leakage.

> Now suppose an unsigned delegation for some other name under alt, such as
> "foo.alt", to an empty zone on the same set of servers.
> 
> The only difference here is where the unsigned delegation is, and what the
> scope of that delegation is.
> 
> In this scenario, any local "foo.alt" can lie about the contents of
> "foo.alt", because it is outside of the secure delegation chain from the
> root.
> 
> The only difference is that the delegation is not directly from the root.
> 
> Any other name under "alt" would have its existence securely denied, unless
> and until a request for an insecure delegation was made and approved.
> 
> Is there a problem with this scenario?

It requires alt to be a registry.  One of the point of this I-D is
to get a namespace that doesn't have a registry.

> > And a signed answer doesn't help unless the recursive server is
> > validating (so it can trust the NXDOMAIN) and has QNAME minimimistion
> > (to prevent *.alt leaking in the first place) and has agressive
> > negative caching (so the answer from the minimised QNAME query get
> > turned into a answer for *.alt).
> >
> > Now we can put QNAME minimisation into a server.
> > Now we can put the code to support agressive negative caching into a
> > server.
> > We can't force validation to be enabled.
> >
> > We need all three things for the privacy leakage to stop.  Any two
> > alone doesn't stop it.
> >
> 
> 
> There's something I don't understand.
> 
> In the case where the local namespace (in your email, that would be "alt",
> in my example above, that would be "foo.alt") is not configured, why does
> leaking matter? Obviously the real local use case is "won't work - broken
> config", and leaking is mostly moot.
> 
> In the case where the local namespace is instantiated, the queries won't
> leak to the root, so privacy is assured.
> 
> Are you saying that leakage when the local namespace is non-existent, is
> a/the issue?

Because when TPB go on a witch hunt for all users of xxxx.alt we
don't want the root servers operators to be able to return the
addresses.  It's not a matter of if, just when.  We have seen that
happen too many times.

> I don't agree, if that is what you are asserting.
> Queries for "rumplestiltskin.foo.alt" can't expect privacy, unless they are
> using a resolver specifically configured for "foo.alt".
> Note that defaulting to providing "empty.as112.arpa", and having the DNAME
> to "alt.empty.as112.arpa", would further actually accomplish privacy,
> without affecting the local instantiation of "foo.alt" via
> "foo.alt.empty.as112.arpa".

A DNAME doesn't give privacy.  You need QNAME minimisation with a
qtype of DNAME instead of NS.

> Brian
> 
> 
> >
> > The alternative is to do a insecure delegation and build in a default
> > empty zone for alt.  You then have to take steps to break the privacy
> > leak by disabling the empty zone.  Additionally it works with all
> > existing servers if they just add a empty .alt zone.  It doesn't
> > require validation to be enabled.
> >
> > It's the difference between defaulting private or not.
> >
> > Mark
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: [phone]                 INTERNET: [e-mail]
> >
> 
> --001a113fece2d952b805482113d7
> 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 Thu, Feb 9, 2017 at 2:48 PM, Mark Andrews <span dir=3D"ltr">&lt;<a h=
> ref=3D"mailto:[e-mail]" target=3D"_blank">[e-mail]</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:12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue=
> .com">12D7473B-3A22-4A8D-9C13-<wbr>[e-mail]</a>&gt;, Ted Lemo=
> n writes:<br>
> &gt;<br>
> &gt; On Feb 9, 2017, at 3:45 PM, Mark Andrews &lt;<a href=3D"mailto:marka@i=
> sc.org">[e-mail]</a>&gt; wrote:<br>
> &gt; &gt; At the moment we have Ted saying that if you want privacy you MUS=
> T<br>
> &gt; &gt; also turn on DNSSEC validation and implement QNAME minimisation a=
> nd<br>
> &gt; &gt; implement agressive negative caching (still a I-D).<br>
> &gt;<br>
> &gt; No, I am _not_ saying that.=C2=A0 =C2=A0I am saying that an unsigned d=
> elegation<br>
> &gt; doesn&#39;t help with privacy unless you also specially configure your=
>  local<br>
> &gt; resolver, and if you are going to specially configure your local<br>
> &gt; resolver, then there are several options for how to do that.=C2=A0 =C2=
> =A0The only<br>
> &gt; reason you need DNSSEC is that if you specially configure your local<b=
> r>
> &gt; resolver to lie, then DNSSEC validation will break that.=C2=A0 =C2=A0I=
> f you aren&#39;t<br>
> &gt; doing DNSSEC validation, you can say any old thing in your local resol=
> ver<br>
> &gt; and the stub will believe it.<br>
> <br></div></div></blockquote><div><br></div><div>Suppose a signed delegatio=
> n for alt, to some widely operated, centrally managed servers (say, the arp=
> a servers).</div><div>Now suppose an unsigned delegation for some other nam=
> e under alt, such as &quot;foo.alt&quot;, to an empty zone on the same set =
> of servers.</div><div><br></div><div>The only difference here is where the =
> unsigned delegation is, and what the scope of that delegation is.</div><div=
> ><br></div><div>In this scenario, any local &quot;foo.alt&quot; can lie abo=
> ut the contents of &quot;foo.alt&quot;, because it is outside of the secure=
>  delegation chain from the root.</div><div><br></div><div>The only differen=
> ce is that the delegation is not directly from the root.</div><div><br></di=
> v><div>Any other name under &quot;alt&quot; would have its existence secure=
> ly denied, unless and until a request for an insecure delegation was made a=
> nd approved.</div><div><br></div><div>Is there a problem with this scenario=
> ?</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"><div class=3D"HOEnZb=
> "><div class=3D"h5">
> </div></div>And a signed answer doesn&#39;t help unless the recursive serve=
> r is<br>
> validating (so it can trust the NXDOMAIN) and has QNAME minimimistion<br>
> (to prevent *.alt leaking in the first place) and has agressive<br>
> negative caching (so the answer from the minimised QNAME query get<br>
> turned into a answer for *.alt).<br>
> <br>
> Now we can put QNAME minimisation into a server.<br>
> Now we can put the code to support agressive negative caching into a server=
> .<br>
> We can&#39;t force validation to be enabled.<br>
> <br>
> We need all three things for the privacy leakage to stop.=C2=A0 Any two<br>
> alone doesn&#39;t stop it.<br></blockquote><div><br></div><div><br></div><d=
> iv>There&#39;s something I don&#39;t understand.=C2=A0</div><div><br></div>=
> <div>In the case where the local namespace (in your email, that would be &q=
> uot;alt&quot;, in my example above, that would be &quot;foo.alt&quot;) is n=
> ot configured, why does leaking matter? Obviously the real local use case i=
> s &quot;won&#39;t work - broken config&quot;, and leaking is mostly moot.</=
> div><div><br></div><div>In the case where the local namespace is instantiat=
> ed, the queries won&#39;t leak to the root, so privacy is assured.</div><di=
> v><br></div><div>Are you saying that leakage when the local namespace is no=
> n-existent, is a/the issue?</div><div><br></div><div>I don&#39;t agree, if =
> that is what you are asserting.</div><div>Queries for &quot;rumplestiltskin=
> .foo.alt&quot; can&#39;t expect privacy, unless they are using a resolver s=
> pecifically configured for &quot;foo.alt&quot;.</div><div>Note that default=
> ing to providing &quot;empty.as112.arpa&quot;, and having the DNAME to &quo=
> t;alt.empty.as112.arpa&quot;, would further actually accomplish privacy, wi=
> thout affecting the local instantiation of &quot;foo.alt&quot; via &quot;fo=
> o.alt.empty.as112.arpa&quot;.</div><div><br></div><div>Brian</div><div>=C2=
> =A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
> r-left:1px #ccc solid;padding-left:1ex">
> <br>
> The alternative is to do a insecure delegation and build in a default<br>
> empty zone for alt.=C2=A0 You then have to take steps to break the privacy<=
> br>
> leak by disabling the empty zone.=C2=A0 Additionally it works with all<br>
> existing servers if they just add a empty .alt zone.=C2=A0 It doesn&#39;t<b=
> r>
> require validation to be enabled.<br>
> <br>
> It&#39;s the difference between defaulting private or not.<br>
> <span class=3D"HOEnZb"><font color=3D"#888888"><br>
> Mark<br>
> </font></span><div class=3D"HOEnZb"><div class=3D"h5">--<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>
> </div></div></blockquote></div><br></div></div>
> 
> --001a113fece2d952b805482113d7--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]