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

[tirumal reddy <[e-mail]>]

Hi Paul,

Please see inline

On Wed, 7 May 2025 at 19:34, Paul Wouters <[e-mail]> wrote:

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

I am glad there’s no disagreement on this point :)


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

We seem to have a disagreement here, possibly due to differing
assumptions. It's
true that attackers won’t follow the Security Considerations. The threat model
assumed in the draft treats resolvers as potentially legitimate or malicious,
while clients are considered trusted and legitimate. The Security
Considerations
section is specifically designed to mitigate risks posed by malicious
resolvers.

If you could elaborate further on the nature of your concern, it would help us
understand the disagreement and address it more effectively.


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

Yes, I was referring specifically to spoof pages.


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

Your concern about untrusted networks is valid and we have no disagreement.

The draft explicitly recognizes this risk and includes guidance to mitigate it.
Specifically, as discussed in the Security Considerations section:

*“A client might choose to display the information in the 'c' field to the
end-user if and only if the encrypted resolver has sufficient reputation,
according to some local policy (e.g., user configuration, administrative
configuration, or a built-in list of respectable resolvers)...”*

This is intended to prevent clients from blindly displaying contact
information, such as those found on potential attacker-controlled networks. The
goal is to preserve user safety by ensuring that only trusted
resolvers can supply
user-facing details. Additionally, if the client chooses not to
display the full
content of the EXTRA-TEXT field, it can still log the information for
diagnostics.

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

The draft requires clients to display the "c" field only if the
resolver is trusted,
specifically to prevent exposing users to harmful information from untrusted
networks. Further, the draft does not require clients to display the "c" field,
even for trusted resolvers; it is entirely up to the client's local policy.

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

It highlights exactly why the draft leaves it entirely up to the client whether
to display user-facing information like the "c" field.


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

It's not practical to capture all possible reasons for blocking using ENUMs.
For example, OpenDNS defines numerous domain categories (see list
<https://community.opendns.com/domaintagging/categories>), and new
ones continue
to be added over time. During WG discussions, there was no consensus
to standardize
categories beyond security-related ones, as others may involve censorship or
policy-sensitive filtering. The "j" field provides necessary
flexibility to convey
resolver-specific reasons in a structured way but only to the IT admin.


> >
> >       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 agree that we’re aligned on the threat model. The difference seems to be in
our assessment of whether the proposed mitigations are sufficient to address
the associated risks.

Cheers,
-Tiru


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