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

[Stephen Farrell <[e-mail]>]

Hi Al,

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

Great.

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

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

I like that.

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

Ack.

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

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

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

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.


> 
> 
>