1

privecsg-15-0010-01-ecsg

IEEE 802 EC Privacy Recommendation SGComments on Privacy PAR/CSD

March, 2015

Juan Carlos Zuniga, InterDigital Labs(EC SG Chair)

2

privecsg-15-0010-01-ecsg

Comments from Roger Marks

• https://mentor.ieee.org/privecsg/dcn/15/privecsg-15-0008-00-0000-comments-on-privacy-recommendation-par-and-csd.pdf

March 2015

3

privecsg-15-0010-01-ecsg

Comments from 802.3

Embedded file:

4

privecsg-15-0010-01-ecsg

Comments from 802.11

• 4.2 and 4.3 need to include target dates for completion. Should be at least 6 months apart.

• 5.2 Change “document” to “recommended practice”• 5.4 delete “document” result “The recommended practice…”• 5.5 change “and certain threats” to “and certain privacy threats”• 5.5 change “with IETF in many” to “with IETF on many”• 5.5 change “guidelines” to “recommendations”• CSD:• Distinct Identity: change “defines privacy” to “defines a privacy”

and “practice” to “practices”• Economic Feasibility – Question was not answered need to

provide evidence and address the requested specific areas “a) through e)”.

March 2015

5

privecsg-15-0010-01-ecsg

Comments from 802.22

1. There are a lot of carriage returns in Sections 5.2 and 5.5. You may want to remove them.

2. It will be nice to provide an example of some of the mechanisms on how the system can achieve resilience to (Surveillance, Monitoring, Stored Data Compromise, Intrusion, Misattribution, Correlation, Identification, Secondary Use, Disclosure and Exclusion) without making too many modifications to the operation of the system - e. g. MAC address randomization.

March 2015

6

privecsg-15-0010-01-ecsg

Comments from 802.1 (1/3)

• General – Many aspects of this proposed PAR seemed to refer to the need for an activity within 802, rather than for the need for the production of a Recommended Practice or other standards document. The timescale over which this activity needs to influence the development of standards within 802 seems to be rather shorter than the time that it would take to develop and approve a Recommended Practice of the proposed scope (typically 2-3 years). There needs to be some consideration of the intended audience for this Recommended Practice. If it is the relative small community of experts that will/could incorporate privacy best practices in 802 standards going forward, other influencing methods may be more appropriate. The Recommended Practice might be retargeted to the external community of developers and users.

• Scope - We do not understand what is meant in ‘scope’ by ‘privacy threat

model’ as there are multiple different interpretations of this term including: (a) reference to ‘privacy considerations’ (RFC 6973); or (b) an analysis of the threats that the project might feasibly address; or (c) reference to a top down security model.

March 2015

7

privecsg-15-0010-01-ecsg

Comments from 802.1 (2/3)

• Purpose – the threats listed appear to be overly broad, with no technical work having been done to date with respect to the feasibility of addressing some of the areas listed, specifically – Stored Data Compromise– Intrusion– Misattribution– Secondary Use– Exclusion

• A focus on specific requirements would seem to be essential to timely project completion. Suggest that the current purpose termination after “including Surveillance.” This should make it clear that the project will address the surveillance issue and that it’s successful conclusion should not be held up by objections that it does not satisfactorily address ‘Misattribution’, for example.

March 2015

8

privecsg-15-0010-01-ecsg

Comments from 802.1 (3/3)

• Need – The Need section of the PAR should address why this specific project is needed, not why privacy in general is wanted.

• Technical Feasibility – The technical feasibility that has been demonstrated does not match the proposed scope. Demonstration of the successful use of MAC address randomization does not itself demonstrate that a particular privacy goal has been achieved.

• Economic Feasibility – The statement being made in this section

of the CSD is a statement of future intent, not evidence of economic feasibility. It would be easier to make a justifiable statement for a PAR with a narrower scope.

March 2015

9

privecsg-15-0010-01-ecsg

Comments from Paul Nikolich (1/2)

• 1) 2.1 Title. Shorten to "Recommended Practice on Privacy Recommendations for IEEE 802 Technologies.

• 2) 5.1 Approximate number of people. 50 seems unrealistically high (I suspect it will be closer to 20), but I may be off base. How did you arrive at that number?

• 3) 5.2 Scope. I recommend deleting "...for standards developers...". and move it to Purpose.

March 2015

10

privecsg-15-0010-01-ecsg

Comments from Paul Nikolich (2/2)

• 4) 5.4 Purpose. part 1 It seems to me much of the Purpose belongs in Scope.

• I suggest moving some of the Purpose text to Scope. Possible Scope text:– Scope: "This document specifies a privacy threat model applicable to

IEEE 802 link layer technologies. The model addresses privacy threats such as Surveillance, Monitoring, Stored Data Compromise, Intrusion, Misattribution, Correlation, Identification, Secondary Use, Disclosure and Exclusion.

• 5) 5.4 Purpose. part 2• Possible modified Purpose text:

– Purpose: To develop a recommendation that defines a privacy threat model and a privacy guideline for 802 standards developers.

March 2015