[secdir] SecDir Review of draft-ietf-lmap-use-cases-05
Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 19 November 2014 09:07 UTC
Return-Path: <hannes.tschofenig@gmx.net>
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 62FFB1ACFC8; Wed, 19 Nov 2014 01:07:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level:
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, 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 DmEfijbTUtab; Wed, 19 Nov 2014 01:07:49 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85731A0059; Wed, 19 Nov 2014 01:07:48 -0800 (PST)
Received: from [192.168.131.129] ([80.92.115.84]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MDW9x-1Xjb7N35kT-00GuRd; Wed, 19 Nov 2014 10:07:36 +0100
Message-ID: <546C5DD7.3060900@gmx.net>
Date: Wed, 19 Nov 2014 10:07:35 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-lmap-use-cases@tools.ietf.org
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="xk9IDHHuSlbfrsExC6MUmQvpItfmOruhg"
X-Provags-ID: V03:K0:ArQb+w3k9fohDTnzaUXl50colMuFhc7rNXqwxoRXV9VWsLj9FLs 3+aV1ju+dIfBtLzfP0xIW7lagefxgIe3knpMbQJ/JF+lqT0kxBe5EJRdyIyqpW9z+HsT7IQ TMGZUjk6mp1sjHHGYGuUec9o9TEMpCT/AjmfhR0HDFmfYU0egLCJwVobZJqV6rT2f8X4u/e SFpWufM6pjj5uGm/k20nw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/QS-xmPQC_6CwRn9INxWVUxxlq9E
Subject: [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 09:07:52 -0000
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. 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 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.) 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. Ciao Hannes
- [secdir] SecDir Review of draft-ietf-lmap-use-cas… Hannes Tschofenig
- Re: [secdir] SecDir Review of draft-ietf-lmap-use… philip.eardley