Hi Markus -
I needed to think about how to reply to this specifically and explain
why its still a bad idea to try and scale things. See below.
On 7/27/2016 8:34 AM, Grunwald, Markus wrote:
Hello,
sorry to break the threading by not replying directly to a post, but
until now I have only been reading the list passively. So I have no
mail to reply to…
I followed your discussion regarding group multicast and how to
encrypt them. I see the problem, but I think one single approach to
solve it either way will not be enough:
-The 200ms barrier for lighting products is quite fix. If we build
products with a reaction time that is too long, nobody is going to use it.
-On the other hand, I am scared of IoT products that could have bigger
latency, but still use a somewhat weaker crypto. I’m thinking of
Fire/Smokedetectors at big airports or the like. Even toggling all
lights of an airport in a one-second rhythm could cause huge problems.
-So we need both, but can hardly have it.
For me, this leads to multiple security levels:
1)Basic security: fast response, low cost with lower security: use
symmetric keys. Use this where the risk is low.
2)High security, low cost: Allow slow(er) response times, because of
the ECC calculations. Kind of a compromise…
3)High security, higher cost: add some crypto hardware. For high risk
environments with low latency
Analogies are sometimes suspect and are never exact matches, but let me
try one:
You want to build the equivalent of three different types of motor
powered vehicles: a go-cart, a family car and a high end luxury vehicle.
You obviously don't want to put in all the safety stuff into the
go-cart. It's cheap, it's meant for fun, and it won't be driving on the
roads, so why bother and besides which it would hurt your bottom line?
In the real world, there are lots of things that keep a go-kart off of
the highway - two of which are fear of death (both the go-cart driver's
and everyone else) and police and laws (e.g. a go-cart is not "street
legal") acting as enforcement mechanisms.
My question - what enforcement mechanism do you propose to keep your
cheap, unsafe at speed, go-cart symmetric key multicast system off the
rest of the information superhighway? How do you propose to keep
someone from strapping on a physical access control management system to
the back of your go-cart and taking it for a ride in the real world?
I think go-carts are fun, but I would never propose that they be allowed
on the highway, or for that matter any public road.
I don’t think that we will be able to cover the whole range of
requirements with one single approach. Implementing the lowest level
would be relatively easy for first concepts.
You really mean simple, and simple != easy. Symmetric key multicast is
a simple concept. It is not *easy* to get right, and it is not *easy*
to mitigate the threats from that approach. The threats are not
necessarily limited to the original field of use (lighting...).
Later, Mike
ps - way back when - maybe 1990 - I was trying to debug why a telnet
connections through a terminal server that one of the other parts of the
organization had bought would silently stop working. It took me a while
to figure it out, but it would stop working if any packet got dropped.
It turns out that the terminal server did not implement TCP
retransmits. When we asked the vendor about it they said that they'd
never seen a drop so they didn't see any need to implement it. When
questioned further, it turns out they did all their implementation work
on a single segment of ethernet and really never saw any dropping
whereas the real-world network had a router that occasionally dropped
packets it couldn't queue. The point of this story is that you as a
vendor may not necessarily be able to control what me as the customer
does with your product. You may think its safe given specific
constraints, but imposing those constraints on an end user is - hard?
Impossible?
Best regards,
Markus Grunwald
Development Engineer
OSRAM GmbH
DS D LMS-COM DE-1
Parkring 33
85748 Garching, Deutschland
Tel. +49 89 6213-3678
mailto:[email protected]
www.osram.com
*Bitte prüfen Sie der Umwelt zuliebe, ob der Ausdruck dieser Mail
erforderlich ist!
*
OSRAM GmbH: Vorsitzender des Aufsichtsrates: Peter Bauer;
Geschäftsführung: Dr. Olaf Berlien (Vorsitzender), Dr. Stefan Kampmann;
Sitz der Gesellschaft: München; Registergericht: München, HRB 201526;
WEEE-Reg.-Nr. DE 71568000
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
