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
