On Mon, May 11, 2020 at 12:35:11PM -0700, Christian Huitema <[email protected]> wrote a message of 294 lines which said:
> The paragraph in section 5.1 seems to imply that embedding a > recursive resolver in the end point or close to reduces the privacy > attack surface: Note that it was already in RFC 7626 (which does not mean it was right). I agree with you that there is a weakness in the reasoning (a sniffer located between such a resolver and the rest of the Internet would see a lot since a one-user resolver may have little caching). I think the problem is that the RFC (in 7626-ter?) should better separate upstream surveillance (before the resolver), downstream surveillance (after the resolver) and internal surveillance (inside the resolver). Using a in-host resolver decreases upstream surveillance and suppresses internal surveillance, but does little for downstream surveillance (because of limited caching). Using a remote resolver with DoT or DoH to reach it may expose to internal surveillance (if the trust in this resolver is misplaced) but decreases upstream and downstream (because of caching) surveillance. > At a minimum, I would like to see a forward pointer to section 6.2 > in the recursive resolver on device paragraph. A general warning > that this is a trade-off would be nice too. I agree and I suggest "As it is often the case with privacy, there is a trade-off here. A local (to the user's machine or LAN) resolver reduces the risk that the resolver's administrator read the user's DNS traffic, but it does not protect a lot against later sniffing, done at the place where the resolver talks with authoritative name servers." > I found the discussion of application embedded resolvers bizarre. See <https://mailarchive.ietf.org/arch/msg/dns-privacy/ZATyqXQ6ccNHTqsMpbq__3a72WM> I know think that it is indeed on the wrong track. > In a modern environment, the concept of host is very fuzzy. We get all > kinds of special devices. We also get containers or virtual machines > running inside hosts. A browser is in practice such a container. I agree that OSvsApplication it should not be in this draft. > As for section 6.1.1.2, I would scratch most of it, I completely agree. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
