On Thu, 12 Oct 2023 at 21:37, Tommy Pauly <[email protected]> wrote:
> > > On Oct 11, 2023, at 3:17 PM, Warren Kumari <[email protected]> wrote: > > > > > > On Tue, Oct 10, 2023 at 12:56 PM, Vodafone Gianpaolo Angelo Scalone < > [email protected]> 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… > > > Yeah, the existing error codes are quite good (and iOS and macOS natively > support them now!), but having more details would allow this to replace > more fully the cases where redirection occurs. > > I also am concerned about someone just putting advertisements or worse in > the contact information, so there should be some control on it. > The above attack and possible mitigation is discussed in the security considerations section of the draft, please see the snip below: </snip> A client might choose to display the information in the "c", "j", and "o" fields if and only if the encrypted resolver has sufficient reputation, according to some local policy (e.g., user configuration, administrative configuration, or a built-in list of respectable resolvers). This limits the ability of a malicious encrypted resolver to cause harm. For example, an end user can use the details in the "c" field to contact an attacker to solve the problem of being unable to reach a domain. The attacker can mislead the end user to install malware or spyware to compromise the device security posture or mislead the end user to reveal personal data. If the client decides not to display all of the information in the EXTRA-TEXT field, it can be logged for diagnostics purpose and the client can only display the resolver hostname that blocked the domain, error description for the EDE code and the suberror description for the "s" field to the end-user. </snip> -Tiru > Tommy > > > W > > > > Thank you >> >> Gianpaolo >> >> C2 General >> >> _______________________________________________ >> DNSOP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dnsop >> > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop > > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
