Re: [Add] Communicating DNS blocks (was Re: A thought -- Move the policy decisions outside the application.)

[Vittorio Bertola <[e-mail]>]

> Il 28 agosto 2019 03:26 Mark Nottingham <[e-mail]> ha scritto:
> 
> Similar things have been proposed in the past, at other layers; e.g., 
>   https://www.ietf.org/archive/id/draft-nottingham-proxy-explanation-00.txt
> 
> There's a bigger issue than figuring out how to make it backwards-compatible. Without trying to speak for them, the impression I got is that the browser vendors are less than enthusiastic about exposing untrusted content to users, even if it's heavily constrained (as is the case in the proposal above), as it's a potential attack vector. 

Thanks for sharing this. It prompted some thoughts on what kind of untrusted content could come this way, as I assume that we could authenticate the resolver and keep the channel secure, and even require EV certificates so that the user could know who is sending the message on the landing page.

I do see risks if you are using an untrusted resolver: for example, the resolver could reply to a request for www.mybank.example with a "blocked" error and a redirection to a phishing page. However, how is this different from an untrusted resolver today, without those extensions? It could already reply with the IP of a phishing page and even claim that it's been DNSSEC-validated.

On the other hand, this kind of enhanced user experience could also be a driver for resolvers to adopt encryption and authentication and get into a "trusted resolver" status (however ascertained).

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[e-mail] | [phone]
Office @ Via Treviso 12, 10144 Torino, Italy