Subject: [Ace] draft-somaraju-ace-multicast

From: Jim Schaad <[email-masked]>
Date: Mon, 9 Jan 2017 20:36:38 -0800

Why restriction on reading messages?  It is not like an external observer is
not going to be able to see the lights go on or off.

I am not sure what you mean by synchronous manner.  Does this mean that the
light needs to change state between the command and the response message?
(As opposed to an asynchronous manner.)  Or do you mean in a synchronized
manner where everything happens at a given time relative to the command
(which could be all at the same time).
 
The solution in section 4 does not seem to meet the following requirement
"Only authorized members of the application group must be able to read and
process messages."

The statement is made that AT-R tokens with references are more efficient
from a bandwidth point of view.  Does this mean that there is going to be a
recommendation that these be provided prior to the first command so that all
n devices dereferencing the pointer will not kill the bandwidth?

This document needs to have a solution for dealing with nonce space
allocation for the cases where more than one sender is going be able to use
the same key.  This is going to be part of the problems with replay
detection as well as security considerations.

Should the algorithms be using high water detection of sequence numbers
rather than the case of not yet used?  Or is that an application specific
type thing?

How does section 5.2 Token Verification reconcile with the idea of doing
references in AT-R tokens?

In section 6.3, if a device has multiple security domains, why could they
not come from multiple KDCs?

The term low latency needs to be much more clearly defined about what it
means in this context.  In a manufacturing facility, I might have a tighter
latency requirement for communicating commands to valves that I would on
dealing with lights that might take a while to come on anyway.  Does that
mean that you feel that this would be an ideal solution for such an
environment?  The same thing might easily be said for emergency alarms.  I
want all of them to come on and come on fast in the event of an emergency.
A better description of what is meant by low-latency is clearly needed.

I do not think that the current security requirements is sufficiently
strident to reflect both the threat of breakage, cross-breakage and
restrictions on where it should be used to pass muster.

Jim