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

["Valery Smyslov" <[e-mail]>]

Hi Göran,

> 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,
because it is he who initiates secure connection with responder). If this third
message is lost or the packets are reordered, then the responder will start receiving
encrypted data from the peer he hasn't authenticated yet. The responder in this
case has two options - either discard incoming encrypted data or buffer it in hope
that the last EDHOC message will come shortly. Both alternatives are bad - 
either it impacts application protocol or opens surface for DoS attack.
Note, that from the initiator's point of view everything is fine, the protocol
has completed successfully, so in general the problem cannot be solved by
sending retransmissions by initiator, instead, the responder must become
an active retransmitter in this case and re-send the second message to nudge
the initiator to re-send the third. This was discussed in the ipsecme WG when
IKEv2 was being designed (back to 2003-2005).

So, unless you rely on a reliable transport that preserves packets ordering,
having odd number of messages significantly complicates implementations.

Note also, that lacking the fourth message there is no way for the responder
to report any authentication error back to the initiator...

Regards,
Valery.

> Thanks,
> Göran
>