On Fri, Apr 24, 2020 at 11:56 PM Paul Vixie <p...@redbarn.org> 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
