Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

[Michael Richardson <[e-mail]>]

Valery Smyslov <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-