Il 29 novembre 2019 01:40 Kenji Baheux <[email protected]> ha scritto:
On Thu, Nov 28, 2019 at 8:05 PM Konda, Tirumaleswar Reddy < [email protected]<mailto:[email protected]>> wrote: In addition, with the extended error codes defined in https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-08<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-dnsop-extended-error-08&data=02%7C01%7Calister.winfield%40sky.uk%7C8f6d20de304945e0a42908d7771fbaa3%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C637108850474743243&sdata=ZtDtO9aoPpax5pCIAN0dpZgEJx2dNyZwv%2F1NQzWu5lw%3D&reserved=0>, client would know the reason for blocking access to a domain, solves the user experience problem and, DoT/DoH ensures the error response is not spoofed. Spot on. A big part of the problem is that the DNS modifications for legit use cases or legal reasons are done in a non-transparent way, with potential security/privacy side-effects (e.g. application left in the dark, forced custom page), and without strong guarantees that this was indeed the original intent. That said, I understand the need for ISP or service operators to explain what happened to the user and how to act on it (e.g. request whitelisting in a parental control situation). So, I'd love to hear feedback from ISPs in particular, on the extended DNS error draft in conjunction with DoH. An alternative would be to use/repurpose HTTP status code such as 451 or 450 in DoH, and also define something for the explanation needs. Vittorio Bertola [email protected]<mailto:[email protected]> wrote: I was the one that asked for the addition to the draft of a specific error code for "filtered per user request", because I wholeheartedly share the view that the UX of current DNS filtering platforms, especially when applied to HTTPS destinations, is terrible and lacks the transparency, security and information necessary to reassure the user that this is indeed what was intended to happen and explain why. It would be great if we could find reliable ways to redirect the user to an explanation/configuration page without the need to circumvent or forge the HTTPS connection, while authenticating the origin of the DNS modification and of the message, and as a DNS vendor we would be happy to cooperate on that. I like the idea given the less than ideal methods required right now to give any feedback to the user. Quite happy to see something like this. Alister Winfield Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
