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"? 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.boucad...@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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
