Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Paul Vixie <[e-mail]>]

Vernon Schryver wrote:
> By "signed" I guess you mean signed by the resolver itself with some
> sort of public key ... If so, I agree that works,

yes.

> but I still don't see how that is as good as two dig's with one to
> a resolver trusted to give the truth.

there will in my model be only one resolver, and while it may or may not 
be trusted to tell the truth, it may or may not also be trusted to tell 
a useful lie. that is, truth has value, and some lies also have value, 
for example an RPZ answer of NXDOMAIN when the qname is a DGA. but right 
now we have no authentication of the lies, while we do have it for the 
truth (if DNSSEC is used). so, i am conflating two issues in my 
stick-figure of the moment: authentication of lie source and content, 
and, the ability of an end-user via resolv.conf or API to tell her local 
applications what lie-source to believe, if any.

> Whenever that in-band DNS truth red light *might* blink, you'll want
> a trusted resolver available so that when the light does blink your
> application gets honest DNS truth or honest RPZ lies.  ...

no, really. it's blink red first, and then either go offline or remain 
online, according to the user's risk tolerance. for me it's go offline.

there is no other resolver present to ask-also or ask-instead or ask-after.

rpz must become hop-by-hop authenticated, since there's no end-to-end 
for it. this may become the first valid use for dnscrypt.

> Principled objections to RPZ cannot be answered by RPZbis including
> truth with lies.  That is because an application must consistently
> choose either truth or possible RPZ lies.  Choosing RPZ lies for
> security and privacy defenses makes including the truth in RPZbis
> answers a sham and waste of bandwidth.  On the other hand, an application
> choosing truth makes the RPZ lies a waste of bandwidth.

i'm on a different trail entirely. we have to include the truth if it's 
dnssec signed, since the client will know we're lying if we do 
otherwise. but, in any valid RPZ deployment, the lies we tell are of 
value to the client, so we must include those. and, because those lies 
can otherwise be MITM'd, we must authenticate them hop-by-hop (that is, 
from the rDNS to the stub.)

> Which gets back yet again to the only place I think RPZ belongs, which
> is in a verifying resolver that you trust to do only the RPZ lying
> that you want (and so where you don't need that red light except when
> debugging).

between arp spoofing and ip-source spoofing, a stub has no reason to 
trust its rDNS -- that's why DNSSEC has to be visible end-to-end for 
DNSSEC-aware applications. we need to authenticate the source of a lie, 
since otherwise it could be inserted by some on-LAN malicious actor. 
while we might be able to use SIG(0) and the KEY RR for this, and that 
would be a form of DNSSEC, the form would be degenerate, since it's not 
the same as end-to-end source authentication of the DNS data as having 
been created by the legitimate operator of the zone whose key signed it. 
RPZ is divorced entirely from the zone whose key normally signs data 
having the owner = qname. so we have to authenticate hop by hop.

-- 
P Vixie