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

["MORTON, ALFRED C (AL)" <[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, April 14, 2015 10:51 AM
> To: MORTON, ALFRED C (AL); [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [lmap] Stephen Farrell's No Objection on draft-ietf-lmap-
> framework-12: (with COMMENT)
> 
> Stephen,
> Thanks!
> 
> 
> > I agree, something like:
> >
> >   o  Privacy Conserving - the protocols and procedures should respect
> > the
> >      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?

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. 

> 
> Similarly in S8.6.2
> << Another anonymisation technique is for the MA to include its Group-ID
>    instead of its MA-ID
> >>
> "obfuscation technique"?
> 
> >
> > >
> > > - 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?
> >
> > 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.
> 
> 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:
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.


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