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

[Paul Wouters <[e-mail]>]

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 ?

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

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.


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