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.
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.
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?
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.
I asked the above question a month ago in response to Hannes' email and
received no answer. None.
As far as I can glean from the discussion (this one and the 2 year one
in DTLS), the current answer from the lighting folk to "What is the
security requirement" is "we don't really care as long it is weak enough
that we don't have to pay for hardware or endure latency for validation
so we can use this fundamentally insecure symmetric key group system".
I apologize if that's unfair, but I literally haven't been able to find
ANY indication that there's any consideration in selecting the
"security" solution than this.
And as far as I can tell, that means that their security requirement is
the empty set - which is sort of an appropriate name for security theater.
Can ANYONE provide me with a parseable and non-empty security
requirement for symmetric key group communications?
On the matter of status, it is not appropriate to release this as an
experiment. People want to code, release that code and see their
customers use that code. This is precisely what a proposed standard is for.
For an "ACE Group comm" protocol, it has to be generally applicable to
the ACE space, and not just this this tiny hardware and cost constrained
corner. An Informational RFC by the lighting folk provided as whole
cloth is the appropriate approach - not an internet standard in any way
shape or form.
I would like to see this draft adopted by the working group, an
appropriate applicability statement added, and see it shipped.
I would like a security group to actually produce secure protocols.
I'm not even sure this approach is applicable to the lighting scenario
in any meaningful way.
Mike
Eliot
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
