Subject: [Add] ABCD BoF agenda items, pervasive monitoring and privacy

From: "Dixon, Hugh" <[email-masked]>
Date: Wed, 13 Nov 2019 10:55:11 +0000

Some might like to think that "Pervasive Monitoring" is clear and bold...

 (from RFC7258):
"Pervasive Monitoring Is an Attack"

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

So ...
PM is an attack.  Some PM is not an attack.

?
H

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: Mark Nottingham <[email-masked]>
Date: Thu, 14 Nov 2019 09:52:39 +1100

> On 13 Nov 2019, at 9:55 pm, Dixon, Hugh <Hugh.Dixon=[email-masked]> wrote:
> 

PM is an attack. Other things might use the same mechanisms as PM for benign purposes. 

In an ideal world we'd disallow PM and allow benign purposes -- but in many cases we can't distinguish them from an attack. We can find other ways to achieve those goals using alternative mechanisms, but we can't say "we won't protect against PM because doing so disables some useful things."

Cheers,

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

---

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

mnot> PM is an attack. Other things might use the same mechanisms as PM
mnot> for benign purposes. 

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.

mnot> In an ideal world we'd disallow PM and allow benign purposes --
mnot> but in many cases we can't distinguish them from an attack. We can
mnot> find other ways to achieve those goals using alternative
mnot> mechanisms, but we can't say "we won't protect against PM because
mnot> doing so disables some useful things."

I would agree that we shouldn't disallow techniques that prevent PM. But
we also shouldn't design techniques that users can't choose to
disable. If we don't allow things like DNS filtering for users who
actually have knowledge of and consent to, we become the authoritarians
we're trying to protect users from.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 13 Nov 2019 15:08:42 -0800

On Wed, Nov 13, 2019 at 2:52 PM Mark Nottingham <[email-masked]> wrote:

> In an ideal world we'd disallow PM and allow benign purposes -- but in
> many cases we can't distinguish them from an attack. We can find other ways
> to achieve those goals using alternative mechanisms, but we can't say "we
> won't protect against PM because doing so disables some useful things."
>
>
I think there is an enormous difference between saying "We won't protect
against PM", and "We won't do X as a way to protect against PM".

In other words, the argument regarding "PM or benign" should not be
sufficient, by itself, to justify the specific choice(s) of how to avoid
PM. If either of X or Y protect against PM, if we all agree that protection
against PM is a core requirement, then reaching rough consensus on X vs Y
should be done on technical merits, in a professional manner.

We can agree on protection against PM, even if we disagree on the
mechanisms. We should all agree up front, that disagreeing on the "how"
with no quarter given in the disagreement, would have the unwanted
consequence of not allowing adoption of any method of avoiding PM, and as
such, should inform discussion and consensus-reaching.

Brian

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 13 Nov 2019 23:14:18 +0000

paul> I would agree that we shouldn't disallow techniques that prevent PM. But

I agree. This to me leads us to transparency and configuration requirements for apps and platforms offering DNS services rather than requirements on the protocols apps and platforms use to perform DNS queries. Not sure if it's within scope of this WG or not (nor do I care to wade those waters), but it seems the question of "how do we ensure we're not preventing users from having control over their DNS traffic?" should be answered at the device level and not the network level because of the point made earlier: once bits are on the wire, it's impossible to distinguish between an attack and "approved administration" when those bits are manipulated. Better to emit bits in the manner the user intended in the first place.

Thanks,
Tommy

________________________________
From: Add <[email-masked]> on behalf of Paul Ebersman <[email-masked]>
Sent: Wednesday, November 13, 2019 3:07 PM
To: Mark Nottingham <[email-masked]>
Cc: Dixon, Hugh <Hugh.Dixon=[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy

--
Add mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7C8fac04dc07c5437deecf08d7688e4f63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637092832744031387&amp;sdata=Cjr3cpbLgvnSGwQyE9P2IQkOOYb3L8hjYgLpHqtzPJ4%3D&amp;reserved=0

---

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

Hiya,

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

FWIW, I don't agree.

First, what passes for "consent" in computing in general
is not what I would call consent, as understood in more
mature fields such as medicine, so I would not myself
accept so-called "consent" as a get out of jail card in
this nor any other Internet context. I don't claim that
everyone would agree with that but that's ok, because...

Second, the term "consent" doesn't occur in 7258. So I
don't think you have any real basis claim that 7258 is
anything to do with that risible (as used in computing)
abuse of terminology. (IIRC there are about 1000 mails
in the archive of ietf@ietf discussing the draft that
became 7258, so feel free to delve into those to see
if you find some backing for what you say above, but
TBH I don't recall that being discussed particularly.)

Thirdly, user knowledge does not make PM a non-attack.
We know that PM is being done still, but it remains an
attack.

Cheers,
S.

PS: The above says nothing about whether net-nanny type
DNS stuff is good nor bad, I'm only disagreeing with your
characterisation of PM and 7258.

---

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

tjensen> I agree. This to me leads us to transparency and configuration
tjensen> requirements for apps and platforms offering DNS services
tjensen> rather than requirements on the protocols apps and platforms
tjensen> use to perform DNS queries. Not sure if it's within scope of
tjensen> this WG or not (nor do I care to wade those waters), but it
tjensen> seems the question of "how do we ensure we're not preventing
tjensen> users from having control over their DNS traffic?" should be
tjensen> answered at the device level and not the network level because
tjensen> of the point made earlier: once bits are on the wire, it's
tjensen> impossible to distinguish between an attack and "approved
tjensen> administration" when those bits are manipulated. Better to emit
tjensen> bits in the manner the user intended in the first place.

Agreed. Intent (particularly user intent) is most easily discerned in
the end user device. I'm far more worried about my OS and applications
leaking things than the network I'm on, as I have less options to see or
control OS/app (other than not using them).

This seems like something worth discussing in docs in this WG.

---

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

sfarrell> First, what passes for "consent" in computing in general is
sfarrell> not what I would call consent, as understood in more mature
sfarrell> fields such as medicine, so I would not myself accept
sfarrell> so-called "consent" as a get out of jail card in this nor any
sfarrell> other Internet context. I don't claim that everyone would
sfarrell> agree with that but that's ok, because...

Will concede consent is a mess. Steve Bellovin's plenary was massively
depressing in that regard, moreso if you delve into the references
behind it.

sfarrell> Thirdly, user knowledge does not make PM a non-attack.
sfarrell> We know that PM is being done still, but it remains an
sfarrell> attack.
[...]
sfarrell> PS: The above says nothing about whether net-nanny type
sfarrell> DNS stuff is good nor bad, I'm only disagreeing with your
sfarrell> characterisation of PM and 7258.

Here I'll disagree. If I know something is happening and I want it to
happen, it's not an attack. I'll take the clarification that it requires
both, since knowledge without consent is still potentially an attack.

If I remove a file from my hard disk and I do that deliberately, that's
a "feature". If malware removes a file and I didn't want that to happen,
that's an "attack". Calling anything that removes a file an attack is a
sloppy problem statement.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 13 Nov 2019 15:42:45 -0800

On Wed, Nov 13, 2019 at 3:14 PM Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:

> I agree. This to me leads us to transparency and configuration
> requirements for apps and platforms offering DNS services rather than
> requirements on the protocols apps and platforms use to perform DNS queries.
>

> Not sure if it's within scope of this WG or not (nor do I care to wade
> those waters), but it seems the question of "how do we ensure we're not
> preventing users from having control over their DNS traffic?" should be
> answered at the device level and not the network level because of the point
> made earlier: once bits are on the wire, it's impossible to distinguish
> between an attack and "approved administration" when those bits are
> manipulated. Better to emit bits in the manner the user intended in the
> first place.
>

We should be careful about distinguishing "what is currently the case" from
"what is possible", and avoid ruling out entire paths of
exploration/development based on possibly erroneous assumptions.

Let me provide a hypothetical counter-example to the assertion that is not
possible (to distinguish an attacker manipulating DNS responses, from a
known party manipulating DNS responses).

Suppose a known party, with whom the client has a relationship, uses DNSSEC
(or other cryptographic signature mechanism) to sign the manipulated
responses.
Suppose the client has installed some manner of validating cryptographic
object, such as a DNSSEC Trust Anchor.

The nature of public key cryptography is that only the party that possesses
the private key can generate such a signature.
If the recipient has the corresponding public key, and trusts it, it is
possible to distinguish the two situations, attacker vs known party.

This does not specifically mandate a particular solution to the problem,
but it DOES demonstrate that a solution to the problem is possible (and
feasible and capable of being operated at scale, etc.)

Brian

---

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

On 13/11/2019 23:40, Paul Ebersman wrote:
> 
> Here I'll disagree. If I know something is happening and I want it
> to happen, it's not an attack.

The "it" involved in PM affects many people, not just
you or I. And your opinion may depend on the identity
of the putative PM attacker. That was all thoroughly
discussed in the development of 7258.

> I'll take the clarification that it requires both, since knowledge
> without consent is still potentially an attack.

See my earlier mail for my opinion of so-called
"consent":-)

S.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 13 Nov 2019 16:24:01 -0800

On Wed, Nov 13, 2019 at 3:32 PM Stephen Farrell <[email-masked]>
wrote:

> abuse of terminology.

RFC 7258 references 6973, in its Section 4 (Security Considerations).

Specifically, it says:

More information about the relationship between security and privacy
threats can be found in [RFC6973 <https://tools.ietf.org/html/rfc6973>]

However, in 6973, section 6.2 (
https://tools.ietf.org/html/rfc6973#section-6.2 ), talks specifically about
User Participation.

Quoting from that section:

As a result, privacy regimes tend to include
>
>
> Cooper, et al.                Informational                    [Page 21]
>
> ------------------------------
>
>   <https://tools.ietf.org/html/rfc6973#page-22>RFC 6973 <https://tools.ietf.org/html/rfc6973>                 Privacy Considerations                July 2013
>
>
>    provisions to require informing individuals about data collection and
>    use and involving them in decisions about the treatment of their
>    data.  In an engineering context, supporting the goal of user
>    participation usually means providing ways for users to control the
>    data that is shared about them.  It may also mean providing ways for
>    users to signal how they expect their data to be used and shared.
>
>
Basically, this directly refutes what you write about "consent", and is
referenced by 7258 in a way that at least suggests it is more authoritative.

It doesn't have to be labeled as "consent" to actually be consent, and this
discussion of goals and methods, regarding informing users and providing
control and signaling intent, seems to cover the issue very succinctly. No
means no, but yes means yes.

It does appear to imply the need for explicit consent, so I'd agree with
excluding implied consent as an acceptable mechanism.

But that is different from asserting that explicit consent isn't really
possible.

(If you didn't agree with what was in 6973, maybe you shouldn't have
included a reference to it, or should maybe have called out the section on
User Participation as a problem.)

Respectfully,
Brian

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 Nov 2019 00:51:43 +0000

Hiya,

On 14/11/2019 00:24, Brian Dickson wrote:
> Basically, this directly refutes what you write about "consent", 

You are incorrect.

So-called "consent" (as the term is abused in computing)
rarely if ever has anything to do with how a user's data
is treated. In approx. 100% of cases (counting say user
actions) relevant to this discussion, so-called "consent"
is an attempt to trick users into saying "yes" and really
nothing more.

> and is

No. 7258 is a BCP with IETF consensus, 6793 is an IAB
stream informational RFC and reflects the opinion of the
IAB members at that time. (As it happens, I like most of
the text, and think it'd be a fine thing if the IETF had a
BCP on that subject.)

> 
> It doesn't have to be labeled as "consent" to actually be consent, 

Perhaps. My point is different: I claim that what is termed
"consent" in computing, the Internet and the web is really 99% a load of
lawyerly obfuscatory crap and nothing to do
with consent.

> and this

7258 is not "my" document - I was the editor. But see above
relating to the formalities.

But I think we're wandering off topic now.

Cheers,
S.

---

From: Rob Sayre <[email-masked]>
Date: Thu, 14 Nov 2019 01:02:32 -0800

> Some might like to think that "Pervasive Monitoring" is clear and bold...

Yes, I think it's pretty clear and bold. :)

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

I believe I may have received this message in error, but I'm not sure what
to do about that, since it's a public message. I'm happy to delete it.

> Please note we reserve the right to monitor all e-mail communication
> through our internal and external networks.
>

 ...

thanks,
Rob

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 14 Nov 2019 13:01:35 +0000

Moin!

On 13 Nov 2019, at 23:14, Tommy Jensen wrote:
> requirements on the protocols apps and platforms use to perform DNS 
> queries. Not sure if it's within scope of this WG or not (nor do I 
> care to wade those waters), but it seems the question of "how do we 
> ensure we're not preventing users from having control over their DNS 
> traffic?" should be answered at the device level and not the network 
> level because of the point made earlier: once bits are on the wire, 
> it's impossible to distinguish between an attack and "approved 
> administration" when those bits are manipulated.
While this is possible for well behaved clients, it’s hardly possible 
for devices that attack my network, like hacked IoT devices. We have to 
give the network some means to defend against this. To achieve this the 
proper behaviour of well defined client must be predictable and follow 
what the network offers. If attack and regular traffic look the same 
defending against attack traffic gets much harder.

So long
-Ralf
—--
Ralf Weber

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Nov 2019 08:13:22 -0500

Sent from my iPad
On Nov 14, 2019, at 8:02 AM, Ralf Weber <[email-masked]> wrote:
> While this is possible for well behaved clients, it’s hardly possible for devices that attack my network, like hacked IoT devices. We have to give the network some means to defend against this. To achieve this the proper behaviour of well defined client must be predictable and follow what the network offers. If attack and regular traffic look the same defending against attack traffic gets much harder.

Your IoT devices should not be able to communicate freely with all other devices on your network (or off).   They should be firewalled automatically using MUD.   This is a much more effective strategy than filtering their DNS queries, because it is a list of permitted connections rather than a list of excluded connections. The permission list permits only those destinations the IoT device should be talking to.  An exclusion list allows the IoT device to talk to all unknown adversaries, and only blocks communication with known adversaries.   So it’s perhaps marginally better than nothing, but still mostly useless.

---

From: "Dixon, Hugh" <[email-masked]>
Date: Thu, 14 Nov 2019 13:41:17 +0000

Ducks are birds
Ducks are defined {thusly}
Some things that match {thusly} are in fact not ducks.  Or they are ducks but they're not actually birds.
---
Either {thusly} is insufficiently precise, and hence not useful for animal taxonomy, or the title should be "Some ducks are birds"

H

On 14/11/2019, 00:51, "Stephen Farrell" <[email-masked]> wrote:

    Hiya,

    You are incorrect.

    Cheers,
    S.