[DNSOP] Client Validation - filtering validation?

[Brian Dickson <[e-mail]>]

On Fri, Apr 24, 2020 at 11:56 PM Paul Vixie <[e-mail]> wrote:

> mind if i cut in?
>
> On Saturday, 25 April 2020 06:23:54 UTC Vladimír Čunát wrote:
> > Original subject: New draft on delegation revalidation
> >
> > On 4/24/20 4:49 PM, Shumon Huque wrote:
> > > ...
> >
> > ...
>
> (agreeableness.)
>
> > Some of them also want a variant of DNS filtering, which
> > still clashes with validation a bit (if done *after* filtering).
>
> it will be necessary for filtered results to be separately (hop by hop)
> signed
> using something like SIG(0) or TSIG. (stubs ought to choose who can
> filter.)
> but this isn't a substitute for stub validation (end to end). one ought
> not
> trust a coffee shop or even one's own ISP to make a trusted introduction
> to
> one's bank (more or less quoting dan kaminsky from back in 2008 or so.)
>


I've been thinking about whether/how a provider of filtering service
(directly or indirectly) could be explicitly trusted to provide filtered
"answers".

It might be necessary to restrict what kinds of answers could be provided
within that scheme, in order to prevent or limit the potential for abuse.

If the client had a validating forwarder, the following would at least in
theory be possible to do:

   - Download the appropriate additional trust anchor for the filtering
   service
   - Filtered responses would be signed with this trust anchor
   - The validating forwarder would validate those using the trust anchor

This supposes that authoritative answers are served by the resolver (and
thus it would not rely on other cached responses), and that those are
signed by the filtering service.

It might be necessary for the client machine to associate a particular set
of such trust anchors with the network environment (including things like
DHCP server, DNS resolver, etc.).

Having signed filtered responses (including NXDOMAIN and/or rewritten
answers) would allow the client to do DNSSEC validation.

I'm not sure how much incremental work is required to do this, beyond some
method of discovery of trust anchors.

I think there would need to be some limitations on rewritten answer, e.g.
ranges of IP for walled garden, or domain names, or even whether positive
or negative answers are allowed.
My intuition would be that the namespace should be subordinate to the name
of the domain serving the filtering service (rpz-service.example.com as an
example) and/or limited to internal IP addresses (RFC 1918 or similar, or
some similarly scoped IP range that can be identified as "local".)

Thoughts?

Does this make sense at all?

(I've been a big proponent of RPZ for a long time now, and am interested in
some solution to client DNSSEC validation that can interoperate with RPZ.)

Brian