In message <capt1n1nlmdoz_3kb8kfp9stsn-gyqo1a9cf3j4zb7qcvo3s...@mail.gmail.com> , Ted Lemon writes: > How does a query for, e.g., super-s3kr1t.alt leak if your caching resolver > is doing qname minimization?
Because QNAME minimization does not stop on NXDOMAIN. Too much broken stuff out there to stop on NXDOMAIN. The purpose of QNAME minimization is prevent leaking too much information about the qname to the parent zone. It does nothing to prevent leakage of the QNAME to the containing zone. For that to happen you need the other two conditions to be met. > On Thu, Feb 9, 2017 at 5: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. > > > > 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. > > > > 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 > > > > --94eb2c0c8e5cca568e0548210c07 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > <div dir=3D"ltr">How does a query for, e.g., super-s3kr1t.alt leak if your = > caching resolver is doing qname minimization?</div><div class=3D"gmail_extr= > a"><br><div class=3D"gmail_quote">On Thu, Feb 9, 2017 at 5:48 PM, Mark Andr= > ews <span dir=3D"ltr"><<a href=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;border-left:1px #ccc solid;padding-left:1ex"><di= > v 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>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> > <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> > > --94eb2c0c8e5cca568e0548210c07-- -- 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
