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

[tirumal reddy <[e-mail]>]

Hi Paul,

Please see inline

On Mon, 5 May 2025 at 21:56, Paul Wouters <[e-mail]> wrote:

> On Mon, 5 May 2025, Stephane Bortzmeyer wrote:
>
> > On Mon, May 05, 2025 at 12:49:28PM +0000,
> > Eric Vyncke (evyncke) <evyncke=[e-mail]> 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:[phone]",
>      "sips:[e-mail]"
>    ],
>    "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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>