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/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
