Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

[Michael StJohns <[e-mail]>]

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. [phone]
> mailto:[e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace