Subject: Re: [arch-d] IAB statement on "Avoiding Unintended Harm to Internet Infrastructure"

From: Andrew Campling <[email-masked]>
Date: Wed, 13 Nov 2019 06:53:55 +0000

Vittorio Bertola <[email-masked]<mailto:[email-masked]>> wrote on Mon, 09 September 2019 15:26

      In the DNS section, it is disheartening to read the IAB stating that "[a DNS resolver] returning the wrong (or no) address breaks the trust that users have in this infrastructure", after having spent months on the ADD list and elsewhere to explain that there are indeed lots of use cases in which users expect, or even actively request, that their resolver applies filters to the responses. In some cases it is actually the opposite - if I acquire a DNS-based service to prevent any accidental connection to malware-infected websites and then I get malware, that's when I lose trust in my DNS resolver; same for parental controls.

I believe that the broad assertion that "all DNS filtering is wrong" suggests a lack of understanding in the way that many users and entities use DNS as a control surface in a variety of contexts.  There are large classes of users that would disagree with the insistence that a DNS resolver must return the correct address in every case.

      More generally, the entire document sounds like a claim that the Internet's infrastructure and those who run it need to be exempt from cooperation with law enforcement activities, and totally unregulated.

In my view it is unrealistic to expect that governments and regulators will be content to allow the Internet's infrastructure and those who run to be exempt from cooperation with law enforcement activities, and totally unregulated.  Indeed the many privacy, antitrust and other issues that have surfaced relating to the tech sector over the last several years have led to an environment where an increase in oversight is both pretty much guaranteed and necessary.

      in the recommendations, it then mentions "endpoint-focused interventions" only to suggest that those who are subject to them should be listed explicitly in the regulation (which, by the way, is not how a law can work).

I agree that, in most if not all cases, it would neither be practical nor desirable to explicitly list all of the organisations that are subject to a specific intervention.  At best it might be possible to list categories of organisations in some cases, however even then the evolution of markets and technology may bring different categories within scope over time.

      Similarly, the section titled "Impact on Internet evolution" seems to argue against regulation of the Internet, but in the final section there is no recommendation against regulation, just a request to involve all stakeholders when discussing it.

As above, in my view it is unrealistic to expect that governments and regulators will be content to exempt the internet from regulation.  As also stated above, the many privacy, antitrust and other issues that have surfaced relating to the tech sector over the last several years have led to an environment where an increase in regulation is both pretty much guaranteed and necessary.

      It would be nice if we could understand better what is the objective that the IAB wants to achieve with this statement and what does it actually recommend, before commenting further.

I agree that it would be useful to see some clarification regarding both the objective behind the statement and the recommendation itself.

Andrew

---

From: Paul Ebersman <[email-masked]>
Date: Wed, 13 Nov 2019 15:29:29 -0700

acampling> In the DNS section, it is disheartening to read the IAB
acampling> stating that "[a DNS resolver] returning the wrong (or no)
acampling> address breaks the trust that users have in this
acampling> infrastructure", after having spent months on the ADD list
acampling> and elsewhere to explain that there are indeed lots of use
acampling> cases in which users expect, or even actively request, that
acampling> their resolver applies filters to the responses. In some
acampling> cases it is actually the opposite - if I acquire a DNS-based
acampling> service to prevent any accidental connection to
acampling> malware-infected websites and then I get malware, that's when
acampling> I lose trust in my DNS resolver; same for parental controls.

acampling> I believe that the broad assertion that ``all DNS filtering
acampling> is wrong'' suggests a lack of understanding in the way that
acampling> many users and entities use DNS as a control surface in a
acampling> variety of contexts.  There are large classes of users that
acampling> would disagree with the insistence that a DNS resolver must
acampling> return the correct address in every case.

Yes. A recent post from Hugh Dixon in the ADD list quotes RFC 7258:

   "Pervasive Monitoring (PM) is widespread (and often covert)
   surveillance through intrusive gathering of protocol artefacts,
   including application content, or protocol metadata such as headers."

   "While PM is an attack, other forms of monitoring that might fit the
   definition of PM can be beneficial and not part of any attack, e.g.,
   network management functions monitor packets or flows and anti-spam
   mechanisms need to see mail message content"

He points out that sometimes monitoring is not an attack.

My take from RFC 7258 is that the key differentiator is user knowledge
and/or consent, i.e. if the user is not aware they are being monitored
and/or has not consented explicitly to altered data (in this case DNS
answers), that is what RFC 7258 considers an attack.

In the use case of DNS filtering, if the user is both aware of the
alteration of DNS answers (and why/how they might be altered) and has
consented via opt-in, that is a *service*, not an attack.

While there is not consensus in ADD/ABCD on the long term effectiveness
of DNS filtering as a control plane to enhance security, it is currently
a wide spread technique that much of the internet uses and finds value
with.

As Andrew said, we and the IAB should not be making blanket statements
that "all DNS filtering is wrong" as that doesn't correctly reflect all
of our stakeholders, considering the use case of user approved
filtering.

acampling> In my view it is unrealistic to expect that governments and
acampling> regulators will be content to allow the Internet's
acampling> infrastructure and those who run to be exempt from
acampling> cooperation with law enforcement activities, and totally
acampling> unregulated.  Indeed the many privacy, antitrust and other
acampling> issues that have surfaced relating to the tech sector over
acampling> the last several years have led to an environment where an
acampling> increase in oversight is both pretty much guaranteed and
acampling> necessary.

Agreed. Recent government panels in the UK and Australia on DoH and
concerns that this will break DNS filtering, even in cases where the
users wish to have it, shows that governments and law enforcement will
push back on technical standards. This is particularly likely if we
don't include them as stakeholders in discussions and help them
understand what these protocols do (and don't do).

This doesn't mean I'd advocate for government approval of IETF documents
but avoiding misunderstandings we can predict in advance does make it
less likely we'll be saddled with excessive and possibly ineffective
regulation.

acampling> It would be nice if we could understand better what is the
acampling> objective that the IAB wants to achieve with this statement
acampling> and what does it actually recommend, before commenting
acampling> further.

Agreed and something I'd love to see discussed next week. This is touchy
stuff and face to face discussions seem useful.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 14 Nov 2019 10:37:24 +1100

> consented via opt-in, that is a *service*, not an attack.

7258 doesn't say anything about consent or "user knowledge," so I don't know how you took that away from the document.

Putting that aside, assuming that consent (or its oft-relied upon variant, "informed consent") is adequate to protect users relies on users' ability to understand how the Internet works, how their data will be used, how it could be misused, how changes in policy, law, or entity ownership might affect its handling, the nature of any security vulnerabilities introduced by third parties involvement in their communication. If the consent is long-lived (as it would be with DNS), they have to remember it over that period of time, for each interaction. They also have to intersect this consent with others that they give -- often leading to "consent fatigue" (see: GDPR cookie notices and privacy policy changes).

That doesn't mean that we should never allow a user to make a choice, but we need to think carefully about the systemic effects of the points where we allow such a choice; there is ample evidence that most users _don't_ understand the choice they're making, and can be led into pretty hazardous situations as a result.

Right now, unencrypted DNS via DHCP doesn't give users a choice at all; they use the DNS results returned by their network, without any consent (beyond using the network -- which in most peoples' minds is "the Internet."). They can, however, choose to use a different DNS server by configuring it, or they can choose to configure an encrypted DNS server. 

The sticking point here is that DoH allows someone to avoid their network making that choice for them (with a lot of fuzziness about how consent is obtained). There are user-centred arguments as to why it's necessary to impose that policy at the network level (eg., lack of interfaces to configure IoT devices), but let's not start from the assumption that the best place to interpose those services is by having the network transparently handle them, just because that's how it's been done before. Let's also not assume that obtaining consent explicitly from the user to interpose those services is easy or without risks of various sorts; we have lots of examples where allowing random devices on networks to ask permission to do things ended up badly.

> of our stakeholders, considering the use case of user approved

That is not a quote from the document. In context, the statement is cautioning that legislation or regulation that requires DNS servers to give false answers could have systemic effects on trust.

> push back on technical standards.

Australian here; could you point me to the event you're talking about? Because I see no evidence yet that the Australian government will "push back" on DoH. There are some people who are trying to stir up a controversy around it, and a lot of misinformation flying about, but nothing from the government itself, AFAICT.

> This is particularly likely if we

I agree that we need to do better in working with the various parts of the Internet community, including governments. I'd be loathe to give them any special status, though, as that would fundamentally change the nature of the IETF, and the Internet.

Chers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Nov 2019 23:43:44 +0000

I'm feeling confused as I responded to exactly this para
on another list (add) that was explicitly setup to avoid
discussion related to DNS privacy and co being spread over
multiple lists, so can we please use one list and not
have the same discussion in two places?

> answers), that is what RFC 7258 considers an attack.

My response on the add list is at [1].

S.

[1] https://mailarchive.ietf.org/arch/msg/add/K8D7lVcDd8uheDVoo6wnMjtrZ9g

---

From: Paul Ebersman <[email-masked]>
Date: Wed, 13 Nov 2019 16:47:36 -0700

+1

DoH was invoked here but without the benefit of a bunch of discussion
already on ADD. Would love to see anything DNS/DoH related moved back
there until we have some consensus.

Stephen. Sorry. Saw this here first and responded. Should have done
redirect then.

sfarrell> I'm Feeling Confused As I Responded To Exactly This Para On
sfarrell> Another List (Add) That Was Explicitly Setup To Avoid
sfarrell> Discussion Related To Dns Privacy And Co Being Spread Over
sfarrell> Multiple Lists, So Can We Please Use One List And Not Have The
sfarrell> Same Discussion In Two Places?
 
stephen.farrell> My response on the add list is at [1].

stephen.farrell> [1] https://mailarchive.ietf.org/arch/msg/add/K8D7lVcDd8uheDVoo6wnMjtrZ9g

---

From: Brian Trammell (IETF) <[email-masked]>
Date: Sun, 17 Nov 2019 11:00:26 +0800

Hi Mark, all,

Quoting below for emphasis.

> On 14 Nov 2019, at 00:37, Mark Nottingham <[email-masked]> wrote:
> 
> There are user-centred arguments as to why it's necessary to impose that policy at the network level (eg., lack of interfaces to configure IoT devices), but let's not start from the assumption that the best place to interpose those services is by having the network transparently handle them, just because that's how it's been done before.

This, a few hundred times.

We've tried transparent network functions of various forms; for the most part, they either work while irretrievably changing the architecture (e.g. NAT have moved the network/transport layer header boundary to include the transport port numbers), or they tend only to work in a restricted set of environments (which may or may not be the environments the functions are sold to work in, but that's a different rant).

> Let's also not assume that obtaining consent explicitly from the user to interpose those services is easy or without risks of various sorts; we have lots of examples where allowing random devices on networks to ask permission to do things ended up badly.

In a cleaner architectural environment, we could move some of these functions to the endpoints (e.g., replacing in-network TCP enhancement with, well, better TCP stacks, which is largely what has happened in server and end-user platforms space over the past couple of decades), and transmute the rest into network functions deployed transparently, where the function's presence is explicit, and ideally exposed to the endpoint in such a way that the endpoint can negotiate with it.

Of course, as you say, the gap between transparency to the network/transport endpoint and informed user consent is a large one. But it'd be nice if we could work on solving that problem, as opposed to pretending that the accidental situation we find ourselves in with a network cluttered with functions that try and fail to be transparent is somehow essential to the Internet architecture, and argue about how best to maintain that situation.

It's also not lost on me that "user consent" is a slippery beast for functions (lawful intercept) where asking for consent is antithetical to the function at hand. In these situations, consent is given by a third party, generally someone from the judiciary in common law jurisdictions. But control over who gives consent is key to how the function is used and misused even in the most pervasive cases.

What the IAB is trying to do with this statement (IMHO) is to try to separate these threads. The way most of these functions are built tends to break things that are well outside the scope of the desired function, without an analysis of the tradeoffs involved. Without discussion of these tradeoffs, an informed discussion of the pros and cons of any given in-network function is not really possible. Hence "avoiding *unintended* harm".

Cheers,

Brian

---

From: S Moonesamy <[email-masked]>
Date: Sun, 17 Nov 2019 02:48:19 -0800

Hello,
At 10:53 PM 12-11-2019, Andrew Campling wrote:
>In the DNS section, it is disheartening to read the IAB stating that 
>"[a DNS resolver] returning the wrong (or no) address breaks the 
>trust that users have in this infrastructure", after having spent 
>months on the ADD list and elsewhere to explain that there are 
>indeed lots of use cases in which users expect, or even actively 
>request, that their resolver applies filters to the responses. In 
>some cases it is actually the opposite - if I acquire a DNS-based 
>service to prevent any accidental connection to malware-infected 
>websites and then I get malware, that's when I lose trust in my DNS 
>resolver; same for parental controls.

The position, in the past, was that it was important to preserve the 
chain of trust instead of allowing someone along the path to change 
the information published in DNS.  There are use cases where the 
changes are done for valid reasons, e.g. the user does not wish to 
download malware.  What are the unintended consequences of supporting 
such cases?

Regards,
S, Moonesamy

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 18 Nov 2019 13:57:43 +0800

> On 17 Nov 2019, at 18:48, S Moonesamy <[email-masked]> wrote:
> 
> Hello,
> The position, in the past, was that it was important to preserve the chain of trust instead of allowing someone along the path to change the information published in DNS.  There are use cases where the changes are done for valid reasons, e.g. the user does not wish to download malware.  What are the unintended consequences of supporting such cases?

The unintended consequences don't come from "supporting the use case" per se, they come from the technical details of the approach used to do so. For example:

For your malware example, "change DNS records by intercepting queries between the client and the recursive resolver and inject NXDOMAIN for malware domains" is one way to implement such a thing. The unintended consequences of this are "you can't deploy DNSSEC", "anyone on the same path can do the same interception, maybe even to add malware", and so on.

Another way to support the same use case would be to add endpoint defenses to the browser for web-based malware: in this case the browser checks URLs against a blocklist. The tradeoff here is that you need to touch every browser, and a possible unintended consequence here is that the infrastructure to distribute the blocklists is a potential further centralization of the architecture.

Cheers,

Brian

> Regards,
> S, Moonesamy
> 
> 
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss