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 > _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
