For the prior versions of draft (see https://datatracker.ietf.org/doc/html/draft-reddy-dnsop-error-page-08), the primary objection wasn’t about using HTML or plain text but rather the potential for URLs to convey unwarranted information. The main concern was that URLs could be misused by malicious resolvers to display ads or prompt users to install potentially harmful software or root certificates. Another issue highlighted was that TRRs (Trusted Recursive Resolvers) primarily validate only the DNS server operator’s privacy claims, yet could still use URLs to serve ads or other content which is not relevant to filtering.
We proposed several security mechanisms to protect end-users in Section 7, but these were ultimately dismissed. It seems that we are revisiting discussions from three years ago, which led to the draft-ietf-dnsop-structured-dns-error’s restricted scope. -Tiru On Thu, 14 Nov 2024 at 03:41, Ben Schwartz <bemasc=40meta....@dmarc.ietf.org> wrote: > I recall that the key objection there was related to displaying HTML > controlled by the DNS server. Limiting the responses to plain text, as > proposed here, makes it significantly less scary. > > --Ben > ------------------------------ > *From:* Ralf Weber <d...@fl1ger.de> > *Sent:* Monday, November 11, 2024 9:25 PM > *To:* Ben Schwartz <bem...@meta.com> > *Cc:* Ben Schwartz <bemasc=40meta....@dmarc.ietf.org>; Stephane > Bortzmeyer <bortzmeyer=40nic...@dmarc.ietf.org>; Mark Nottingham <mnot= > 40mnot....@dmarc.ietf.org>; dnsop@ietf.org <dnsop@ietf.org> > *Subject:* Re: [DNSOP] New Version Notification for > draft-nottingham-public-resolver-errors-00.txt > > > > Moin! > > On 8 Nov 2024, at 6:07, Ben Schwartz wrote: > > 1. Prevent DDoS attacks. A malicious DNS server could cause a large > number of clients to fetch incident reports from an arbitrary victim > server. (c.f. Great Cannon [A]) > > As the initial structured error draft requires encrypted DNS this is not > possible, or I am failing to see how that would work. > > > > 2. Block reports that transited a naive forwarder. These reports could > be inauthentic, if the forwarder's upstream transport is unencrypted. > > EDNS0 is hop by hop so the forwarder would per default not copy it anyway. > > > > We could probably develop some technical mechanism that prevents both of > these attacks without the same-domain requirement. However, that may not > be necessary. As Emily points out, clients (i.e. browsers) might have > their own reputation systems for determining which reports can safely be > displayed to the user. > > > > When the client applies its own reputation system, the same-domain > requirement and central registry are both unnecessary. > > I’m having a deja vu here. Earlier versions had an URL as notification > target in there and clients could have done their own reputation systems > with this, but we were told that there was no way clients would be getting > data from a URL in a DNS packet. > > This draft puts an intermediate layer on it with the registry, which IMHO > fixes this and removes the same domain requirement. > > So long > -Ralf > ——- > Ralf Weber > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
