[DNSOP] Re: Comments from IETF Last Call about draft-ietf-dnsop-structured-dns-error

[Paul Wouters <[e-mail]>]

On Tue, 6 May 2025, tirumal reddy wrote:

>       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, which shows how structured DNS error reporting can enhance end-user communication.  

I disagree. An ENUM can be handled by browsers to display text in the
locality of the user. This can just fling up a free text English
message, that you expect browsers to validate for potential harm
before displaying to the user. You are subcontracting out the
security risks you are introducing.

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

Ease of use for which users? Please tell me which of these users will
use this contact information:

1) Paul using a mobile phone, maybe connected to wifi or LTE.
2) Paul using a mobile phone, at home using a default CP from his ISP
3) Paul using a mobile phone, at home using his own stuff - he is a geek
4) Paul using a mobile phone, at starbucks, mall or airplane
5) Paul using a mobile phone, as BYOD at work
6) Paul using a mobile phone, in his hotel room
7) Paul using a Desktop at home
8) Paul using a Desktop at work

Tell me in which of these scenarios the contact info should be
displayed. Then do the same for Paul, now elderly at 90 years of
age, and not really understanding how is phone or desktop connects
to the internet at all.

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

I am fine with more enum's helping categorize why an answer is withheld.
I am having a problem with the EXTRA-TXT.

If an IT admin cannot find out who is responsible for a DNS filter, they
should probably switch DNS filter vendors. Worse, if their DNS service
providing this is compromised, they can't even trust it anyway. They
need to use their own resources and documentation, and not the network
provided one. I think claiming this is useful for non-endusers is just
not realistic. Which leaves us with endusers which means anything
displayed can and will be abused by attackers to manipulate vulnerable
endusers.

I see the main concern from an ISP being "It looks like we are broken
but we are merely following instructions (from government or the
commercial serivce opted in by the enduser) to filter/block a DNS
request".

So for that, ENUMs are enough and save to convey. And browsers can
translate enums for the user. Eg:

FILTERED_BY_DEVICE_REGULATORY
FILTERED_BY_DEVICE_USER_OPTIN_ADULT
FILTERED_BY_DEVICE_USER_OPTIN_ADBLOCKER
FILTERED_BY_ISP_REGULATORY
FILTERED_BY_ISP_USER_OPTIN_MALWARE

etc.


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

I've tried to explain this two times now. I hope this helps. Note that
it might also be helpful to read the below text where I explain how
Mark was trying to reduce the harm caused by your draft, but how I feel
it is still (too) dangerous to use freefom text ask Mark proposed.

Paul

> 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 -- [e-mail]
>       To unsubscribe send an email to [e-mail]
> 
> 
>