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

On Tue, 18 Apr 2023 at 16:41, Benjamin Schwartz <ietf@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.

-Tiru

>
> I think the idea of "suberrors" for the "Censored" EDE code probably just
> doesn't make sense.  By definition, this code indicates that the resolver
> _doesn't_ know why the result was filtered.  (The resolver operator may
> know a _claimed_ reason, but it has no way to know whether this rationale
> is the real motivation.)  Thus, one way forward might be to exclude this
> code from the suberror registry.
>
> Even for the other codes, I think this registry opens a terrible can of
> worms that the IETF can and should avoid.  Shall we add codes for "adult
> content"? "advertising"? "social media"? "political extremism"? "terrorist
> content"? "CSAM"? "fake news"?
>
> The EDE draft manages this to some extent by presenting an initial list of
> codes that are plainly technical or structural in nature.  This draft does
> the opposite, by starting to enumerate all the perceived evils of the
> Internet.
>
> Let's not go down that road.
>
> On Fri, Apr 7, 2023 at 11:26 AM <mohamed.boucadair@orange.com> wrote:
>
>> Hi all,
>>
>>
>>
>> We are implementing the changes to address the feedback we received in
>> IETF#116. The candidate changes can be seen at Diff:
>> draft-ietf-dnsop-structured-dns-error-01.txt -
>> draft-ietf-dnsop-structured-dns-error.txt
>> <https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-dnsop-structured-dns-error&url_2=https://ietf-wg-dnsop.github.io/draft-ietf-dnsop-structured-dns-error/draft-ietf-dnsop-structured-dns-error.txt>
>>
>>
>>
>> The current version of the draft indicates that the policy for
>> registering a new suberr is via DE. We added a guard to prevent that DEs
>> modify entries set via IETF review.
>>
>>
>>
>> I know that Ben indicated a preference for requiring IETF review for the
>> registry. This seems to me too restrictive, especially that the policy for
>> the EDE itself is FCFS. The argument that DEs will be pressured is not
>> specific to this registry and would a priori apply for every registry with
>> a DE policy.
>>
>>
>>
>> I think that we need a good balance to allow for useful suberr codes to
>> be registered without requiring much heaviness in the process that is
>> induced by an IETF review.
>>
>>
>>
>> Ben, if your concern is to have some control, what about requiring that
>> new registrations should be sent to the DEs and also to dnsop (or another
>> list), and that DEs should listen to whatever feedback received from the
>> list?
>>
>>
>>
>> Thank you.
>>
>>
>>
>> Cheers,
>>
>> Med
>>
>> _________________________________________________________________________________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>