Hi Paul, Please see inline
On Mon, 5 May 2025 at 21:56, Paul Wouters <p...@nohats.ca> wrote: > On Mon, 5 May 2025, Stephane Bortzmeyer wrote: > > > On Mon, May 05, 2025 at 12:49:28PM +0000, > > Eric Vyncke (evyncke) <evyncke=40cisco....@dmarc.ietf.org> wrote > > a message of 200 lines which said: > > > >> * Are full-text explanations better or worse from UX or security > >> point of view ? > > > > Indeed, it was mentioned and I am quite surprised. Because DNS already > > has full-text explanations since 2020 (RFC 8914) and nobody > > complained. draft-ietf-dnsop-structured-dns-error-15 does not change > > that. > > RFC 8914: > > This information is intended for human consumption (not automated > parsing) > > draft-ietf-dnsop-structured-dns-error: > > This document describes a format for computer-parsable data in the > EXTRA-TEXT field of [RFC8914]. > > > With the reason qualified as: > > One of the other benefits of the approach described in this > document is to eliminate the need to "spoof" block pages for > HTTPS resources. This is achieved since clients implementing this > approach would be able to display a meaningful error message, > and would not need to connect to such a block page. > > I am not sure why a JSON object for a browser would produce a more > "meaingful error message" than one that is possible with RFC 8914 ? > It is designed for clients to interpret and render meaningful, user-friendly messages. This approach has already seen adoption, such as in AdGuard’s DNS SDE extension <https://github.com/AdguardTeam/dns-sde-extension>, which shows how structured DNS error reporting can enhance end-user communication. > > The example given is: > > { > "c": [ > "tel:+358-555-1234567", > "sips:b...@bobphone.example.com" > ], > "j": "malware present for 23 days", > "s": 1, > "o": "example.net Filtering Service" > "l": "tzm", > } > > First of all, the contact details are completely untrusted (eg when > obtaining a DNS via DHCP) or superfluous (eg when the user configured > 8.8.8.8 they already know they can go to dns.google.com for help) > On an Enterprise network, there is already a "contact IT" method in > place. On a Home network that auto-configured its CP device, you already > know to contact your ISP and don't need to get a copy of their phone > number, sips: or email address (or website). > > Note that an attacker being able to give you an email address to use > is very dangerous - it will facilitate endusers to receive malicious > email responses from an attacker. > The risks associated with displaying attacker-provided contact details are already addressed in the draft (see https://www.ietf.org/archive/id/draft-ietf-dnsop-structured-dns-error-15.html#section-10.2). The draft explicitly states that displaying the "c" field is not mandatory and outlines conditions under which it may be shown. While a home admin or IT department may already know the resolver’s contact details, other users on the network often do not. Providing contact information in structured form improves ease-of- use, allowing users to report filtering errors without having to independently search for their ISP’s or administrator’s support details. > The text "malware present for 23 days" and "example.net Filtering Service" > could have already been placed in the EXTRA-TEXT field as per RFC8914. > > > The draft further states: > > Whether the information provided in the "j" name is meaningful > or considered as garbage data (including empty values) is local > to each IT teams. > The draft seems the cherry-pick whether the content is meant for > endusers ("to eliminate the need to "spoof" block pages for HTTPS > resources") or when it is meant for IT teams. I think IT teams can > figure out who admins a DNS resolver on a certain IP already. The > non-admins are just vulnerable to misinformation. > Relying solely on the EXTRA-TEXT field to carry "j" would prevent carrying other structured fields intended for both IT admins and end-users. This is precisely why separating structured information into dedicated fields is necessary to allow selective display to end-users and logging for IT admins. > > And this: > > This approach thus avoids the need to install a local root > certificate authority on those IT-managed devices. > > Is clearly targetting endusers. > > > I believe this document is actually harmful to endusers, with no > meaningful gains for IT teams. If I was a browser vendor, I would > only allow displaying i18n text for EDE enums. > please elaborate how it is harmful to end-users. Cheers, -Tiru > > > Now Mark Nottingham does a fair attempt at trying to contain the > problem of display free text for the enduser in > draft-nottingham-public-resolver-errors > by constraining the EXTRA-TEXT to just two IDs that map to a DNS > provider and an incidence number. But that will lead us back to > attacker induced spoof pages, eg: > > The network / attacker does a: > > - redirecting major IPs port 53 to itself (eg 1.1.1.1, 8.8.8.8, 9.9.9.9) > (and block DoT, DoH, DoQ) > - issuing DHCP DNS servers to itself. > - transparently run all port 53 through its own resolver. > > then: > > - Use a globally trusted ID from the DNS Resolver Identifier Registry, eg > the one from Google DNS. > - Generate a filtered response with Extended DNS Error Code 17 (see > [RFC8914]) > and an EXTRA-TEXT field containing: > > { > "ro": "GoogleDNS", // or whatever they would have registered at IANAA > "inc": "abc123" // or whatever format Google DNS would use > } > > Let's assume Google DNS has registered the template: > > https://resolver-report.dns.google.com/filtering-incidents/{inc} > > then additionally: > > - resolve resolver-report.dns.google.com to itself. > - generate some self signed cert for resolver-report.dns.google.com > - publish malicious / advertising content on any URL on > resolver-report.dns.google.com > > > Since captive portals have already desensitized users into accepting > spoofed pages, this will still trick a percentage of users into going > to a malicious site (even if one cannot make it clickable, the text > can lure people to open a new tab/window and type in the name of the > website conveyed in the error msg, eg "visit www.fbi-arrests.io to > avoid an arrest warrant for trying to browse illegal content"). > > Furthermore, the incidents number can be customized for tracking or > deanonimising a user (eg one using Private Relay / MASQ). It would be > much better from a privacy perspective to only allow the QNAME to be > the incident number. > > Note also that RFC 8914 warns of the dangerous of EXTRA-TEXT causing DNS > fragmentation when messages are used that are too long. > > Mark's draft also causes more centalization of "well known/trusted DNS > servers". > > > I would suggest that instead of these solutions, > draft-ietf-dnsop-structured-dns-error > restricts itself to extend the ENUMs to cover most cases, and leave the > user / browsers to try and give more details errors, without the IETF > centralizing it using an IANA Registry. I would like it to deprecate > EXTRA-TEXT. > > If some kind of extra text option is _really_ needed, then extend RFC > 9606 resinfo with a template field that points to the resolver operators > extended error website, that browsers can use by filling in the template > URI with only the QNAME as option so it is guaranteed each user trying > to go to the same blocked domain gets the same error message and cannot > be deanonimized or tracked. > > Paul > > _______________________________________________ > 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
