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

["Gianpaolo Angelo Scalone, Vodafone" <[e-mail]>]

Hi Tim ,
I'm not proposing that the browser shows an https page in any use case,
Only as result of out of band request or if received from well known service,
Eventually by creating a service for hosting well known high reputation static only blocking pages.
Without this the user remain subject to false positives without being able to request a reclassification,
Resulting in potentially unwanted censorship...

Gianpaolo

Inviato da Outlook per Android<https://aka.ms/AAb9ysg>



C2 General

________________________________
Da: Ben Schwartz <bemasc=[e-mail]>
Inviato: Giovedì, Novembre 9, 2023 5:14:26 PM
A: Tim Wicinski <[e-mail]>; Ben Schwartz <[e-mail]>
Cc: Gianpaolo Angelo Scalone, Vodafone <[e-mail]>; [e-mail] <[e-mail]>
Oggetto: Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-07.txt


External Email: Be cautious about the sender email address, attachments and links. If uncertain use Report Message button.

Tim,

The EDE error codes cover that use case already, by allowing the browser to generate that error page, and without requiring the DNS filter to run an HTTP server at all.

--Ben Schwartz
________________________________
From: DNSOP <[e-mail]> on behalf of Tim Wicinski <[e-mail]>
Sent: Thursday, November 9, 2023 10:48 AM
To: Ben Schwartz <bemasc=[e-mail]>
Cc: Gianpaolo Angelo Scalone, Vodafone <Gianpaolo-Angelo.Scalone=[e-mail]>; [e-mail] <[e-mail]>
Subject: 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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd


On Thu, Nov 9, 2023 at 10:02 AM Ben Schwartz <bemasc=[e-mail]<mailto:[e-mail]>> 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<http://example.com/>".

tim



--Ben Schwartz
________________________________
From: DNSOP <[e-mail]<mailto:[e-mail]>> on behalf of Gianpaolo Angelo Scalone, Vodafone <Gianpaolo-Angelo.Scalone=[e-mail]<mailto:[e-mail]>>
Sent: Thursday, November 9, 2023 4:08 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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

_______________________________________________
DNSOP mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dnsop