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

[Mark Nottingham <[e-mail]>]

Hi Vittorio,

> On 27 Aug 2019, at 7:07 pm, Vittorio Bertola <vittorio.bertola=[e-mail]> wrote:
> 
> For example, rather than having to alter the response (and break DNSSEC) to redirect the user to a meaningful explanation page, a filtering resolver could just return the "blocked" or "censored" error code and add the altered IP address / explanation URL somewhere in an extra field - the "extra-text" of Warren's draft or something more specific - which the client could then use to show the resolver's message to the user. This would require client support, while old clients would just get the error rather than the altered response, so we'd have to think whether this could actually work in all use cases, but still, once widely implemented, this would provide a cleaner architecture and a better user experience in the basic "web filter" cases. 

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. 

While technical people (like those on this list) might be able to interpret such a message safely and productively, many users of the Internet don't have that skill; for similar reasons, browsers have substantially changed the user experience of security for TLS over the last few years, and are continuing to do so, so that it's "safe by default", even in the face of user ignorance / apathy. 

Cheers,

--
Mark Nottingham   https://www.mnot.net/