privecsg15 0010 00 ecsg IEEE 802 EC Privacy

  • Slides: 8
Download presentation
privecsg-15 -0010 -00 -ecsg IEEE 802 EC Privacy Recommendation SG Comments on Privacy PAR/CSD

privecsg-15 -0010 -00 -ecsg IEEE 802 EC Privacy Recommendation SG Comments on Privacy PAR/CSD March, 2015 Juan Carlos Zuniga, Inter. Digital Labs (EC SG Chair) 1

privecsg-15 -0010 -00 -ecsg March 2015 Comments from Roger Marks • https: //mentor. ieee.

privecsg-15 -0010 -00 -ecsg March 2015 Comments from Roger Marks • https: //mentor. ieee. org/privecsg/dcn/15/privecsg-150008 -00 -0000 -comments-on-privacy-recommendationpar-and-csd. pdf 2

privecsg-15 -0010 -00 -ecsg Comments from 802. 3 Embedded file: 3

privecsg-15 -0010 -00 -ecsg Comments from 802. 3 Embedded file: 3

privecsg-15 -0010 -00 -ecsg March 2015 Comments from 802. 11 • 4. 2 and

privecsg-15 -0010 -00 -ecsg March 2015 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)”. 4

privecsg-15 -0010 -00 -ecsg March 2015 Comments from 802. 22 1. There a lot

privecsg-15 -0010 -00 -ecsg March 2015 Comments from 802. 22 1. There 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. 5

privecsg-15 -0010 -00 -ecsg March 2015 Comments from 802. 1 (1/3) • General –

privecsg-15 -0010 -00 -ecsg March 2015 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. 6

privecsg-15 -0010 -00 -ecsg March 2015 Comments from 802. 1 (2/3) • Purpose –

privecsg-15 -0010 -00 -ecsg March 2015 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. 7

privecsg-15 -0010 -00 -ecsg March 2015 Comments from 802. 1 (3/3) • Need –

privecsg-15 -0010 -00 -ecsg March 2015 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. 8