> From: Paul Vixie <p...@redbarn.org>
> > 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 v...@rhyolite.com
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
