In message <cah1iciqi_xjjwxvsr-x76fcz20niugnjyqamek1zhwd+54s...@mail.gmail.com> , Brian Dickson writes: > > On Thu, Feb 9, 2017 at 2:48 PM, Mark Andrews <ma...@isc.org> wrote: > > > > > In message <12d7473b-3a22-4a8d-9c13-2aeedeabb...@fugue.com>, Ted Lemon > > writes: > > > > > > On Feb 9, 2017, at 3:45 PM, Mark Andrews <ma...@isc.org> 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: +61 2 9871 4742 INTERNET: ma...@isc.org > > > > --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"><<a h= > ref=3D"mailto:ma...@isc.org"; target=3D"_blank">ma...@isc.org</a>></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 <<a href=3D"mailto:12D7473B-3A22-4A8D-9C13-2AEEDEABB879@fugue= > .com">12D7473B-3A22-4A8D-9C13-<wbr>2aeedeabb...@fugue.com</a>>, Ted Lemo= > n writes:<br> > ><br> > > On Feb 9, 2017, at 3:45 PM, Mark Andrews <<a href=3D"mailto:marka@i= > sc.org">ma...@isc.org</a>> wrote:<br> > > > At the moment we have Ted saying that if you want privacy you MUS= > T<br> > > > also turn on DNSSEC validation and implement QNAME minimisation a= > nd<br> > > > implement agressive negative caching (still a I-D).<br> > ><br> > > No, I am _not_ saying that.=C2=A0 =C2=A0I am saying that an unsigned d= > elegation<br> > > doesn't help with privacy unless you also specially configure your= > local<br> > > resolver, and if you are going to specially configure your local<br> > > resolver, then there are several options for how to do that.=C2=A0 =C2= > =A0The only<br> > > reason you need DNSSEC is that if you specially configure your local<b= > r> > > resolver to lie, then DNSSEC validation will break that.=C2=A0 =C2=A0I= > f you aren't<br> > > doing DNSSEC validation, you can say any old thing in your local resol= > ver<br> > > 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 "foo.alt", 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 "foo.alt" can lie abo= > ut the contents of "foo.alt", 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 "alt" 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'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'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't stop it.<br></blockquote><div><br></div><div><br></div><d= > iv>There's something I don'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", in my example above, that would be "foo.alt") is n= > ot configured, why does leaking matter? Obviously the real local use case i= > s "won't work - broken config", and leaking is mostly moot.</= > div><div><br></div><div>In the case where the local namespace is instantiat= > ed, the queries won'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't agree, if = > that is what you are asserting.</div><div>Queries for "rumplestiltskin= > .foo.alt" can't expect privacy, unless they are using a resolver s= > pecifically configured for "foo.alt".</div><div>Note that default= > ing to providing "empty.as112.arpa", and having the DNAME to &quo= > t;alt.empty.as112.arpa", would further actually accomplish privacy, wi= > thout affecting the local instantiation of "foo.alt" via "fo= > o.alt.empty.as112.arpa".</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't<b= > r> > require validation to be enabled.<br> > <br> > It'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"+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:ma...@isc.org";>ma...@isc.org</a><br> > </div></div></blockquote></div><br></div></div> > > --001a113fece2d952b805482113d7-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
