[core] Secure CoAP multicast overhead (was: OSCOAP -02: sequence number reuse?)

[Göran Selander <[e-mail]>]

Hi Christian,

(continuing the discussion in a new thread)

On 2017-03-22 16:49, "Christian Amsüss" <[e-mail]>
wrote:

>On Wed, Mar 22, 2017 at 10:17:02AM +0000, Göran Selander wrote:
>> Judging by your proposal you got the point despite these errors. I’ve
>> updated the draft, please check if I got it right:
>>
>> As an exercise, verify that this construction works even if client and
>> server change roles. And also with Observe in that case.
>
>As I read it now, it should work. (Without observe and role reversal, it
>works in my implementation, the rest is pending but requires some more
>streamlining in the API).
>
>Where I do see trouble coming up is when the multicast proposals get
>warmed up again.

They already are :-) See below.

> For then, I can envision at least two solutions[1], so
>I suppose we're good.
>
>Best regards
>Christian
>
>
>[1]: (Diverting this into a footnote so it's on record, even though it's
>not relevant for this thread itself, but might spin off a new one for
>multicast:)
>
>* Approach A: Unless only one node that is allowed to do requests, all
>  responses must bear a sequence number of their own instead of
>  mirroring.
>
>  This adds back the sequence numbers to the message length. (As the
>  multicast responses probably need the KID as well, this just means
>  that the compressed responses take the [partIV, kid, ciphertext] form.

Correct, and this is essentially how it is specified in section 5 of:

https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-01

The only additional message field is a group/context identifier to allow
nodes to be part of multiple groups. (And a countersignature to address
use cases where source authentication is important.)

>
>* Approach B: Allocate not 1 but n "mirror spaces". This would take
>  ceil(log2(n_participants)) bits off the sequence number range, but the
>  responders would then only need to send their KID (sender ID) and the
>  ciphertext.
>
>  (Basically they'd encode the peer number in reverse bit sequence in
>  the partial IV, where 0 is used for sequence numbers the device has
>  dealt itself, 1 is for sequence numbers out of the list of the first
>  partner (or the unicast partner), and 2 etc is for sequence numbers of
>  other people's pools.

Interesting alternative. As it is currently designed, OSCOAP is optimized
for CoAP (RFC7252), which gives a very low overhead [2]. When OSCOAP is
extended to other settings, like e.g. secure multicast with unicast
responses, there are a few additional message fields. But, as you point
out, also in that case it is possible to make further optimisations.

Göran


[2] 
https://datatracker.ietf.org/doc/html/draft-mattsson-core-security-overhead


>
>-- 
>Christian Amsüss                      | Energy Harvesting Solutions GmbH
>founder, system architect             | headquarter:
>mailto:[e-mail]  | Arbeitergasse 15, A-4400 Steyr
>tel:[phone]                | http://www.energyharvesting.at/
>                                      | ATU68476614