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

> -----Original Message-----
> From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Michael StJohns
> Sent: Thursday, July 21, 2016 3:05 PM
> To: ace@ietf.org
> Subject: Re: [Ace] Adoption of Low Latency Group Communication Security
> Work in ACE
> 
> On 7/21/2016 5:26 AM, Carsten Bormann wrote:
> > Michael Richardson wrote:
> >> Why will ACE succeed when DICE failed?
> > Because DICE tried to hack something into TLS.  That had no support.
> 
> Actually, that's not the complete story.  It was one of the things that finally killed
> this off (e.g. DICE was supposed to make a profile of DTLS for constrained
> devices, BUT DTLS didn't already support multicast, so its difficult to profile it
> in...; we have to come up with message formats for a DTLS extension)
> 
> It wasn't the only thing.  Again, there's a very long record of why this was a bad
> idea in DICE.  It's trivially easy to map each and every one of those arguments to
> why the equivalent thing in ACE is bad.
> 
> >
> >> Does ACE now have some knowledge or mechanism that DICE couldn't have
> created
> >> because it was out of scope?
> > ACE has COSE.
> 
> *sigh* If this had any application to the stated lighting problem, then
> sending a COSE message with a public key signed payload to trigger state
> changes would be the solution, not a symmetric group multicast key.
> 
> E.g. use section 4 of the
> https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ document.  Do NOT
> use any of the symmetric key sections.
> 
>   I've said similar things before, but there continues to be this belief
> from certain folk that its too expensive to do public key cryptography
> for lightbulbs.
> 
> So to be clear - yes COSE is useful.  No, it does not actually do
> anything to fix the problem of symmetric key group communications UNLESS
> you stick to the public key sections.

I completely agree with this.  The problem is not how the messages are distributed and how the protection is done on the message.  The problem is that the authentication of the message is being done with a value which cannot be assigned to a single command generation entity and thus anybody with the key can masquerade as a command generation entity.

Jim

> 
> Later, Mike
> 
> 
> >
> > Grüße, Carsten
> >
> > _______________________________________________
> > Ace mailing list
> > Ace@ietf.org
> > https://www.ietf.org/mailman/listinfo/ace
> 
> 
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace