Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

From: Vittorio Bertola <[email-masked]>
Date: Mon, 2 Dec 2019 13:03:49 +0100 (CET)

Il 29 novembre 2019 01:40 Kenji Baheux <kenjibaheux=[email-masked]> ha scritto:

On Thu, Nov 28, 2019 at 8:05 PM Konda, Tirumaleswar Reddy <
[email-masked]> wrote:

In addition, with the extended error codes defined in https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-08, 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.

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.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: "Winfield, Alister" <[email-masked]>
Date: Mon, 2 Dec 2019 14:20:16 +0000

On Thu, Nov 28, 2019 at 8:05 PM Konda, Tirumaleswar Reddy < [email-masked]<mailto:[email-masked]>> 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.

Vittorio Bertola [email-masked]<mailto:[email-masked]> 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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Dec 2019 14:59:06 -0500

This business of proxy chains. It seems like it is insoluble. We faced the
same problem when we were trying to deal with spam. There is a huge amount
of complexity there. I have been thinking about this problem for the past
week and I think I have come up with the answer:

None of it matters.

To explain, if Alice decides to use DavesDNS.resolv as her resolution
service, that is the end of the matter as far as Alice is concerned. There
are two possible types of service Dave might provide:

1) Untrusted: Dave returns full DNSSEC paths for all his answers, Alice
checks them. In this case, the source of the data Dave supplies is
irrelevant as the source of trust is whatever DNSSEC apex is used for
validation.

2) Trusted: Dave returns unsigned records and Alice must trust that Dave
obtained the records, processed them etc. in accordance with the agreement
between Alice and Dave.

The point is that Alice ONLY has a relationship here with Dave. How Dave
obtains the records is irrelevant. They can be sent by carrier pigeon for
all it matters. The internals of how Alice obtains the information is
'black box'.

Within any relay structure, there is always a controller who decides which
will be the next relay in turn and unless there is a successful MITM attack
(in which case we should want to force the connection to ABORT) the control
is always with either the sender or the receiver

As far as the Internet protocol is concerned, there is always exactly one
hop, the point where the client side hands control over to the service
side. And this is always the hop that crosses the narrow waist.