On Tue, Oct 10, 2023 at 12:56 PM, Vodafone Gianpaolo Angelo Scalone <
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>
>
>
>
Erm, can't a large amount of this already be accomplished using RFC8914
Extended Errors. E.g:
https://www.rfc-editor.org/rfc/rfc8914.html#name-extended-dns-error-code-15-
—-
"4.16. Extended DNS Error Code 15 - Blocked
The server is unable to respond to the request because the domain is on a
blocklist due to an internal security policy imposed by the operator of the
server resolving or forwarding the query.
4.17. Extended DNS Error Code 16 - Censored
The server is unable to respond to the request because the domain is on a
blocklist due to an external requirement imposed by an entity other than
the operator of the server resolving or forwarding the query. Note that how
the imposed policy is applied is irrelevant (in-band DNS filtering, court
order, etc.).
4.18. Extended DNS Error Code 17 - Filtered
The server is unable to respond to the request because the domain is on a
blocklist as requested by the client. Functionally, this amounts to "you
requested that we filter domains like this one."
---
Yes, it doesn't give you the HTML page, but I personally view that as a
feature, not a bug.
You *know* that if my coffee-shop/hotel/car-dealer has the ability to
respond to every N-th DNS query with:
"({ "c": [https://subaru.example.com/buy-the-new-outback.html})" or "(({
"c": [https://www.example.com/free-donut-with-every-pumpkin-spice-latte.]})"
they will.
Yes, I shouldn't be trusting my coffee-shop/hotel/car-dealer's resolvers,
but with captive-portals and similar many people do…
W
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
