Göran Selander
2017-03-23 07:30:15 UTC
Hi Christian,
(continuing the discussion in a new thread)
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.
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.)
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
(continuing the discussion in a new thread)
Judging by your proposal you got the point despite these errors. I’ve
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, itAs an exercise, verify that this construction works even if client and
server change roles. And also with Observe in that case.
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.
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: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.
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 optimizedceil(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.
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
tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/
| ATU68476614
Christian Amsüss | Energy Harvesting Solutions GmbH
tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/
| ATU68476614