Subject: [lmap] Stephen Farrell's No Objection on draft-ietf-lmap-framework-12: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 09 Apr 2015 06:58:45 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-lmap-framework-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-lmap-framework/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- general: Thanks for the significant consideration
of privacy, the draft has a quite good analysis. I
want to check though that the plan is that other lmap
drafts, esp protocol drafts, will in fact describe
(and maybe mandate) ways to meet privacy goals, and
will not simply refer to section 8 of this and tell
developers to go figure it out. If that latter was
the plan/expectation, then we'd be better off
discussing that now, rather than as a late surprise
for the WG. I assume though that the plan is rather
to try make the lmap protocol something that can
really be used in a privacy sensitive manner and that
defaults to that where possible, in which case we'll
not have that problem.

- One way in which it might be possible to provide
evidence that a system respects user privacy would be
to have some kind of auditor entity as part of the
framework. For example, an MA could be setup to send
some selection of reports/instructions to (or
encrypted for) the auditor as well as to the normal
destination. Did the WG consider such an entity?
(This is not a DISCUSS as I can see pros and cons in
the auditor-approach, so I'm not sure if it'd be a
good idea in the end.)

- Thanks for section 8, one suggestion - I'd argue
that "privacy respecting/friendly" ought be a bullet
at the end of section 1, as if the system is not,
then it'll eventually be turned off, one way or
another. If you agree, I'd be happy. If not, I'll not
get in the way.

- 5.4 (and elsewhere) I'm not sure a Group-ID by
itself is sufficient to hide identity (timing and
soure addressing may expose it anyway). That should
be noted, and that lmap protocols should be analysed
to see what turns out to be the case. I'm not sure
talking about "anonymising" is really correct as
anonymity is a very very hard thing to achieve. 

- section 8: I'm not that keen on considering the
privacy of organisations at the same level as that of
people. I can see why you might do it but that is
also often done as a way to minimise the privacy of
people.

- section 8: I didn't spot considerations related to
re-identification, which can be significant.  E.g. if
I can see other traffic that identifies a person and
the re-identify that person based on LMAP trafic
later on (or elsewhere). Did the WG consider that?

- section 8: I'm not sure that the "user consent"
thing is really of that much benefit here (and it's
ubiquitously abused on the Internet today).  It
would have been welcome had the WG come up with
something better, but then since I don't have a
solution to hand, I can't insist that you do;-)

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sun, 12 Apr 2015 18:47:38 -0400

Hi Stephen, 
many replies below (since most is on section 8),
other authors should chime in too.
Al

> -----Original Message-----
> From: lmap [mailto:[email-masked]] On Behalf Of Stephen Farrell
...
> - general: Thanks for the significant consideration of privacy, the
> draft has a quite good analysis. I want to check though that the plan is
> that other lmap drafts, esp protocol drafts, will in fact describe (and
> maybe mandate) ways to meet privacy goals, and will not simply refer to
> section 8 of this and tell developers to go figure it out. If that
> latter was the plan/expectation, then we'd be better off discussing that
> now, rather than as a late surprise for the WG. I assume though that the
> plan is rather to try make the lmap protocol something that can really
> be used in a privacy sensitive manner and that defaults to that where
> possible, in which case we'll not have that problem.

I think it's expected that the protocol design(s) will embrace the 
relevant mitigations described in section 8, just as they should take-on
all relevant specifications of the framework. So, the answer is yes, IMO.

> 
> - One way in which it might be possible to provide evidence that a
> system respects user privacy would be to have some kind of auditor
> entity as part of the framework. For example, an MA could be setup to
> send some selection of reports/instructions to (or encrypted for) the
> auditor as well as to the normal destination. Did the WG consider such
> an entity?
> (This is not a DISCUSS as I can see pros and cons in the auditor-
> approach, so I'm not sure if it'd be a good idea in the end.)

An independent auditor is an interesting possibility, but it didn't come-up
in discussions.  That's likely due to the scope of initial LMAP work,
which limits us to design for LMAP systems under the control of a 
single organization. I'm assuming the auditor needs to be somehow independent
to be effective.

> 
> - Thanks for section 8, one suggestion - I'd argue that "privacy
> respecting/friendly" ought be a bullet at the end of section 1, as if
> the system is not, then it'll eventually be turned off, one way or
> another. If you agree, I'd be happy. If not, I'll not get in the way.

I agree, something like:

  o  Privacy Conserving - the protocols and procedures should respect the
     sensitive information of all those involved in measurements.

> 
> - 5.4 (and elsewhere) I'm not sure a Group-ID by itself is sufficient to
> hide identity (timing and soure addressing may expose it anyway). That
> should be noted, and that lmap protocols should be analysed to see what
> turns out to be the case. I'm not sure talking about "anonymising" is
> really correct as anonymity is a very very hard thing to achieve.

That's a fair point, we could add this limitation in section 5.1,
the second bullet seems to be where Group-ID is first discussed in 
some detail.  (It's never claimed that Group-ID fixes cures all ills.)

> 
> - section 8: I'm not that keen on considering the privacy of
> organisations at the same level as that of people. I can see why you
> might do it but that is also often done as a way to minimise the privacy
> of people.

In this case, the specific organization is an ISP, who has responsibilities
to protect the sensitive customer info they possess and to protect 
the private information about their network which they are entitled to conceal.

> 
> - section 8: I didn't spot considerations related to re-identification,
> which can be significant.  E.g. if I can see other traffic that
> identifies a person and the re-identify that person based on LMAP trafic

The short answer is that if RFC 6973 had considered re-identification, we would have.
The closest topic we covered is Correlation, combining various separate pieces of info
to obtain identity. The point is that an LMAP system could unwittingly
complete an information chain if it exposes any sensitive info, so don't.

If a user's access with another system already gave away sensitive info, 
correlation is clearly easier and can result in re-identification, 
even when an LMAP conserves sensitive information to great extent.
We could add this point in 8.5.3.

> thing is really of that much benefit here (and it's ubiquitously abused
> on the Internet today).  It would have been welcome had the WG come up
> with something better, but then since I don't have a solution to hand, I
> can't insist that you do;-)

Right now, user consent and temporary/per-instance user consent are helpful
if the protocols communicate the permission status, or stop transactions
when they don't get indication of permission. We have difficulty limiting what 
consenting adults do.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 13 Apr 2015 01:10:32 +0100

Hi Al,

> all relevant specifications of the framework. So, the answer is yes, IMO.

Great.

> single organization. I'm assuming the auditor needs to be somehow independent

Well, while I think the idea has pros and cons, I don't think
ruling it out on the single-domain ground is really compelling.
Enterprises inherently qualify as single-domain but yet all (are
required to) do some kind of audit. And in some senses, a comms.
regulator could be considered as having audit of ISPs as part of
it's remit I guess, esp. where an ISP has (near) local monopoly.
So no, I don't think that gets us off the hook, in terms of
whether or not we ought consider an audit function.

Maybe that's one to raise with the WG and see what folks think?
>From my POV, it's fine to leave out of this document though,
but I think would be good to consider more fully as the work
proceeds.

(To be clear: I think an audit approach to privacy isn't an
ultra-clear winner at all. In some cases, it'd help, but I can
imagine circumstances where an audit function could be abused
in highly privacy unfriendly ways.)

>      sensitive information of all those involved in measurements.

I like that.

> some detail.  (It's never claimed that Group-ID fixes cures all ills.)

Ack.

> the private information about their network which they are entitled to conceal.

Yes, that is something one hears argued. I just think it dilutes
the concept of privacy if we extend that to organisations as well
as people. And even moreso when the last decade or so tells us
that the very organisations to whom this document is granting
privacy "rights" are ones who have in ways not honoured the privacy
expectations of humans.

I'd really encourage you to re-cast discussion of network structure
in terms of security and confidentiality for the organisation, but
not in terms of privacy.

> We could add this point in 8.5.3.

That'd be great. I think we've loads to learn about re-identification
so just adding an acknowledgement of the issue is probably about right
for now.

> when they don't get indication of permission. We have difficulty limiting what 

As to that last, we have difficulty knowing when we're dealing with,
or being, consenting adults is the problem. (Do you really consent to
everything in every EULA through which you click? No you do not is
the reality, no matter the legalese.) But again I've no concrete change
that's better to offer, sorry.

Cheers & thanks for the full response.
S.

---

From: <[email-masked]>
Date: Tue, 14 Apr 2015 14:26:15 +0000

Hi,

Just wanted to highlight the IESG's assumption that LMAP protocols will describe how to meet the privacy goals, ie not just say 'read Section 8 of the framework'.
Just making sure that the protocol people are ok with this!

Privacy is mentioned in http://tools.ietf.org/html/draft-starkcarey-lmap-protocol-criteria-01 in the context of security 

---
Stephen Farrell's IESG comment:

> draft has a quite good analysis. I want to check though that the plan 
> is that other lmap drafts, esp protocol drafts, will in fact describe 
> (and maybe mandate) ways to meet privacy goals, and will not simply 
> refer to section 8 of this and tell developers to go figure it out. If 
> that latter was the plan/expectation, then we'd be better off 
> discussing that now, rather than as a late surprise for the WG. I 
> assume though that the plan is rather to try make the lmap protocol 
> something that can really be used in a privacy sensitive manner and 
> that defaults to that where possible, in which case we'll not have that problem.

Al's reply:
I think it's expected that the protocol design(s) will embrace the relevant mitigations described in section 8, just as they should take-on all relevant specifications of the framework. So, the answer is yes, IMO.

---

From: <[email-masked]>
Date: Tue, 14 Apr 2015 14:50:54 +0000

Stephen,
Thanks!

>      sensitive information of all those involved in measurements.

I think 'Privacy respecting' is better than 'Privacy conserving'.

> 
> >
> > - 5.4 (and elsewhere) I'm not sure a Group-ID by itself is sufficient
> > to hide identity (timing and soure addressing may expose it anyway).
> > That should be noted, and that lmap protocols should be analysed to
> > see what turns out to be the case. I'm not sure talking about
> > "anonymising" is really correct as anonymity is a very very hard
> thing to achieve.
> 
> That's a fair point, we could add this limitation in section 5.1, the
> second bullet seems to be where Group-ID is first discussed in some
> detail.  (It's never claimed that Group-ID fixes cures all ills.)
> 

Agree with above. The idea of Group-ID was so that you had to do some work to discover the end-user's identity - do it deliberately. With the MA-ID you have to do work not to know the MA's identity. 

In Section 5.4
>>   The Report contains:
>>   o  the MA-ID or a Group-ID (to anonymise results)
I agree this puts it too strongly. How about something like "to obscure the MA's identity"

I'm not sure whether this sentence in S8.4.1 needs to be similarly toned down:
<< Assignment of a Group-ID
   enables anonymisation sets to be formed on the basis of service
   type/grade/rates.  
Perhaps "obfuscation sets" would be better?

Similarly in S8.6.2
<< Another anonymisation technique is for the MA to include its Group-ID
   instead of its MA-ID
"obfuscation technique"?

> > re-identification, which can be significant.  E.g. if I can see other
> > traffic that identifies a person and the re-identify that person
> based
> > on LMAP trafic later on (or elsewhere). Did the WG consider that?
> 
> The closest topic we covered is Correlation, combining various separate
> pieces of info to obtain identity. The point is that an LMAP system
> could unwittingly complete an information chain if it exposes any
> sensitive info, so don't.
> 
> If a user's access with another system already gave away sensitive
> info, correlation is clearly easier and can result in re-
> identification, even when an LMAP conserves sensitive information to
> great extent.

If I understand your point, it's that the LMAP measurement traffic or control /reporting messages from a particular end-user may contain a 'signature' that enables someone to track the end-user (perhaps they're mobile)
Interesting point, would be worth adding somewhere. 

> > thing is really of that much benefit here (and it's ubiquitously
> > abused on the Internet today).  It would have been welcome had the WG
> > come up with something better, but then since I don't have a solution
> > to hand, I can't insist that you do;-)
> 
> Right now, user consent and temporary/per-instance user consent are
> helpful if the protocols communicate the permission status, or stop
> transactions when they don't get indication of permission. We have
> difficulty limiting what consenting adults do.
> 

User consent and empowerment seem central to Data protection and privacy regulations and discussions. I agree with you that the Internet industry hasn't worked out how to make this meaningful - beyond today's mostly unread T&Cs and (in Europe) irritating messages about cookies.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 15 Apr 2015 10:45:13 -0400

Hi Stephen, 
Thanks for your reply late Sunday,
I'm following up on just a few points, so I've
deleted the agreements in previous mail.

Al

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Sunday, April 12, 2015 8:11 PM
...
> >> auditor as well as to the normal destination. Did the WG consider
> >> such an entity?
> > An independent auditor is an interesting possibility, but it didn't
> > come-up in discussions.  That's likely due to the scope of initial
> > LMAP work, which limits us to design for LMAP systems under the
> > control of a single organization. I'm assuming the auditor needs to be
> > somehow independent to be effective.
> 
> Well, while I think the idea has pros and cons, I don't think ruling it
> out on the single-domain ground is really compelling.
> regulator could be considered as having audit of ISPs as part of it's
> remit I guess, esp. where an ISP has (near) local monopoly.
> So no, I don't think that gets us off the hook, in terms of whether or
> not we ought consider an audit function.
> 
> From my POV, it's fine to leave out of this document though, but I think
> would be good to consider more fully as the work proceeds.
> 
> (To be clear: I think an audit approach to privacy isn't an ultra-clear
> winner at all. In some cases, it'd help, but I can imagine circumstances
> where an audit function could be abused in highly privacy unfriendly
> ways.)
> 

I'm not ruling it out, but saying that the initial phase of LMAP work
simplifies all relationships by assuming a single system operator.
There are many aspects to consider when multiple organizations 
join the system. An auditor is one example where the trust boundary
has to be extended to include an independent entity, if that's how 
the audit is arranged.

I think it would be fair to add a recommendation for each entity in 8.1,
(individuals, ISPs, Regulators, others) to assess the risks of LMAP 
data collection by conducting audits of data protection methods 
(at end of 8.6.4).

This would be an essential topic in any further phase of LMAP.

(one of my favorite quotes applies here:
	"However beautiful the strategy, 
      you should occasionally look at the results.  Sir Winston Churchill  )

...
> >> might do it but that is also often done as a way to minimise the
> >> privacy of people.
> >
> > In this case, the specific organization is an ISP, who has
> > responsibilities to protect the sensitive customer info they possess
> > and to protect the private information about their network which they
> are entitled to conceal.
> 
> Yes, that is something one hears argued. I just think it dilutes the
> concept of privacy if we extend that to organisations as well as people.
> And even moreso when the last decade or so tells us that the very
> organisations to whom this document is granting privacy "rights" are
> ones who have in ways not honoured the privacy expectations of humans.
> 
> I'd really encourage you to re-cast discussion of network structure in
> terms of security and confidentiality for the organisation, but not in
> terms of privacy.

I sometimes have trouble distinguishing between these terms, especially
when they often result in taking the same measures to ensure their preservation.

In the US, certified accountants are often trusted more than others.
The American Institute of CPAs website says:  
"Privacy / Data Protection: Privacy encompasses the rights and obligations 
of individuals and organizations with respect to the collection, use, 
retention, disclosure, and disposal of personal information."

Here's what we said in section 8.1:
   Although privacy is a protection extended to individuals, we include
   discussion of ISPs and other LMAP system operators in this section.
   These organisations have sensitive information involved in the LMAP
   system, and many of the same dangers and mitigations are applicable.
   Further, the ISPs store information on their Subscribers beyond that
   used in the LMAP system (for instance billing information), and there
   should be a benefit in considering all the needs and potential
   solutions coherently.

We could say:
   Although privacy is a protection extended to individuals, we discuss 
   data protection by ISPs and other LMAP system operators in this section.
   ...

My own view is that sensitive information is so often shared among sets 
of individuals - in partnerships, marriages, families - that the privacy
boundary needs to be re-drawn for each piece of info considered and/or shared. 

> >> based on LMAP trafic later on (or elsewhere). Did the WG consider
> that?
> >
> > The closest topic we covered is Correlation, combining various
> > separate pieces of info to obtain identity. The point is that an LMAP
> > system could unwittingly complete an information chain if it exposes
> any sensitive info, so don't.
> >
> > info, correlation is clearly easier and can result in
> > re-identification, even when an LMAP conserves sensitive information
> to great extent.
> That'd be great. I think we've loads to learn about re-identification so
> just adding an acknowledgement of the issue is probably about right for
> now.
> 

Phil made a comment on re-identification, and I'll reply to
it separately on that thread.

...

Al

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 15 Apr 2015 10:54:59 -0400

Hi Phil and Stephen,
some replies in-line below.
(apologies for limited formatting help to find them)
Al

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, April 14, 2015 10:51 AM
> To: MORTON, ALFRED C (AL); [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [lmap] Stephen Farrell's No Objection on draft-ietf-lmap-
> framework-12: (with COMMENT)
> 
> Stephen,
> Thanks!
> 
> 
> > I agree, something like:
> >
> > > - 5.4 (and elsewhere) I'm not sure a Group-ID by itself is
> > > sufficient to hide identity (timing and soure addressing may expose
> it anyway).
> Agree with above. The idea of Group-ID was so that you had to do some
> work to discover the end-user's identity - do it deliberately. With the
> MA-ID you have to do work not to know the MA's identity.
> 
> In Section 5.4
> >>   The Report contains:

I don't think so, " anonymisation sets" is the RFC 6973 term.
We have said that anonymisation is difficult in 8.6.2, changing what
we call it doesn't change that fact. 

> > > re-identification, which can be significant.  E.g. if I can see
> > > other traffic that identifies a person and the re-identify that
> > > person
> > based
> If I understand your point, it's that the LMAP measurement traffic or
> control /reporting messages from a particular end-user may contain a
> 'signature' that enables someone to track the end-user (perhaps they're
> mobile) Interesting point, would be worth adding somewhere.

I took this to mean that once a person IS identified, then less info is
needed to infer that observed traffic is from the same person.
IOW, re-identifying Alice, once I've seen Alice's name and her IP address
together, can be accomplished with just the IP address.

I added to 8.5.3:

> > > abused on the Internet today).  It would have been welcome had the
> > > WG come up with something better, but then since I don't have a
> User consent and empowerment seem central to Data protection and privacy
> regulations and discussions. I agree with you that the Internet industry
> hasn't worked out how to make this meaningful - beyond today's mostly
> unread T&Cs and (in Europe) irritating messages about cookies.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Apr 2015 16:29:19 +0100

Hi Al,

I'm fine with all below and with the separate mail about
re-identification.

S.