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

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

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

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Sunday, April 12, 2015 8:11 PM
...
> >
> >>
> >> - 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.
> 
> 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.)
> 

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  )

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

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