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