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 < gianpaolo-angelo.scal...@vodafone.com> 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=40meta....@dmarc.ietf.org> > *Inviato:* Giovedì, Novembre 9, 2023 5:14:26 PM > *A:* Tim Wicinski <tjw.i...@gmail.com>; Ben Schwartz <bem...@meta.com> > *Cc:* Gianpaolo Angelo Scalone, Vodafone < > gianpaolo-angelo.scal...@vodafone.com>; dnsop@ietf.org <dnsop@ietf.org> > *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 <dnsop-boun...@ietf.org> on behalf of Tim Wicinski < > tjw.i...@gmail.com> > *Sent:* Thursday, November 9, 2023 10:48 AM > *To:* Ben Schwartz <bemasc=40meta....@dmarc.ietf.org> > *Cc:* Gianpaolo Angelo Scalone, Vodafone <Gianpaolo-Angelo.Scalone= > 40vodafone....@dmarc.ietf.org>; dnsop@ietf.org <dnsop@ietf.org> > *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= > 40meta....@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-boun...@ietf.org> on behalf of Gianpaolo Angelo > Scalone, Vodafone <Gianpaolo-Angelo.Scalone=40vodafone....@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 > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
