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

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

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

> -----Original Message-----
> From: lmap [mailto:[e-mail]] On Behalf Of Stephen Farrell
...
> ----------------------------------------------------------------------
> 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.

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

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