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