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

[Tim Wicinski <[e-mail]>]

Thanks both of you - I knew I was missing this when I hit send.

tim


On Thu, Nov 9, 2023 at 11:20 AM Gianpaolo Angelo Scalone, Vodafone <
[e-mail]> wrote:

> 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]> 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 <[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
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>