On Wed, 7 May 2025, tirumal reddy wrote:
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.
To clarify, the sub-error attribute, being an ENUM, can be rendered without
interpretation and is suitable for localization and consistent handling across
clients.
We do not have a disagreement on this part.
For other fields, specific restrictions are imposed to avoid the risks
associated with displaying its content.
We have a disagreement here. The bad guys don't follow the Security
Considerations.
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
You are questioning a long-standing practice of providing contact details in
HTTP(S) block pages to assist users. This isn’t new or experimentan, it’s a
well-established and widely deployed pattern. Resolvers that present block
pages include contact information by default. In fact, I’m not aware of any
major
resolver offering block pages that does not include such details.
It seems you are mixing up DNS blocking and spoof page presentations.
eg google states on https://developers.google.com/speed/public-dns/blocking
that they return REFUSED, so I don't understand how an enduser could end
up on a block page. Perhaps your claim above is not correct?
For instance, see real-world examples like OpenDNS block page and Quad9’s
collaboration where
users are directed for support or further action.
I tried seeing the opendns page, but I can't because both firefox and
chrome no longer allows an override to visit spoof pages, which is
the problem you are trying to address with this draft. I'm not sure
what kind of details they give out. Regardless, there is a difference
of seeing a page from Google DNS, OpenDNS, Quad9, Cloudflare DNS that
can be reasonably trusted, or seeing a page from any random network
you joined. Whether it is untrusted hotel/coffeeshop or perhaps a
CP device taken over my an attacker to reconfigure DNS to trick
people to go somewhere malicious.
Structured DNS error reporting simply standardizes this practice, with clear
restrictions on when the "c" field
should be displayed to the end-user.
Yes, it standardizes presenting potentially harmful information from a
few usually trusted DNS resolvers to any (potentially hostile) network
in the world. That is the core of the problem, and non-technical
endusers are going to become the victims.
For elderly users, it’s unlikely they would contact anyone directly, but family
members or caregivers assisting will benefit from the structured information to
report the problem or educate the elderly not to visit the blocked domain as it
is bad.
Having just spent two days reinstalling a windows machine with custom
malware running in C:\Users\User\Download, and a chrome browser that
pops up screens with "Your antivirus is disabled, CLICK HERE TO ENABLE"
and the person telling me they did click and renew they anti-virus but
the popup didn't go away, I really really really REALLY differ of
opinion with you my future 90 year old Paul will not click on these
things or make phone calls.
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".
IT admins typically know their resolver’s support contact details. The "j"
field helps them identify the exact reason a domain was blocked without needing to
contact the resolver’s helpdesk. For example, if a domain is blocked because it
is unclassified or misclassified, and the IT team sees multiple users accessing
it
for legitimate reasons, they can create an explicit allow rule and raise a
ticket with the resolver’s helpdesk.
ENUMs should be enough as a "reason" to be able to figure out if a block
was done in error ("without contacting the helpdesk"). IT admins can get
statistics on QNAMEs that got blocked for their internal investigations
without users calling them. Regardless, how you run your company and
helpdesk is out of scope for this document. Your users already know how
to contact their ISP or Enterprise admins.
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
The draft has already added a registry to update the enum in future
specifications.
We don't disagree about adding enums. We disagree about this draft doing
MORE than adding enums. In those more parts, I have security concerns
that you have not addressed and that I feel are not addressable.
I would really like to hear from the browser vendors on whether they
would support displaying custom error strings in DNS replies to their
endusers, and how they would handle the potential security issues with
this.
Paul
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
