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

From: Vernon Schryver <[email-masked]>
Date: Thu, 17 Aug 2017 03:43:55 GMT

> From: Paul Vixie <[email-masked]>

> > A network that routes requests to 8.8.8.8 to inject DNS lies will also
> > arrange to ignore or pervert any DNS-in-band tell-the-truth signaling.
> > Without access to a trustworthy resolver, tell-the-truth signaling is
> > useless because you can't trust it.
> 
> i would like to be able to know that i can't trust it, rather than
> merely assuming that i can't trust it, as happens today. if neither the
> truth nor the lie is signed, i can make a red light blink, or even go
> offline, refusing the local edition of the social compact ("if you want
> to use the internet you have to accept dns answers w/o provenance.")

By "signed" I guess you mean signed by the resolver itself with some
sort of public key (perhaps DLV, double dnssec, one of the other secure
DNS schemes, or something new) or with TSIG using a symmetric key
previously shared with the resolver.  (Having the stub verify DNSSEC
to validate the truth and turn off the red light would make the stub
a lot like a verifying resolver.)

If so, I agree that works,

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.

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.  But with that
trusted verifying resolver you can use 2 digs and don't need the
protocol or implementation costs of inband RPZ truth and you needn't
to surmount principled IETF opposition to sanctioning RPZ.

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.

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).  All other uses of RPZ should be considered attacks on
your security and privacy.  (I think that's a short form of the agreed
words that I'm waiting to be told to add to the draft.)

Vernon Schryver    [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 16 Aug 2017 22:40:04 -0700

Vernon Schryver wrote:
> sort of public key ... If so, I agree that works,

yes.

> 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.

> 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.

> 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.)

> 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