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

On Thu, Nov 9, 2023 at 10:02 AM Ben Schwartz <bemasc=
40meta.com@dmarc.ietf.org> wrote:

> 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

In the Enterprise case , the end user does need to see some simple web
based feedback.  My employer's Firewalls throw up a very basic "You can not
go to example.com".

tim

> --Ben Schwartz
> ------------------------------
> *From:* DNSOP <dnsop-bounces@ietf.org> on behalf of Gianpaolo Angelo
> Scalone, Vodafone <Gianpaolo-Angelo.Scalone=40vodafone.com@dmarc.ietf.org>
> *Sent:* Thursday, November 9, 2023 4:08 AM
> *To:* dnsop@ietf.org <dnsop@ietf.org>
> *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
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>