On 12/23/2016 3:24 AM, Eliot Lear wrote:
On 12/22/16 11:36 PM, Michael StJohns wrote:
On 12/22/2016 3:42 AM, Eliot Lear wrote:
Hi,
This working group has been in a state of indecision about this draft
for quite some time and I would like to gain some clarity on the matter.
On the one hand, we have a draft that there seems to be unanimous
agreement would be useful to the lighting people.
Actually, we have a draft that the lighting people unanimously agree
that would be useful to the lighting people. Not quite the same thing.
No, even you have previously conceded that this use case is fine.
Really? Where and when? What I said was that I didn't believe this
draft was even conditionally secure for control systems, and that while
I thought it was a bad idea, I was fine with the lighting folk going off
and publishing it as informational for their own internal use.
And, as I've said before, if this is ONLY applicable to the lighting
people then they should go off and write an Informational "Here's how
we do it" document and not try for an internet standard.
It's not. Lighting is not the only highly constrained case where low
power budget and low latency requirements will make public key
operations expensive. It just happens to be leading the path.
Can you think of even one other case where low cost (not low power -
seriously, it's a light bulb and it's plugged in) and low latency so
constrain the problem that nothing but a symmetric solution will work?
I can't. And I can't remember even a suggestion that there was another
one. Remember that the latency issues here are related to human
perception and to nothing else.
So use case other than lighting is?
On the other hand, we
have some concern that the draft might be misapplied to environments
where PSK/symmetric keys should not be employed.
As Hannes wrote, security is not a black and white matter. We need to
acknowledge that fact. This, to me, seems to boil down to an
applicability statement.
I don't know why people think I'm just going to let things pass
without trying to inject some rigor.
My last question: What is the security requirement for an ACE Group
comm protocol?
The answer should be as it always was: make things better.
In what world is "make things better" a security requirement?
The current
alternative is nothing, which is what happens today, and well beyond
lighting. The current draft provides for use of asymmetric keying for
group admission. Beyond that, the choices are pretty stark: perform an
symmetric operation on every transaction or use a group key.
I'm not sure if you meant "perform an asymmetric operation..." or you
were stating a false dilemma by limiting the choices. The asymmetric
keying for group admission is nothing new, and probably doesn't
materially affect the security of the protocol.
If you've got a content distribution system, then the use of group
symmetric keys is a valid option - mainly because the compromise of an
end device is no worse than the compromise of the group key as you get
access to the content by breaking into an end system. But that's not
what this is.
If you've got a one-to-many control system, then the use of group
symmetric keys is not an option, because the compromise of an end or
actuator device gives you the access to control other end or actuator
devices. There are caveats and mitigations here dealing with key
protection and secure elements (which cost money or power), but the
general case is as stated.
ACE should be working on the general case of the security of a group
control system, and it's pretty clear that - for the general case - only
an asymmetric approach for "signing" the control messages has the
necessary security properties.
My current minimum bid: Compromise of a single device shall not
result in the attacker gaining privileges over the group greater than
those nominally granted to the device being attacked. or less
nuanced: Compromise of a single device shall not result in the
compromise of the entire group.
And here's mine:
The group must be treated as a single device, for purpose of compromise,
barring additional measures being taken at other layers.
Um. No. This requirement is valid if and only if each and every device
in the group has exactly the same privileges with respect to the group.
If I compromise a light switch, I get its privileges to turn on and off
the group. If I compromise a light bulb, why should I get privileges to
turn on and off the group?
I actually described the above as a possibility for say a
collection/flock of drones way back in DICE. But even then I would
suggest that hardware protection of the symmetric key would be necessary
for meaningful security guarantees for any group larger than about 4 or 8.
The advantage
of this over status quo is that today admission is open, and the threat
surface is therefore unconstrained. With this approach the threat
surface is reduced to other infected group members.
I believe that your analysis is flawed. Basically, the cost to attack
any of the entities in the lighting case approaches zero, especially if
you can physically access one. The probability of success of attacking
such entities approaches unity. The security guarantees for this are
therefore roughly equivalent to no security at all and may be worse
than no security at all because the general public will not inquire as
to what "secure" means for any given case. Or put another way, this is
no better than security by obscurity.
There are any number of products that tout security in their ads or
specifications, but when you get under the covers you recoil in horror
at finding just how trivial it would be to penetrate.
I expect going forward that any device or item can be broken into with
some level of effort given physical or network access. What I don't
want to have happen - due to our poor choices - is making the Work
Factor of the group (to break in) identical to the Work Factor of
breaking into a single device and that's what this draft is proposing to
institutionalize in the protocol. We can do better and we should.
Mike
Eliot
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
