On Fri, Oct 13, 2023 at 4:05 AM, tirumal reddy <[email protected]> wrote:
> On Thu, 12 Oct 2023 at 21:37, Tommy Pauly <[email protected]. > org> 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 > > <no-hat> Yes, I read that — but I still (personally) think that the risks outweigh the benefit. Knowing that a site is unreachable because it is "Extended DNS Error Code 17 - Filtered" seems helpful and safe. Having additional shiny pages saying "Vodafone Internet Services has protected you from 'Malware'. Hooray! Click here [https://www.vodafone.com/blockpage?list=malwarecc] for more info, and a cute upsell bundle 5G with your DNS Blocking needs" doesn't. Note that this is my personal view only — it's possible / likely that the WG consensus differs from mine. </no-hats> W > > >> 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
