Subject: Re: [hrpc] Working group last call for draft-irtf-hrpc-guidelines

From: farzaneh badii <[email-masked]>
Date: Thu, 1 Jul 2021 09:12:50 -0400

Mallory,

I have now gotten to read your paper. It sets the scene for a discussion
but there are some very generalized and broad hypotheses in the paper that
have not been supported and there are many disagreements over them.  The
trade-off between privacy and security of the DNS users is unclear and
needs much more in-depth research, especially when we relate it to
public interest. Moreover, the trade off you are mentioning in the paper is
itself an argument for both centralized and decentralized systems (there is
an actual research group about  decentralized infrastructure, I don't know
how useful it is:  https://datatracker.ietf.org/rg/dinrg/about/). Also
decentralized as explained in the document is very vague. Decentralization
of what aspects of the infrastructure, used by whom etc? It is surprising
but the Web itself technically has a very centralized governance.  I can't
suggest a change because the text asserts the arguments with too much
conviction but we should identify these issues as areas of research.

Farzaneh

On Mon, Jun 28, 2021 at 3:14 PM Mallory Knodel <[email-masked]> wrote:

>
>
> On Monday, June 28, 2021, Gurshabad Grover <[email-masked]>
> wrote:
>
>>
>> > Section 2.3.13
>> >
>> > I don't know that we have *any* real success stories for
>> > decentralization.  HTTP certainly isn't one.  Certainly designing
>> > *toward* centralization might be best, but I don't think we have very
>> > many examples of that *either.*  Moreover, I have argued, and continue
>> > to argue, that some centralization may *facilitate* human rights.  If
>> > you take into account the combination of DOH + cloud, an observer must
>> > go to far greater lengths to discern even so much as the nature of the
>> > traffic, much less content and actual endpoint.
>> >
>> > And this raises another issue: the point of much of cloud services is to
>> > improve individual service reliability.  And yet those same cloud
>> > services are a form of centralization.  If you consider that perhaps a
>> > handful of players might force DNS traffic to a limited number of
>> > resolver services, we might also say that DoH itself presents
>> > centralization risks.
>> >
>> > These sorts of conflicts are of course to be expected.  The question is
>> > whether it is worth providing guidance relating to centralization.  I
>> > will claim that nobody yet has a real handle in this area, and so better
>> > to say nothing in the form of guidance.  Instead, it seems to me to be
>> > good fodder for future work.
>> >
>>
>> I don't think I have a strong opinion about this. Before making any
>> changes in this section, however, I'd love to hear what others think.
>>
>
> I do think that while centralisation can be leveraged for good that it’s
> well established that an interoperable, resilient decentralised internet
> architecture is ideal for the public interest. So there may be trade offs.
> I would point to the section on consolidation in the paper Shivan and I
> wrote on DNS Privacy Vs (the public interest).
>
> It’s important to keep in mind the tensions so that we aren’t dogmatically
> accepting either scenario.
>
> Here’s that text: https://github.com/mallory/DNS-Privacy.
>
> Great work getting this new version out!
>
> -M
>
>
>
> --
> Mallory Knodel
> CTO, Center for Democracy and Technology
> gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
>
>
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 1 Jul 2021 15:53:30 +0200

Hi Gurshabad,

Thanks for your responses.  Please see below.

>> For "Impacts"-
>>
>> These impacts are claimed, both here and in 8280, but the linkage isn't
>> explicitly made in each case.  Are these linkages made clear somewhere
>> else?  I may have entirely missed it, in which case this issue isn't an
>> issue at all.  Otherwise, one wonders if we are putting the cart before
>> the horse.
>>
> I think the explanation and examples under each each sub-section of 2.3
> are intended to make these links explicit. Are you referring to some
> other sort of links between rights and properties of protocols/specs?

In reviewing Section 2.3, I think my confusion comes from the examples.  
Let's consider Section 2.3.1:

The key point in the section is probably this sentence:

>  However,
>    protocols relying on middleboxes can create potential for abuse, and
>    intentional and unintentional censoring, thereby influencing
>    individuals' ability to communicate online freely and privately.

A good example for middleboxes is actually Email, not NATs or firewalls, 
because the tradeoffs for email are most plain.  Email provides a point 
of rendezvous to enable scaling.  Furthermore, having email servers, as 
opposed to directly delivering to end devices, has additional security 
benefits to reduce spamming, phishing, and malware attacks.  But those 
same middleboxes that scan for bad behaviors could scan for politically 
sensitive content, and thus infringe on people's rights, because we have 
yet to find ways to properly scale end-to-end encryption to the billions 
of people.

There isn't that much of a tradeoff for NATs these days- nobody likes 
them architecturally, but I think people would be hard pressed to 
demonstrate harm to human rights.  Moreover, NATs are designed to be 
transparent to most – but not all – protocol transactions.  and so there 
isn't much of a tradeoff, and this makes people scratch their heads when 
relating a NAT to "Right to freedom of assembly and association".

In fact, arguably this section should probably focus on applications and 
social network sites, where this tussle has played out in far more 
dramatics style over the last several years.  Consider the tradeoffs of 
a wildly popular IM application, which makes great use of middleboxes 
(there isn't really an IM system that doesn't).

> As I understand it, we are not proposing an ideal workflow as such. We
> are just listing out some assessment frameworks (which may be used
> independently or in conjunction with each other).

Up to you.

>
>> A few of the examples seem to me a bit disjoint from the IETF.  I think
>> we talked about Accessibility at some point, but an example more
>> relevant to the IETF might help people grasp the more direct relevance
>> to the organization.  I don't have a particularly good example of this,
>> but there should at least be an existence proof of the relevance to
>> us... unless...
>>
>> ... you want the guidance to be broader than just the IETF.  I see
>> absolutely nothing wrong with that, but you should scrub the doc then to
>> make sure that IETF-specific stuff is generalized.  An example might be
>> to replace "protocol" with "specification".
>>
> I don't think we're saying this explicitly anywhere, but that's
> deliberate. Since IETF is not the only place where protocols are made, I
> think that this vagueness is acceptable. Of course, one of the primary
> goals for the document remains that it is usable by people at IETF.
>
> That said, I think we were at consensus that the guidelines are not just
> relevant to protocols, but specifications (an example at IETF would be
> specifications that lay out an architecture but not a protocol) in the
> broad area of networking. For instance, I think the group has used the
> guidelines to review the MLS architecture and SUIT architecture. Made
> some changes to say 'specification' instead of protocol where relevant.

Well... as it happens I just laid out two examples for you above ;-)  
Use them if you like.

> changes in this section, however, I'd love to hear what others think.

Ok.

>
>> 2.3.17 Authenticity
>>
>> The authors write:
>>
>>>     At the same time, authentication should not be used as a way to
>>>     prevent heterogeneity support, as is often done for vendor lock-in or
>>>     digital rights management.
>> As if that should be the #1 concern.  Perhaps a bigger concern is that
>> authenticity directly conflicts with anonymity or pseudo-anonymity.  If
>> someone is forcing you to authenticate, the authentication identity can
>> and will be associated with whatever access takes place, and that
>> information can be demanded.
>>
>> Furthermore,  I'm not at all sure that the example holds up, and it
>> should be at least supported by a current reference.  Finally, there are
>> conflicts here as well: the technology that one might use for vendor
>> lock-in is  the same as that used to validate the authenticity of
>> software, for purposes of preventing malware spread.
>>
>> Also, the question itself is a bit shallow.  Authenticity of what?  If
>> we are talking about the underlying data, a mere transport connection
>> may not in and of itself provide sufficient protection.  We have plenty
>> of mail traversing encrypted tunnels and lots of spam to go with.
>>
> I agree that identity authentication can be at odds with
> anonymity/pseudonymity, but this section is not about that. I re-read
> the text and example in this section, and to me it's clear that it's
> more to do with transport/data authenticity than identity
> authentication. Would love to hear your thoughts on how we can make this
> even clearer if it's cause for confusion.

At the high level, it is that very conflict of identity authentication 
which itself provides for data authenticity (that's how Bob knows that 
it was Alice who sent the message) versus anonimity/pseudonymity (that's 
how others might know that it was Alice who sent that message) that has 
to be laid out.  The work of TLS 1.3 in particular was all about *not* 
revealing Alice's identity unless the other end is authorized to see it. 
That's probably worth capturing a bit better.  This is probably where I 
would focus the section.  It's not an easy topic, because peer to peer 
communications (as opposed to client->server) require that someone has 
to reveal something to get things going, at least using the currently 
scaled technology.

Also, the DRM discussion really is just a bit facile, and has to take 
into account the very real possibility that in some cases, the end user 
is considered the adversary.  Absent this model, services like Netflix 
could not exist, for instance.  Perhaps that's not a HR issue, but 
vendor lock-in is such a complicated issue that attempting to address it 
with a few throwaway lines isn't giving it appropriate consideration.

>
>> *Minor issues:*
>>
>> Beginning with Section 1:
>>
>>>    This is by no means an attempt to exclude specific rights or
>>>     prioritize some rights over others.  If other rights seem relevant,
>>>     please contact the authors.
>> Are we are sufficiently taking into account how linkages to other rights
>> might prevail?  Let me give an example:
>>
>> If we are talking about a new version of "whois" that retrieves
>> information necessary for law enforcement, the whole point of the
>> protocol is to expose information that some would say is private.  And
>> so the question revolves around whether appropriate protections are in
>> place to limit access to that information to authorized parties.
>> However, even doing that may not be enough, if "authorized parties" are
>> the source of abuse.  I don't know if such an example is an outlier, but
>> there it is.
>>
>> Nit: the 2nd sentence will need to be changed or removed.
> Removed the second sentence.
>
> Could you please elaborate on what you mean to demonstrate through the
> example here (with respect to linkages of rights)?

I attempted, apparently unsuccessfully, to do that with whois. This is a 
tradeoff, and perhaps better documented by ICANN than I could 
elaborate.  They've had an ongoing To Do with the EC and the GDPR, and 
they are in a far better position to explain it.

Regards,

Eliot

---

From: Mallory Knodel <[email-masked]>
Date: Thu, 1 Jul 2021 11:39:03 -0400

Hi Farzaneh,

> I have now gotten to read your paper. It sets the scene for a discussion
Yes, that's actually the only goal of the paper.
> but there are some very generalized and broad hypotheses in the paper 
> that have not been supported and there are many disagreements over 
> them.  The trade-off between privacy and security of the DNS users is 
> unclear and needs much more in-depth research, especially when we 
> relate it to public interest.
We hope that the paper sparks lots and lots of additional research.
> Moreover, the trade off you are mentioning in the paper is itself an 
> argument for both centralized and decentralized systems
Indeed, it is pointing this out and hopefully helping advocates 
recognise this confusion situation-- that centralisation can be 
leveraged for good, but ultimately the tradeoff of the effects of 
long-term centralised markets/internet/etc is probably bad.
> (there is an actual research group about  decentralized 
> infrastructure, I don't know how useful it is: 
> https://datatracker.ietf.org/rg/dinrg/about/)
This is a related use of the word "decentralised" but it is not the 
same. DINRG is concerned with "distributed ledger technologies", eg 
blockchain. It's not what we're talking about.
> Also decentralized as explained in the document is very vague. 
> Decentralization of what aspects of the infrastructure, used by whom etc?
As an architecture and a market.
> It is surprising but the Web itself technically has a very centralized 
> governance.  I can't suggest a change because the text asserts the 
> arguments with too much conviction but we should identify these issues 
> as areas of research.

Glad we're exactly on the same page!

Thanks so much for the review,

-Mallory

>     On Monday, June 28, 2021, Gurshabad Grover
>     <[email-masked]> wrote:
>
>
>         > Section 2.3.13
>         >
>     I do think that while centralisation can be leveraged for good
>     that it’s well established that an interoperable, resilient
>     decentralised internet architecture is ideal for the public
>     interest. So there may be trade offs. I would point to the section
>     on consolidation in the paper Shivan and I wrote on DNS Privacy Vs
>     (the public interest).
>
>     It’s important to keep in mind the tensions so that we aren’t
>     dogmatically accepting either scenario.
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 1 Jul 2021 18:59:34 +0200

On Mon, Jun 28, 2021 at 03:14:04PM -0400,
 Mallory Knodel <[email-masked]> wrote 

> 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,
* it is very close from the arguments of the Internet access providers
(as presented in RFC 8404) "encryption is a problem for us",
* 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. Calling DNS requests "metadata" is
may be an attempt to have such a criteria. If so, it is a bad one.)

> 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.

> 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.

> 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.

>  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. 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).

---

From: Eliot Lear <[email-masked]>
Date: Thu, 1 Jul 2021 19:29:48 +0200

Hi Stephane,

The fundamental issue here is as much control as it is privacy. If a 
device is making use of DoH to get to places others don't want that 
device to get to, that is problematic from one point of view and 
beneficial from another.  Surely there is a tussle between This end 
device, the user and his or her rights, and OTHER end devices and their 
users and their rights.  If This user wants to make use of privacy 
technology but his or her hardware is hacked, and then makes use of it, 
then that poses a problem for the others, and it's by definition an 
externality.  The blocking technology to address that sort of use would 
have quite a wide footprint, indeed, potentially leading to a 
permission-based, rather than permissionless network.

Be careful what you ask for.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 1 Jul 2021 19:19:02 +0100

Hiya,

On 01/07/2021 18:29, Eliot Lear wrote:
> Surely there is a tussle between This end device, the user and his or 
> her rights, and OTHER end devices and their users and their rights.

I don't think that's "sure."

In at least some cases the tussle seems to be between users
aiming for better privacy and companies that want to not
increase their costs by having to make changes, or wanting
to preserve existing revenue streams. That's also a pattern
we've seen before as new deployments using confidentiality
services become more widespread.

S.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 1 Jul 2021 20:22:56 +0200

> I don't think that's "sure."

Surely there is.  But it's not the only tussle.  There are also 
governments acting outside their citizens' interests.  I'm a little 
surprised you didn't go for that one first ;-)

Eliot

---

From: Mallory Knodel <[email-masked]>
Date: Fri, 2 Jul 2021 07:58:58 -0400

Hi,

> 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.

> (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.
> that would have to stay in clear.
(same argument)
>   Calling DNS requests "metadata" is
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.
> 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.
> 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.

> many instances of a decentralized protocol), not to stop deploying
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".
> 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

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

---

From: Mallory Knodel <[email-masked]>
Date: Fri, 9 Jul 2021 07:14:07 -0400

Hi all,

Thanks so much for the reviews that came in last call.

After talking with Gurshabad, I am going to move this draft toward 
publication. Most suggestions below are about including examples, so 
keeping in tact some of that remaining discussion open for other 
reviews, such as in the IRSG, will be part of the detail that I pass on.

Thanks all,

-Mallory

On 7/1/21 9:53 AM, Eliot Lear wrote:
> In reviewing Section 2.3, I think my confusion comes from the 
> examples.  Let's consider Section 2.3.1:
>
> A good example for middleboxes is actually Email, not NATs or 
> firewalls, because the tradeoffs for email are most plain. Email 
> provides a point of rendezvous to enable scaling. Furthermore, having 
> email servers, as opposed to directly delivering to end devices, has 
> additional security benefits to reduce spamming, phishing, and malware 
> attacks.  But those same middleboxes that scan for bad behaviors could 
> scan for politically sensitive content, and thus infringe on people's 
> rights, because we have yet to find ways to properly scale end-to-end 
> encryption to the billions of people.
>
> transparent to most – but not all – protocol transactions.  and so 
> there isn't much of a tradeoff, and this makes people scratch their 
> heads when relating a NAT to "Right to freedom of assembly and 
> association".
>
> In fact, arguably this section should probably focus on applications 
> and social network sites, where this tussle has played out in far more 
> dramatics style over the last several years.  Consider the tradeoffs 
> of a wildly popular IM application, which makes great use of 
> middleboxes (there isn't really an IM system that doesn't).
>
> it was Alice who sent the message) versus anonimity/pseudonymity 
> (that's how others might know that it was Alice who sent that message) 
> that has to be laid out. The work of TLS 1.3 in particular was all 
> about *not* revealing Alice's identity unless the other end is 
> authorized to see it. That's probably worth capturing a bit better.  
> This is probably where I would focus the section.  It's not an easy 
> topic, because peer to peer communications (as opposed to 
> client->server) require that someone has to reveal something to get 
> things going, at least using the currently scaled technology.
>
> into account the very real possibility that in some cases, the end 
> user is considered the adversary.  Absent this model, services like 
> Netflix could not exist, for instance. Perhaps that's not a HR issue, 
> but vendor lock-in is such a complicated issue that attempting to 
> address it with a few throwaway lines isn't giving it appropriate 
> consideration.
>
>
>>> *Minor issues:*
>>>
> I attempted, apparently unsuccessfully, to do that with whois. This is 
> a tradeoff, and perhaps better documented by ICANN than I could