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

[Stephen Farrell <[e-mail]>]

Hi Al,

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

S.

On 15/04/15 15:45, MORTON, ALFRED C (AL) wrote:
> 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
>