1. March 2018
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [SG SECN PAR & CSD Comment resolution March 2018 Plenary]
Date Submitted: [7 March, 2018]
Source: [Don Sturek] Company [Itron]
Address [230 W. Tasman Drive, San Jose, CA ]
Voice[]
Re: []
Abstract: [PAR & CSD comment resolution]
Purpose: [PAR & CSD comment resolution for March 2018 SG SECN]
Notice: This document has been prepared to assist the IEEE P It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P
Don Sturek (Itron)

2. 802.15 SG SECN PAR & CSD Response
March 2018
SG SECN PAR & CSD Response
Don Sturek Itron
Don Sturek (Itron)

3. March 2018
y Comments from
PAR 2.1 “Amendment defining security extensions to IEEE Std adding at a minimum Advanced Encryption Standard (AES)-256” to “ Amendment defining support for Advanced Encryption Standard (AES)-256 encryption and security extensions.” Accept
PAR 5.2.b change “Std.” to “Std” Accept
Don Sturek (Itron)

4. March 2018
y Comments from
PAR 5.2b Change Scope statement to present tense and remove “at a minimum”. Accept
Change “This amendment defines security extensions to IEEE Std adding, at a minimum, AES-256. It also defines possible methods to simplify the addition of future encryption modes and key lengths. IEEE Std currently supports either AES-128 or no security”
To “This amendment adds support for AES-256 encryption and defines security extensions to allow for future encryption modes and key lengths. “ Accept
PAR 5.5 no need to capatilize “Quantum Computing” Revise, removed the reference as a result of comment
CSD b) need space between “control,etc.” Accept
Don Sturek (Itron)

5. March 2018
P y Comments from 802.3
Amendment: SECN (Security Next Generation)
PAR
2.1 — As an amendment to , it is unnecessary to repeat what standard the extensions are for (especially when Std is incorrectly followed by a dot). Accept
Also the title doesn’t need to include a repeat of the project scope. How about Amendment Security extensions (preferred) or Amendment Security extensions including Advanced Encryption Standard (AES) Revised, used the change suggested by
5.2.b — Change IEEE Std to IEEE Std (remove the dot after Std). Accept
5.2.b — The “possible” does not seem to be properly placed in: “It also defines possible methods to simplify the addition of future encryption modes and key lengths.” (Hopefully no standard will define an impossible method.) Is the project really planning to define a set (“methods") of ways to add new modes and keys; or is the possible supposed to mean the project may or may not define a method to simplify adding new keys and modes; or should “possible” simply be deleted? Accept, removed the word “possibly”
Don Sturek (Itron)

6. March 2018
P y Comments from 802.3
Amendment: SECN (Security Next Generation)
CSD
Title — If PAR title is changed per comments, also change on the CSD. Accept
1.2.1,a — Not all that responsive to the question about broad applicability. Isn’t the point that has significant market presence and that addition of better security is demanded for that broad application base, and continued deployment to will require better security? Adding something on that line would make the answer more responsive to the question. Accept, changed the text to read: “IEEE has significant market presence and the addition of better security is demanded for the broad application base and continued deployments.”
1.2.3 — Change IEEE Std to IEEE Std (remove the dot after Std). Accept
1.2.3, last sentence — Should it read: "The SECN extensions will be unique from features in the existing standard which is currently limited to AES-128 encryption or no security." Accept
Don Sturek (Itron)

7. March 2018
P y Comments from 802.1
1. This PAR is being brought forward in advance of calls for proposals, but at the same time introduces a constraint on those proposals. For the reasons described in the following comments it would be better to delay the PAR until there is a better sense of what the final standard should achieve. Revise, provided more specifics in the PAR to better explain the scope
2. Referencing the use of a block cipher (AES-256 or any other) might meet a marketing need but is not technically sufficient as a description of a project constraint, unless all possible modes (allowing the use of a block cipher to encipher data - such as frame contents - in excess of the block size) are to be supported, which is not well expressed by "at a minimum".
If a specific cipher is to be identified as part of the Scope, the Cipher Suite (mode as well as block cipher, if a block cipher such as AES is to be used) needs to be specified.
Revise, focused on AES-256-CCM in the PAR and provided a framework for algorithm agility.  When we set up for algorithm agility need to constrain the range of algorithms (gate to registry process) and provide a way to add new algorithms.
Don Sturek (Itron)

8. March 2018
P y Comments from 802.1
3. Changes to protect against future attacks should not prejudge the nature of or the solution to those attacks. This proposed amendment should ensure that replacement of the specification of one Cipher Suite by another can be accomplished in a modular fashion, without further extensive specification revision. It should also ensure that the Cipher Suite (or Cipher Suites) that might be use by a particular implementation are appropriately identifiable by each of the key management protocols specified in IEEE Std While it is highly desirable to limit the proliferation of Cipher Suites, with a goal of there being a single Cipher Suite in predominant use at any time, transition periods and the need for stability for particular groups of implementations have to be accommodated.
Revise, , specified a way to add new cipher suites.   Don’t need to talk about quantum computing. 
Don Sturek (Itron)

9. March 2018
P y Comments from 802.1
4. An appropriate project description might (a) introduce the appropriate standard flexibility/agility for Cipher Suite use as noted in our comment 3 above, while (b) setting out criteria for inclusion of one or more Cipher Suites for inclusion in this amendment (as opposed to future amendments, in response to new attacks or a general need for more stringent criteria). These criteria should encompass security strength, relative cost (licensing, computational efficiency, memory), hardware and software suitability, and external acceptability. For ease of general understanding these criteria might be stated in terms of existing well-known Cipher Suites and implementation characteristics (e.g. offering a security strength greater than that of AES-128-CCM).
Revise, clarified that a registry will be created and algorithm agility supported via new abbreviated amendments to include additional registry items
5. Real world systems that make use of can also participate in higher layer protocols that also need to be secured. The effect of decisions on total system cost is affected by the degree to which resources (hardware assist,
code) can be shared across the system. This makes it important to be sensitive to, and some extent dependent on, developments outside the scope of What are the other security standards that systems targeted by this PAR will depend upon (e.g. EAP-TLS and its options, IEC 62591, IEC 62374)?
Revise, stated that picking algorithms (AES-256-CCM) which can be used by higher layers provides synergy with requirements for link layer security
Don Sturek (Itron)

10. March 2018
P y Comments from 802.1
6. The point made about automated configuration made in CSD c does not appear to be supported by any activity identified by the PAR scope. Why will automated configuration not apply equally to the use of AES-128 and to the use of AES-256?
Revise, stated that AES-256-CCM will be the new default but AES-128-CCM will be included in the registry
7. This PAR is being brought forward at a time when there is active high quality work on future Cipher Suites. See CAESAR:
is reasonably likely that this competition will complete prior to the completion of the proposed y project, and will result in one or more widely acceptable Cipher Suites with at least one of these offering significant cost advantages for computationally constrained and memory constrained implementations. Insisting on the inclusion of an AES-256 based Cipher Suite in the proposed amendment might then result in confusion as to what should be included in an implementation with resulting increased costs if a superior (in the general application space) is available.
Revise, ensured that the cipher suite agility and registry is flexible enough to add CAESAR or other ciphers
8. As an editorial issue, the title of this PAR is inappropriate.  It appears to be a sentence, being nearly identical to the first sentence of the scope of the project.
It may more appropriate to generalize it as simply " Amendment:  security extensions”
Revise, used the modified project scope description provided by
Don Sturek (Itron)

11. March 2018
WG Motion
WG Motion: request that the PAR and CSD contained in documents and , respectively updated from resolved comments in , be approved by the IEEE WG and that the EC be requested to forward the PAR to NesCom. The working group chair and technical editor are authorized to make additional modifications to the PAR and CSD as needed to reflect EC discussion at its closing meeting.
Moved by Don Sturek (Itron)
Seconded by ()
Yes:
No:
Abstain:
Don Sturek (Itron)