1. 1 privecsg-15-0013-00-ecsg Response to comments on Privacy PAR/CSD Date: [2015-03-12] Authors: NameAffiliationPhoneEmail Juan Carlos ZúñigaInterDigital LabsJuanCarlos.Zuniga@InterDigital.com Notice: This document does not represent the agreed view of the IEEE 802 EC Privacy Recommendation SG. It represents only the views of the participants listed in the ‘Authors:’ field above. It is offered as a basis for discussion. It is not binding on the contributor, who reserve the right to add, amend or withdraw material contained herein. Copyright policy: The contributor is familiar with the IEEE-SA Copyright Policy.http://standards.ieee.org/IPR/copyrightpolicy.html Patent policy: The contributor is familiar with the IEEE-SA Patent Policy and Procedures: and.http://standards.ieee.org/guides/bylaws/sect6-7.html#6http://standards.ieee.org/guides/opman/sect6.html#6.3 Abstract The present document proposes some responses to the comments received on the Privacy Recommendation PAR/CSD

2. 2 privecsg-15-0013-00-ecsg Comments from Roger Marks https://mentor.ieee.org/privecsg/dcn/15/privecsg-15- 0008-00-0000-comments-on-privacy-recommendation- par-and-csd.pdfhttps://mentor.ieee.org/privecsg/dcn/15/privecsg-15- 0008-00-0000-comments-on-privacy-recommendation- par-and-csd.pdf Dates The PAR form dates are blank. Dates are consensus- based decisions to which participants may be sensitive. These must be discussed and agreed as part of the technical decision to submit a PAR. They are not editorial issues. –Dates will be provided, stating that the project expects to finalize 2 years after the initial date March 2015

3. 3 privecsg-15-0013-00-ecsg Comments from Roger Marks Working Group The Working Group is indicated as: “Privacy Recommendation EC Study Group (C/LM/PrivacySG).” This is not a valid Working Group. Proposed change: Name an existing Working Group, or a new one. Suggestion: 802.1 Working Group –Agreed March 2015

4. 4 privecsg-15-0013-00-ecsg Comments from Roger Marks Title Extraneous language in the title follows format that has generally been abandoned within IEEE 802. Proposed change: Title: Recommended Practice for Information technology-- Telecommunications and information exchange between systems– Local and metropolitan area networks: Privacy considerations for IEEE 802 Technologies. –Agreed March 2015

5. 5 privecsg-15-0013-00-ecsg Comments from Roger Marks Scope (1) Scope refers to “general recommendations”, but the project will be of little use without specific recommendations. Proposed change: Title: This document specifies a privacy threat model for IEEE 802 technologies and provides general recommendations for standards developers and implementers on how to protect against privacy threats. –Agreed March 2015

6. 6 privecsg-15-0013-00-ecsg Comments from Roger Marks Scope (2) Scope refers to “recommendations for standards developers,” but the remainder of the PAR and CSD have no indication that the recommendations are relevant to the development of standards within IEEE 802. Is an intent to make recommendations on how IEEE 802 standards should be amended? If no, then “for standards developers” should be deleted from the scope. If yes, then the rest of the PAR and CSD should be aligned (including but not limited to, the “Stakeholders,”“Broad Market Potential,” and “Technical Feasibility” elements). –Propose clarifying that privacy can be engineered by design. Please see: https://mentor.ieee.org/omniran/dcn/15/omniran-15- 0015-00-CF00-privacy-engineered-access-network.pptxhttps://mentor.ieee.org/omniran/dcn/15/omniran-15- 0015-00-CF00-privacy-engineered-access-network.pptx March 2015

7. 7 privecsg-15-0013-00-ecsg Comments from Roger Marks Purpose The language mentions “recommendations to address privacy threats” and mentions some threats, but it does not explain the purpose of the recommendations. Presumably, the recommendations will mitigate the threats if adopted. But to whom are the recommendations addressed? To which users, designers, standards groups, implementers, or network elements will the recommendations be applicable? This is not apparent, and, without an understanding of the answer, it is difficult to understand the purpose. –Requires further clarification about the expected audience of the document March 2015

8. 8 privecsg-15-0013-00-ecsg Comments from Roger Marks Stakeholders See comments on Scope and Purpose –Agree to provide coherent information in these sections March 2015

9. 9 privecsg-15-0013-00-ecsg Comments from Roger Marks CSD Coexistence The response “A CA document is not applicable because this project does not use wireless spectrum.” could be understood to mean that the standard is not applicable to wireless networks. Proposed change: A CA document is not applicable because this project standard does not use specify wireless spectrum operation. Smart-aleck remark: The criterion is not applicable because it applies only to a WG proposing a project, not to a Study Group proposing a project. –Agree with proposed text March 2015

10. 10 privecsg-15-0013-00-ecsg Comments from Roger Marks CSD Broad Market Potential “Broad Market Potential” refers to “numerous users.” But who are the users of the recommendation? For example, if standards developers are potential users of the recommendation, which standards developers are potential adopters? –Will provide details about expected audience March 2015

11. 11 privecsg-15-0013-00-ecsg Comments from Roger Marks CSD Technical Feasibility The response indicates that “The recommended practice will define recommendations that can be followed by system designers and implementers,” but the Scope refers to “recommendations for standards developers and implementers.” Which is it: system designers or standards developers? –Will provide details about expected audience March 2015

12. 12 privecsg-15-0013-00-ecsg Comments from Roger Marks CSD Economical Feasibility The response does not address economic feasibility. Increased privacy has economic benefits to some parties and is an economic threat to others. These issues should be articulated. –Should state that Privacy enhances, not degrades, security and functionality –Please see: https://mentor.ieee.org/omniran/dcn/15/omniran- 15-0015-00-CF00-privacy-engineered-access-network.pptxhttps://mentor.ieee.org/omniran/dcn/15/omniran- 15-0015-00-CF00-privacy-engineered-access-network.pptx March 2015

13. 13 privecsg-15-0013-00-ecsg Comments from 802.3 - PAR Project number –Agree with suggestion in the EC announcement email that this would fit in 802.1 and should be assigned there with assent of the 802.1 WG. –Agree 2.1 (non-­ ‐ substantive) Title doesn’t include a period (aka, full stop). (It is unlikely that publication editors would include one independent of the PAR.) –Agree 4.2, 4.3 Dates need to be included – lack of dates could suggest the SG does not yet understand the magnitude of the work to be done and resources required to complete the work. –Agree. See previous comment from Roger Marks March 2015

14. 14 privecsg-15-0013-00-ecsg Comments from 802.3 - PAR 5.1 Please justify the estimate of number of participants, for 802, this shouldn’t be the number of people expected to be in the WG ballot group, but the number actively participating in the project (e.g., TF/TG). How many regular ECSG participants is a good indicator. This number is subject to review by the WG and EC at checkpoints, so not inflating this number is wise. –73 subscribers to mailing list, 24 contributors to mailing list, 12 contributors to mentor, 15-20 attendees to face-to-face meetings, 18-25 attendees to teleconferences March 2015

15. 15 privecsg-15-0013-00-ecsg Comments from 802.3 - PAR 5.2.a (non-­ ‐ substantive) There is a superfluous return in the presumably pasted text. –Agree 5.4 (non-­ ‐ substantive) Inappropriate capitalization of attack methods. –Agree 5.5 (non-­ ‐ substantive) There are superfluous returns in the presumably pasted text. –Agree March 2015

16. 16 privecsg-15-0013-00-ecsg Comments from 802.3 - CSD General: The responses are perfunctory and are generally without substance. Managed Objects: A recommended practice can include parameters and management capability. The response needs to be relevant to this proposed project and why the scope of work will not include management capability. If high level management architecture or capability definition is included, (what we expect with threat definition and measurement), that should be stated in the response. –Should clarify that no management architecture is expected Broad Market Potential This response sounds like it is in satisfaction of an existing and well known privacy requirement, (e.g., an encryption protocol), not for determining the need for encryption (e.g., threat assessment). –Should clarify differences between Privacy and Security, and perhaps related requirements March 2015

17. 17 privecsg-15-0013-00-ecsg Comments from 802.3 - CSD Technical Feasibility It would be expected for the response to address the technical feasibility to measure each of the multiple threats listed in the Purpose section of the PAR. –List will only include Surveillance, as per 802.1’s comment Economic Feasibility Answer is non-­ ‐ responsive to the list of considerations. It does not address at all the economic feasibility of doing the threat assessment. –See previous response to Roger Mark’s comment Most security techniques have some impact on system cost(e.g., encryption hardware, software complexity), security overlays have installation costs. While features integral to implementations may have negligible installation impacts, maintenance costs (updating capabilities for new threats) certainly have operational cost implications. –Should clarify misunderstanding between Privacy and Security, and perhaps mention some examples March 2015

18. 18 privecsg-15-0013-00-ecsg Comments from 802.11 4.2 and 4.3 need to include target dates for completion. Should be at least 6 months apart. –See previous response to Roger Mark’s comment 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” –Agree with the above 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)”. –See previous response to Roger Mark’s comment March 2015

19. 19 privecsg-15-0013-00-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. –Agree 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. –Should provide example of Surveillance March 2015

20. 20 privecsg-15-0013-00-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. –Responding to this comment requires further consideration by the group 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. –Responding to this comment requires further consideration by the group March 2015

21. 21 privecsg-15-0013-00-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. –Agree March 2015

22. 22 privecsg-15-0013-00-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. –Agree 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. –Agree 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. –See previous response to Roger Mark’s comment March 2015

23. 23 privecsg-15-0013-00-ecsg Comments from Paul Nikolich (1/2) 1) 2.1 Title. Shorten to "Recommended Practice on Privacy Recommendations for IEEE 802 Technologies. –Agree (verify with EC) 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? –See previous response to 802.3’s comment 3) 5.2 Scope. I recommend deleting "...for standards developers...". and move it to Purpose. –See previous response to Roger Mark’s comment March 2015

24. 24 privecsg-15-0013-00-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. Suggest adopting text, with limited list as per 802.1’s comment 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. –Agree March 2015