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

[Peter Thomassen <[e-mail]>]

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