security-comments-on-802-15-4y-secn-par-0318-v02.txt

802.1 comments on the proposed 802-15-4y PAR and CSD
----------------------------------------------------

These comments are on:
mentor.ieee.org/802.15/dcn/18/15-18-0037-03-secn-draft-par-for-4y.pdf
mentor.ieee.org/802.15/dcn/18/15-18-0040-04-secn-draft-csd-for-4y.docx

they concern the "Scope of the project" and the "Need for the project" (PAR form
5.2.b and 5.5). There are also issues regarding related work by other
organizations which the simple answer to 7.1 (standards or projects with similar
scope) fails to illuminate. Use of (a) new cipher suite(s) will also require some 
registration activity, so 6.1.b should be checked and explained.

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.

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.

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 802.15.9. 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.

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).

5. Real world systems that make use of 802.15 can also participate in higher
layer protocols that also need to be secured. The effect of 802.15 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 802.15. 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)?

6. The point made about automated configuration made in CSD 1.2.5.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?

7. This PAR is being brought forward at a time when there is active high quality
work on future Cipher Suites. See CAESAR:
https://competitions.cr.yp.to/caesar.html It is reasonably likely that this
competition will complete prior to the completion of the proposed 802.15.4y
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 802.15 application space) is
available.