As another enthusiastic follower of this document, I appreciate the suggestions
from Gianpaolo here.
Looking at the document, in section 5.3, it does cover some of the suggestions,
particularly that the extra-text MUST be over encrypted DNS, and MUST NOT be
opportunistic.
Having a requirement that the contact needs to be related to / covered by the
resolver cert is interesting. I’d be curious to hear if this would generally
work for resolvers?
Thanks,
Tommy
> On Oct 10, 2023, at 9:56 AM, Gianpaolo Angelo Scalone, Vodafone
> <Gianpaolo-Angelo.Scalone=40vodafone....@dmarc.ietf.org> wrote:
>
>
> I really love this draft and would like to see browser side implementation
> for the benefit of customers user experience.
> Today several services are implemented on top of DNS to filter malicious or
> unwanted traffic in an effective way, but customers cannot distinguish the
> blocking from a network error.
> This led to frustration or even worst put them in danger: a quick solution to
> the "network error" is to disable the protection and so be infected, or
> change browser.
> The server side implementation provides all the needed information to build a
> great user experience: in the example below I see at least 2 options
>
> ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24987
> flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 OPT
> PSEUDOSECTION:
> EDNS: version: 0, flags:; udp: 512
> EDE: 17 (Filtered): ({ "c":
> [https://blocking.vodafone.com/blockpage?list=malwarecc], "s": 1,"j":
> "Malware C&C", "o": "Vodafone Internet Services" }) QUESTION SECTION:
> malw.scalone.eu. IN A
>
> Option 1 - better user experience, some complexity to avoid security risks
>
> if the contact URI is trusted it is possible to present in the GUI a real
> blocking page.
> The problem is that untrusted providers could use this method as an attack
> vector.
> Potential solutions could be:
> Browsers accept Exte4nded DNS Errors only from DoH servers.
> URI domain has to be covered by DoH server certificate.
> There could potentially be a vetting process e.g. through IANA, whereby
> filtering providers would need to register. Only registered and approved
> providers would then be permitted to use this method
>
> Option 2 - Sub-optimal user experience; however, a significant improvement
> over today's user experience.
>
> <Browser name> cannot open <filtered domain, not clickable> because it has
> been filtered by <name of the filtering service, "organization" field>
> Blocking reason: <blocking reason, " justification" field>
>
> Thank you
>
> 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
