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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
