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

[tirumal reddy <[e-mail]>]

On Wed, 19 Apr 2023 at 20:49, Benjamin Schwartz <[e-mail]> wrote:

>
>
> 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.
>

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
>