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

[Ben Schwartz <[e-mail]>]

Note that "mailto" URIs can pre-populate subject and body contents, so information about the specific blocked item and other metadata could be populated automatically.  This seems sufficient for enterprise use cases like allowing employees to tell corporate IT that they are blocking something incorrectly.

HTTP error pages are primarily relevant to end users on personal devices whose access is being blocked by their ISP.   That is not an environment in which it is safe or appropriate for the network to inject block pages.

--Ben Schwartz
________________________________
From: DNSOP <[e-mail]> on behalf of Gianpaolo Angelo Scalone, Vodafone <Gianpaolo-Angelo.Scalone=[e-mail]>
Sent: Thursday, November 9, 2023 4:08 AM
To: [e-mail] <[e-mail]>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-07.txt

Hi, I still think that a mechanism to reach an HTTPS resource is needed. Considering the security implications of rendering directly an HTTPS URI, It could be an additional field, to be used by the client For out of band connection to retrieve


Hi,

I still think that a mechanism to reach an HTTPS resource is needed.

Considering the security implications of rendering directly an HTTPS URI,

It could be an additional field, to be used by the client

  *   For out of band connection to retrieve the needed page info from resolvers with high reputation that have agreements with the browser
  *   To connect to an high reputation service (to be created) having the only purpose to host blocking pages on behalf of the various DNS filtering services
     *   This high reputation service would be defined in a separated RFC
     *   Access criteria and content to be defined
     *   Management criteria to be defined



Having such a service would allow to access high reputation information about the eventual blocking reason and provide the end user modern methods to understand the blocking or request an amendment in case of false positives.



The mechanism proposed in draft-ietf-dnsop-structured-dns-error-07.txt is a big improvement respect the existing situation, but still requires some knowledge that common users may not have and so limit the capability to require amendments only to users well educated on the topic.

With a SIP contact or an EMAIL contact the end user should know what to ask very well, with an HTTPS URI a request to amend the blocking could be populated with the relevant information, empowering also less experienced users (here we are sort of providing a pre internet solution to an internet problem).



Many countries request filtering of DNS traffic for CSAM or for Adult Content Filtering reasons, so a good way to avoid false positives would provide the population a better access to internet.



Gianpaolo




C2 General