On Wed, 19 Apr 2023 at 20:49, Benjamin Schwartz <i...@bemasc.net> wrote:
> > > On Wed, Apr 19, 2023 at 10:04 AM tirumal reddy <kond...@gmail.com> wrote: > >> On Tue, 18 Apr 2023 at 16:41, Benjamin Schwartz <i...@bemasc.net> wrote: >> >>> The draft's opening words are "DNS filtering is widely deployed for >>> network security". This is true, but by far the "widest" deployment of DNS >>> filtering is for authoritarian national censorship, to prevent citizens >>> from engaging with forbidden ideas. >>> >>> The EDE draft acknowledges and rebukes this rather directly with the >>> "Censored" code, expressing that this filtering was performed _against_ the >>> preference of the resolver operator. Although the EDE registry is FCFS, >>> the presence of this registry entry at the outset ensures that any attempt >>> to whitewash this sort of behavior would be duplicative. >>> >>> The "structured errors" draft risks undermining this norm and diluting >>> the intent of the "Censored" code. For example, the "Malware", "Phishing", >>> "Spam", and "Spyware" suberrors are listed as applicable to the "Censored" >>> code, which is rather strange. What is a "Spam" domain, and when would a >>> resolver be forced to filter it "due to an external requirement imposed by >>> an entity other than the operator"? >>> >> >> Yes, "Spam" is not suitable with "Censored" code. The other suberror >> codes may be applicable with "Censored" code. For instance, in a deployment >> where the network-provided DNS forwarder is configured to use a public >> resolver to filter malware domains. >> > > "Censored" requires that the blocking is "due to an external requirement > imposed by an entity other than the operator of the server resolving or > forwarding the query". This does not correspond to the situation you are > describing, where the filtering is "inherited" but not "required" or > "imposed". > > I don't know of any situation today in the world where "Censored" could > logically be used with any of these sub-errors. We would have to imagine a > situation where the resolver operator is being _forced_ to apply malware > filtering, not choosing to do so. > I see your point, will remove use of "Censored" from the draft. We probably need a new error code (Blocked by upstream server) to address the above scenario. The server (e.g, DNS forwarder) is unable to respond to the request because the domain is on a blocklist due to an internal security policy imposed by the upstream server (e.g., DNS resolver). > Personally, I don't think these "sub-errors" make a lot of sense for > "Censored". We should consider excluding "Censored" from this draft, or > focusing instead on providing objective information about the block. We > can take inspiration from some of the work related to HTTP 451: > - RFC 7725 defines the "blocked-by" relation, to identify the party that > implemented the censorship. This is relevant to DNS when forwarders are in > use. > - draft-sahib-451-new-protocol-elements-01 (expired) proposed > "blocking-authority" and "geo-scope-block" headers to identify the source > and scope of the block. > > Regardless of the draft's details, I think work related to DNS filtering > should generally receive HRPC review prior to WGLC. > Sounds good to me. -Tiru > > --Ben Schwartz >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
