Re: [DNSOP] draft-ietf-dnsop-structured-dns-error: suberr registration policy

[Benjamin Schwartz <[e-mail]>]

On Wed, Apr 19, 2023 at 10:04 AM tirumal reddy <[e-mail]> wrote:

> On Tue, 18 Apr 2023 at 16:41, Benjamin Schwartz <[e-mail]> 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.

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.

--Ben Schwartz