[hrpc] DNS Privacy Vs. Re: Working group last call for draft-irtf-hrpc-guidelines

[Mallory Knodel <[e-mail]>]

Hi,

On 7/1/21 12:59 PM, Stephane Bortzmeyer wrote:
> On Mon, Jun 28, 2021 at 03:14:04PM -0400,
>   Mallory Knodel <[e-mail]> wrote
>   a message of 145 lines which said:
>
>> Here’s that text: https://github.com/mallory/DNS-Privacy.
> I'm not convinced. This paper has several weaknesses:
>
> * it speaks mostly about *one* deployement model of DoT/DoH, and
> criticize it, instead of promoting other models,

We definitely want to introduce more nuanced models in the next version.

What we can do is be explicit about what we are currently talking about, 
and not make a blanket statement. Criticism isn't exactly the point, 
it's more to acknowledge tensions and help non-technical people weigh 
the tradeoffs.

> * it is very close from the arguments of the Internet access providers
> (as presented in RFC 8404) "encryption is a problem for us",
The idea is to face the shortcomings head on (rather than to pretend 
they don't exist) and from a public interest perspective give an 
analysis that ultimately ends in: given all of this we still think that 
encryption and privacy are more important, overall.
> * with the very same arguments about research and monitoring, we could
> suppress all encryption. (The paper does not propose a criteria to
> separate things that have the right to be encrypted and the things
> that would have to stay in clear.
(same argument)
>   Calling DNS requests "metadata" is
> may be an attempt to have such a criteria. If so, it is a bad one.)
If you could just explain more what you mean here, I think you're 
raising an important point that we want to better consider in the text.
>> Making DNS lookup more private for the user affects internet
>> measurements, consolidates service provision
> No. There is zero relationship between "making DNS lookup more
> private" and "consolidates service provision". Big public DNS
> resolvers existed before DoT and DoH (I bet that the vast majority of
> requests to 8.8.8.8 and 1.1.1.1 are not over DoT/DoH). Saying that
> "Making DNS lookup more private for the user consolidates service
> provision" is like saying SMTP created Gmail.
We should say, "Recent efforts that have popularised private DNS 
lookup..." and there certainly is a relationship to consolidation, 
albeit not causation. We then use the fuller section to explain this 
more clearly, and resolve the tension as you point out.
>> Making DNS lookup more private for the user [...] risks internet
>> shutdown for some users
> This one really upset me. The responsability of Internet shutdowns is
> 100% on the side of the censors/governments/etc. Accusing the user who
> tried to improve his/her privacy is a bad idea. For every security
> measure, the other side will try to find a counter-measure and we
> don't accuse security measures of being responsible for the nasty
> effects of these counter-measures.

Censorship is upsetting. We're not accusing the user obviously. If 
anything it's really important to warn users of risks when they start 
using new tools because they are evading censorship or surveillance. 
Giving users a false sense of security is at the top of the 
what-not-to-do list.

The point is to speak to the audience of people who are building the 
circumvention tools and the people who support at-risk groups to adopt 
those tools. This audience needs to confront the fact that the censor is 
going to make a counter-move, and to be informed of any existing 
counter-measures and to expect, possibly even plan, more of them.

>> Needless to say, it is not in the public interest for internet
>> traffic to be consolidated on only a few network operators.
> And therefore the solution is to have many secure resolvers (in the
> same way that the solution to centralized social networks is to have
> many instances of a decentralized protocol), not to stop deploying
> DoT/DoH.
This is the exact point that we clearly make. While obvious to us, it's 
valuable to say it in a document written from a public interest 
perspective. It's called "taking a position".
>>   App developers on these platforms can now enable encrypted DNS for
>>   app-specific lookups even if the system resolver doesn’t use
>>   encrypted DNS or uses a different resolver.
> This has nothing to do with DoT or DoH. Applications were always able
> to have their own resolution.
Yes but if the user's mental model is that their lookups are private, 
they need to understand who is the intermediary from whom they are not 
private: the app. I've written about and taught digital security for 
at-risk users and it is fundamentally critical that the inherent trust 
relationships in tools be uncovered. What is written here is not 
attributing something new to DoT/DoH, it is describing what is possible.
>   Anyway, the solution is not to drop
> DoT/DoH (see my remark above about the fact that this paper seems to
> consider there is only one way to deploy DoT/DoH) but to have the OS
> resolver use DoT (Android now does it) or DoH (Windows 11 now does
> it).

The solution is to make DoT/DoH *ubiquitous*. I'm just baffled at how 
you could read a pretty mild analysis of implementation tradeoffs and 
assume the literal opposite intention of the paper.

Perhaps we're all just very used to unconditional and unexamined support 
of anything that says it's good for user privacy?

-Mallory

-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780