privecsg-15-0013-01-ecsg
Response to comments on Privacy PAR/CSD
Date: [2015-03-12]
Authors:
Name
Affiliation
Juan Carlos Zúñiga
InterDigital Labs
Phone
Email
JuanCarlos.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:
<http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and <http://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
1
privecsg-15-0013-01-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
• Dates
• The PAR form dates are blank. Dates are consensusbased 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
2
privecsg-15-0013-01-ecsg
March 2015
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
3
privecsg-15-0013-01-ecsg
March 2015
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
4
privecsg-15-0013-01-ecsg
March 2015
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.
– Responding to this comment requires further consideration by
the group
5
privecsg-15-0013-01-ecsg
March 2015
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-150015-00-CF00-privacy-engineered-access-network.pptx
6
privecsg-15-0013-01-ecsg
March 2015
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
7
privecsg-15-0013-01-ecsg
March 2015
Comments from Roger Marks
• Stakeholders
• See comments on Scope and Purpose
– Agree to provide coherent information in these
sections
8
privecsg-15-0013-01-ecsg
March 2015
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 clarifying text in a better way
9
privecsg-15-0013-01-ecsg
March 2015
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
10
privecsg-15-0013-01-ecsg
March 2015
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
11
privecsg-15-0013-01-ecsg
March 2015
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 probably state that Privacy control should enhance, not
degrade, security and functionality. Please see:
https://mentor.ieee.org/omniran/dcn/15/omniran-15-0015-00CF00-privacy-engineered-access-network.pptx
– (Consider adding a clear statement like the one used in IETF)
– There are examples of solutions that improve privacy without
increasing significantly the cost (e.g. MAC address
randomization)
12
privecsg-15-0013-01-ecsg
March 2015
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
13
privecsg-15-0013-01-ecsg
March 2015
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
– Should mention 18, as per the f2f meetings attendance
14
privecsg-15-0013-01-ecsg
March 2015
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
15
privecsg-15-0013-01-ecsg
March 2015
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).
– We recognize the comment and will address it in a future version of the
CSD
16
privecsg-15-0013-01-ecsg
March 2015
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 differences between Privacy and Security, and perhaps mention
some examples. We will address this in a future version of the CSD
17
privecsg-15-0013-01-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.
– 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. We will address this in a future
version of the CSD
18
privecsg-15-0013-01-ecsg
March 2015
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
19
privecsg-15-0013-01-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.
–
•
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
20
privecsg-15-0013-01-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.
– Agree
21
privecsg-15-0013-01-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.
– 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.
– We will address this comment in a future version of the CSD
22
privecsg-15-0013-01-ecsg
March 2015
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
23
privecsg-15-0013-01-ecsg
March 2015
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
24