Re: [secdir] SecDir Review of draft-ietf-lmap-use-cases-05

<philip.eardley@bt.com> Wed, 19 November 2014 17:48 UTC

Return-Path: <philip.eardley@bt.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369531AD3D7; Wed, 19 Nov 2014 09:48:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQbat0PbZA3X; Wed, 19 Nov 2014 09:48:29 -0800 (PST)
Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3201AD3E0; Wed, 19 Nov 2014 09:48:23 -0800 (PST)
Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 19 Nov 2014 17:48:29 +0000
Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.213]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Wed, 19 Nov 2014 17:48:21 +0000
From: <philip.eardley@bt.com>
To: <hannes.tschofenig@gmx.net>, <secdir@ietf.org>, <iesg@ietf.org>, <draft-ietf-lmap-use-cases@tools.ietf.org>
Date: Wed, 19 Nov 2014 17:48:20 +0000
Thread-Topic: SecDir Review of draft-ietf-lmap-use-cases-05
Thread-Index: AdAD2FjBxlxG6NVMQQ+SRi3/3FK+1AAQYaZQ
Message-ID: <A2E337CDB7BC4145B018B9BEE8EB3E0D413A79212D@EMV67-UKRD.domain1.systemhost.net>
References: <546C5DD7.3060900@gmx.net>
In-Reply-To: <546C5DD7.3060900@gmx.net>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/YWg2cNpqL5aYPCAbF7OLwqX0hmk
Subject: Re: [secdir] SecDir Review of draft-ietf-lmap-use-cases-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Nov 2014 17:48:32 -0000

Hannes,

Thank-you for your review. Some follow-ups in-line

Best wishes
phil

> -----Original Message-----
> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
> Sent: 19 November 2014 09:08
> To: secdir@ietf.org; iesg@ietf.org; draft-ietf-lmap-use-
> cases@tools.ietf.org
> Subject: SecDir Review of draft-ietf-lmap-use-cases-05
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.
> These comments were written primarily for the benefit of the security
> area directors. Document editors and WG chairs should treat these
> comments just like any other last call comments.
> 
> This document outlines two main use cases for measuring broadband
> performance on a large scale.
> 
> The document is well-written and discusses security as well as privacy
> concerns.
> 
> I have a few remarks regarding the text in the security consideration
> section.
> 
> You introduce the terms "Measurement Agents", "Subscriber", and
> "Measurement Tasks" for the first time in the security consideration
> section.
> 
> I wonder whether you could describe the problems without actually
> having to reference the framework document.

[phil] will substitute the terms used earlier in the doc: probe, end user and measurement tests. 
Would prefer to keep the reference - as it gives a pointer, for people who want to read about some potential mitigations of the security issues.
 
> 
> A few remarks regarding the listed issues:
> 
>       1. a malicious party that gains control of Measurement Agents to
>       launch DoS attacks at a target, or to alter (perhaps subtly)
>       Measurement Tasks in order to compromise the end user's privacy,
>       the business confidentiality of the network, or the accuracy of
>       the measurement system.
> 
> How does the DoS attack against some other party compromise the end
> user's privacy? I guess you are referring to the threat described in
> Section 5.1.3 of http://tools.ietf.org/html/rfc6973

[phil] I think this bullet should be split in two. I think we were just making the general point that DoS attacks are bad (in ways too numerous to mention!).

1. a malicious party that gains control of Measurement Agents to
      launch DoS attacks at a target.

2. a malicious party that gains control of Measurement Agents to alter (perhaps subtly)
      Measurement Tasks in order to compromise the end user's privacy,
      the business confidentiality of the network, or the accuracy of
      the measurement system.

> 
>       2. a malicious party that gains control of Measurement Agents to
>       create a platform for pervasive monitoring [RFC7258], in order to
>       attack the privacy of Internet users and organisations.
> 
> You might want to explain that the developed protocol mechanism allows
> data about the user's communication to be collected. This collected
> data allows monitoring.
> 
> (I haven't followed the LMAP work in detail but it might be useful to
> state what type of data the system is anticipated to collect. If
> everything can be collected then a reference to RFC 2804 might be
> appropriate.)

[phil] How about adding this:
For example, imagine a malicious party that could distribute to the probes a measurement test that recorded (and later reported) all the IP addresses the end host communicated with. 

> 
>       6. a measurement system that is vague about who is responsible
> for
>       privacy (data protection); this role is often termed the "data
>       controller".
> 
> I would re-write this to:
> 
>       6. a measurement system that does not indicate who is responsible
> for the collection/processing of personal data and who is responsible
> for fulfilling the rights of users.
> 
> You could also say something about the need to
> 
>  * prevent unauthorized access to collected measurement data,
>  * give users the ability to view collected data,
>  * give users the ability to exert control over sharing, and
>  * enforce retention periods.

[phil] how about this?

6. a measurement system that does not indicate who is responsible for the collection and processing of personal data and who is responsible for fulfilling the rights of users. The responsible party (often termed the "data controller") should, as good practice, consider issues such as defining:- the purpose for which the data is collected and used; how the data is stored, accessed, and processed; how long it is retained for; and how the end user can view, update, and even delete their personal data. If anonymised personal data is shared with a third party, the data controller should consider the possibility that the third party can de-anonymise it by combining it with other information.  

> 
> Ciao
> Hannes