Subject: [Ace] multicast

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Oct 2017 06:01:43 +0000

Hi all,

During the ACE conference call we had a few new participants, namely Stevie, Piotr and Marius, from the lighting consortium Fairhair attending. Great to see new participants "on-board".

Stevie explained that he needs a document that contains a solution using asymmetric and symmetric cryptography, that they intend to use the asymmetric solution whenever there is no low latency requirement (and for unicast communication), and only use the symmetric key approach when the low latency requirements demand it.

Is this a correct summary?

Ciao
Hannes

PS: Stevie also mentioned that he likes draft-tiloca-ace-oscoap-joining-00.txt but not draft-somaraju-ace-multicast<https://tools.ietf.org/html/draft-somaraju-ace-multicast>. This was rather surprising since draft-somaraju-ace-multicast<https://tools.ietf.org/html/draft-somaraju-ace-multicast>was written by the lighting community (in the OpenAIS project) specifically addressing the low latency requirements of that community. Stevie, could you explain?
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: "Beck, Stefan" <[email-masked]>
Date: Thu, 19 Oct 2017 10:56:16 +0000

Hi Hannes,
Thanks for the warm welcome!

See inline my comments...
Stevie

> From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Thursday, October 19, 2017 8:02 AM
> To: [email-masked]
> Subject: [Ace] multicast
> 
> Hi all, 
> 
> During the ACE conference call we had a few new participants, namely
Stevie, 
> Piotr and Marius, from the lighting consortium Fairhair attending. 
> Great to see new participants "on-board". 
> 
> Stevie explained that he needs a document that contains a solution using 
> asymmetric and symmetric cryptography, that they intend to use the
> asymmetric solution whenever there is no low latency requirement 
> (and for unicast communication), and only use the symmetric key approach 
> when the low latency requirements demand it. 
> 
[Stevie] Well, slightly different. First, my interest is to separate unicast
from multicast
communication completely. (Use of DTLS, for all unicast communication)
For multicast, my focus is on using asymmetric encryption for
authentication & integrity, and using symmetric encryption for
confidentiality.
I see high chances for reasonable options to achieve this with the given
drafts [1] / [2] / [3],
even supporting the "low-latency" requirements we need, also considering the
main ideas from [4].
Note this is still mostly a "gut feeling" today - as I am still not familiar
enough with all potentially relevant details.
Let me (better: us) give some more days to elaborate on that before starting
broader discussion...

[1] https://tools.ietf.org/html/draft-ietf-ace-dtls-authorize-01
[2] https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-03
[3] https://tools.ietf.org/html/draft-tiloca-ace-oscoap-joining-00

[4] https://tools.ietf.org/html/draft-somaraju-ace-multicast-02 

> 
> Ciao
> Hannes
> 
> PS: Stevie also mentioned that he likes
draft-tiloca-ace-oscoap-joining-00.txt 
> but not draft-somaraju-ace-multicast. This was rather surprising since 
> draft-somaraju-ace-multicastwas written by the lighting community (in the 
> OpenAIS project) specifically addressing the low latency requirements of
that 
> community. Stevie, could you explain? 
[Stevie] I did (and still do) support draft-somaraju-ace-multicast, see also
my email to the
list in March [5].
I just think that there should not be two competing drafts, where there is
chance to combine them (especially when there's a chance to improve the
security aspects
within that common approach). I cannot speak for the OpenAIS project, but at
least in
the Fairhair Alliance there is currently common sense to focus on one
approach (i.e. not
attempting to "revive" draft-somaraju-ace-multicast)

[5] https://mailarchive.ietf.org/arch/search/?email_list=ace&q=stevie

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Oct 2017 12:51:44 +0000

Hi Stefan,

I am trying to understand your ideas.

~snip ~

In your view, you are sending a multicast message that will contain a digital signature and is also encrypted using symmetric key crypto?

Is this correct?

Ciao
Hannes

---

From: "Beck, Stefan" <[email-masked]>
Date: Thu, 19 Oct 2017 13:20:33 +0000

Yes, correct.

Stevie

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Thursday, October 19, 2017 2:52 PM
> To: Beck, Stefan <[email-masked]>; [email-masked]
> Subject: RE: multicast
> 
> Hi Stefan,
> 
confidentiality.
> 
> In your view, you are sending a multicast message that will contain a
digital
> signature and is also encrypted using symmetric key crypto?
> 
> Is this correct?
> 
> Ciao
> Hannes
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
recipient,
> please notify the sender immediately and do not disclose the contents to
any
> other person, use it for any purpose, or store or copy the information in
any
> medium. Thank you.

---

From: Derek Atkins <[email-masked]>
Date: Thu, 19 Oct 2017 09:51:10 -0400

Hi,

"Beck, Stefan" <[email-masked]> writes:

[snip]
> even supporting the "low-latency" requirements we need, also considering the
[snip]

Could you provide some more concrete numbers for your definition of
"low-latency" requirements?

Thanks,

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Oct 2017 14:59:16 +0000

I suspect the idea is the following:

1) First, you would decrypt the packet and validate the mac (assuming that it is an AEAD cipher)
2) You execute the operation to meet the latency requirements.
3) Then, you can take time to verify the digital signature (outside the latency requirements)

Is that the idea?

-----Original Message-----
From: Beck, Stefan [mailto:[email-masked]]
Sent: 19 October 2017 15:21
To: Hannes Tschofenig; [email-masked]
Subject: RE: multicast

Yes, correct.

Stevie

confidentiality.
digital
recipient,
any
any

---

From: "Beck, Stefan" <[email-masked]>
Date: Thu, 19 Oct 2017 15:43:07 +0000

Hi Derek,

The requirement roughly is:
Assume a few light switches as multicasters and many luminaires as listeners
- turning lights on / off via multicast
The end-2-end processing (multicaster to encrypt&sign the message, the
network to transmit the message, and the listeners to validate&decrypt the
message) should not exceed ~200 ms.

Stevie

> From: Derek Atkins [mailto:[email-masked]]
> Sent: Thursday, October 19, 2017 3:51 PM
> To: Beck, Stefan <[email-masked]>
> Cc: Hannes Tschofenig <[email-masked]>; [email-masked]
> Subject: Re: [Ace] multicast
> 
> Hi,
> 
> Could you provide some more concrete numbers for your definition of "low-
> latency" requirements?
> 
> Thanks,
> 
> -derek
> 
> --
>        [email-masked]
> https://emea01.safelinks.protection.outlook.com/?url=www.ihtfp.com&data=0
> 2%7C01%7C%7C015cc4c4b8da4534720808d516f87712%7Cec1ca250c2344d56a
> 76b7dfb9eee0c46%7C0%7C0%7C636440178780250813&sdata=C3WzL%2FAdUd
> wWhHz3aaAg0V4TZgBCWIkYqqH%2FF3tMjDw%3D&reserved=0

---

From: Michael StJohns <[email-masked]>
Date: Thu, 19 Oct 2017 12:37:59 -0400

> 3) Then, you can take time to verify the digital signature (outside the latency requirements)

It can't possibly be.   What do you do if the digital signature doesn't 
verify?  Reverse the operation?   Flicker the lights?  Go back to the 
original levels?  Flash "OOPS" in morse code?

You need to verify the signature in advance of doing an operation 
authenticated and authorized by that signature....

Mike

---

From: "Beck, Stefan" <[email-masked]>
Date: Thu, 19 Oct 2017 19:59:28 +0000

I totally agree with Mike.
BTW, Hannes, this was "part a." of Idea #1 - the only added value I've seen 
was that the device
could raise an alarm - so there is awareness of an attack at least "after the 
fact". However,
it adds complexity to the constrained device - and alternatively, one could 
just use one
separate listener to the multicast group, that just does this job. It's 
multicast, so a single listener
is sufficient to handle such type of alarms.

"Part b." would even be more important to me: the multicasters (not the 
listeners) are the constrained devices
that are unable to sign their messages in time. (Think of battery-powered low 
cost wall switches).
In that case they would need to pre-compile their multicast message (or set of 
messages-
eg. one or more for turn off / turn on / dim level x events), so they just 
fire them when the event happens.
Again, this adds a lot of complexity, and may even not be feasible at all (in 
case you have timing constraints in the crypto operations)

Stevie

> From: Ace [mailto:[email-masked]] On Behalf Of Michael StJohns
> Sent: Thursday, October 19, 2017 6:38 PM
> To: [email-masked]
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Face&data=02%7C01%7C%7Cd6a2b032140a4
> 8082e1908d5170fc763%7Cec1ca250c2344d56a76b7dfb9eee0c46%7C0%7C0%7
> C636440278895347864&sdata=fpqgRpYFEvJxQUc4l2zlHM%2BUc7VaYLcp217q3
> 2kHgLQ%3D&reserved=0

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Oct 2017 20:02:32 +0000

So, what are you suggesting?

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Beck, Stefan
Sent: 19 October 2017 21:59
To: [email-masked]
Subject: Re: [Ace] multicast

I totally agree with Mike.
BTW, Hannes, this was "part a." of Idea #1 - the only added value I've seen was that the device could raise an alarm - so there is awareness of an attack at least "after the fact". However, it adds complexity to the constrained device - and alternatively, one could just use one separate listener to the multicast group, that just does this job. It's multicast, so a single listener is sufficient to handle such type of alarms.

"Part b." would even be more important to me: the multicasters (not the
listeners) are the constrained devices
that are unable to sign their messages in time. (Think of battery-powered low cost wall switches).
In that case they would need to pre-compile their multicast message (or set of
messages-
eg. one or more for turn off / turn on / dim level x events), so they just fire them when the event happens.
Again, this adds a lot of complexity, and may even not be feasible at all (in case you have timing constraints in the crypto operations)

Stevie

---

From: "Beck, Stefan" <[email-masked]>
Date: Thu, 19 Oct 2017 20:15:07 +0000

As mentioned in yesterday's call: give me/us some more time to work it out 
more precisely first.
We have a meeting on Monday to verify and consolidate the current proposal - I 
believe
I shouldn't speak up before that.
(And I don't want to risk a shit-storm in case I get some parts wrong or 
immature; most of
the people on this list are much smarter than me regarding these topics ;-)

Stevie

> Sent: Thursday, October 19, 2017 10:03 PM
> Subject: RE: [Ace] multicast
>
> was
> that the device could raise an alarm - so there is awareness of an attack at 
> least
> "after the fact". However, it adds complexity to the constrained device - 
> and
> alternatively, one could just use one separate listener to the multicast 
> group,
> that just does this job. It's multicast, so a single listener is sufficient 
> to handle
> such type of alarms.
>
> Again, this adds a lot of complexity, and may even not be feasible at all 
> (in case
> you have timing constraints in the crypto operations)
>
> Stevie
>
> please notify the sender immediately and do not disclose the contents to any

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Oct 2017 20:16:17 +0000

No problem. Take your time.

Ciao
Hannes

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Beck, Stefan
Sent: 19 October 2017 22:15
To: [email-masked]
Subject: Re: [Ace] multicast

As mentioned in yesterday's call: give me/us some more time to work it out more precisely first.
We have a meeting on Monday to verify and consolidate the current proposal - I believe I shouldn't speak up before that.
(And I don't want to risk a shit-storm in case I get some parts wrong or immature; most of the people on this list are much smarter than me regarding these topics ;-)

Stevie

> BTW, Hannes, this was "part a." of Idea #1 - the only added value I've
> seen was that the device could raise an alarm - so there is awareness
> of an attack at least "after the fact". However, it adds complexity to
> the constrained device - and alternatively, one could just use one
> separate listener to the multicast group, that just does this job.
> It's multicast, so a single listener is sufficient to handle such type
> of alarms.
>
> listeners) are the constrained devices that are unable to sign their
> messages in time. (Think of battery-powered low cost wall switches).
> Again, this adds a lot of complexity, and may even not be feasible at
> all (in case you have timing constraints in the crypto operations)
>
> Stevie
>
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw
> > ww
> > .i
> >
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.

---

From: Derek Atkins <[email-masked]>
Date: Fri, 20 Oct 2017 09:30:00 -0400

Hi Stevie,

> message) should not exceed ~200 ms.

Thanks, that's a good start.  A few follow-on questions:

What's the realistic transmission speed you can expect?  100kbps?
1mbps?  10kbps?

What's the realistic processing power / platform of the switches and
liminaires?  (base processor / clock speed)

I'm asking because I do have access to a lightweight signature scheme
where we can validate a 128-bit-security-level signature on an ARM
Cortex M3 in 5.7ms (@48MHz).

I'll also note that in this scenario encryption is a "nice to have" but
does not seem "necessary", whereas integrity protection and source
authentication is definitely necessary.  I.e., if it's a trade-off
between encryption and authentication/integrity I would choose
authentication/integrity.

Just my $0.02.

-derek

---

From: Michael Richardson <[email-masked]>
Date: Fri, 20 Oct 2017 11:11:25 -0400

> digital signature and is also encrypted using symmetric key crypto?

Is the symmetric key for privacy in addition to whatever L2 security there
might be?  Is it in fact the L2 security?  Or does it replace L2 security
with L3 (L7?) security?

Is the target network 15.4 (like), or 802.11-like?  If 802.11-like is it
managed or adhoc/mesh?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-