Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt

[Peter Thomassen <[e-mail]>]

On 10/13/23 10:05, tirumal reddy wrote:
> The above attack and possible mitigation is discussed in the security considerations section of the draft, please see the snip below:
> </snip>
> 
>     A client might choose to display the information in the "c", "j", and
>     "o" fields 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 limits the ability of a malicious encrypted
>     resolver to cause harm.  For example, an end user can use the details
>     in the "c" field to contact an attacker to solve the problem of being
>     unable to reach a domain.  The attacker can mislead the end user to
>     install malware or spyware to compromise the device security posture
>     or mislead the end user to reveal personal data.  If the client
>     decides not to display all of the information in the EXTRA-TEXT
>     field, it can be logged for diagnostics purpose and the client can
>     only display the resolver hostname that blocked the domain, error
>     description for the EDE code and the suberror description for the "s"
>     field to the end-user.
> 
> </snip>

I share this concern (and Eric's, where the error page is an impersonation of the target page!), and am not convinced that the potential benefit is larger than the harm.

An alternate route could be to make the error page "well-known", based on the encrypted resolver's hostname (e.g. https://dns.adguard.com/?malw.scalone.eu.), and have the browser display a big warning ("This content does not come from the page you requested.).

This could be combined with disabling redirects and/or form submissions on the resolver's domain origin, so that the resolver server itself has to be able to serve the page, without redirecting anywhere to make the domain name look differently and without collecting login credentials à la phishing. For a branded error page with nice UX, that should be completely sufficient. (Are there any known use cases not accommodated by this?)

I'm not sure this would alleviate all concerns (and perhaps it's not much better), but *at least* it would prevent trivial attacks where the error page would redirect me from twitter.com to twítter.com, even though I typed the former, but the latter has a proper TLS certificate, so I couldn't otherwise notice a problem.

Thanks,
Peter

-- 
https://desec.io/