Valery Smyslov <smyslov.i...@gmail.com> wrote:
>> Current version of EDHOC is 3-pass to allow traffic data after one round
trip,
>> which reduces latency in many applications.
>> A 4-pass version has also been discussed:
>> https://mailarchive.ietf.org/arch/msg/ace/ZDHYEhvI0PenU6nGrhGlULIz0oQ
>>
>> When EDHOC is used as key exchange for OSCORE, and also in other
settings,
>> EDHOC will commonly run on top of CoAP. For example, in 6tisch the join
>> protocol relies on CoAP proxy functionality. CoAP is defined for reliable
>> transport (RFC 8323) as well as UDP (RFC 7252), the latter handles
>> retransmissions by client and server. An example of using EDHOC with
CoAP is
>> given in appendix D.1:
>> https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-11#appendix-D.1
>>
>> It sounds like we should add some considerations for the setting you
outline.
>> Do you have an example or pointer explaining the specific problem in more
>> detail?
> In the current EDHOC draft the initiators sends the last (third) message
of AKE and then
> immediately starts sending encrypted data (note, that he has almost
> always something to send,
When done over CoAP, the message would be sent with CONfirmable, so it would
be ACK'ed. I would make the first message CONfirmable too.
That makes it much like IKEv2 is, where all messages are ACKed and the initiator
is responsible for all retransmits.
If someone wants to run EDHOC over another transport, then they would need to
take this
into account.
> So, unless you rely on a reliable transport that preserves packets
ordering,
> having odd number of messages significantly complicates implementations.
CoAP is reliable, and it does preserve packet ordering if asked to.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
