Nargh, I forgot my main point, which was on the suggestion in the security considerations to only diepslay
"c"/"j"/"o" iff the resolver has sufficient
reputation, according to some local policy (e.g., user configuration,
administrative configuration, or a built-in list of respectable
resolvers).
I think this needs to be fleshed out more to be helpful.
For example, when my resolver is configured dynamically as I switch networks,
how can users (or even administrators, for mobile devices) be expected to
assess and configure a resolver's reputation?
And if we expect this to not be configured in most cases, with "c"/"j"/"o" not
being used as a consequence, then why bother?
Regarding the built-in list of respectable resolvers, who should maintain this
list, and why? And how often is updated in browser? etc.pp. Smells like a PSL
kind of problem ...
Thanks,
Peter
On 10/16/23 12:37, Peter Thomassen wrote:
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
--
Like our community service? 💛
Please consider donating at
https://desec.io/
deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany
Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
