[held for document revision?] EDHOC option can make sense with EAD_4 as well

[chrysn]

There are scenarios in which a Message 4 is needed for more than just key confirmation. (An example of this are upcoming relaxations in ACE EDHOC that'd allow a token in message 2 or message 4, see ace-wg/ace-edhoc-oscore-profile#8). When using reverse flow (enabled for ACE EDHOC in the same issue), that message is sent as a request.

By the text of this document, this scenario can not use the EDHOC option – flow would be:

• empty POST / message 1
• message 2 / message 3
• message 4 / empty response
• OSCORE application request / application response

Other than that this document does not allow it, there is nothing that precludes the use of the EDHOC option with a message 4. Technically, it'll just work, because like message 3, message 4 is self-delimited by being exactly one byte string:

• empty POST / message 1
• message 2 / message 3
• OSOCORE application request in outer EDHOC option / application response

It's probably too late in this document to just say that it's also allowed. If there are real-world use cases (token in message 4 may be rather niche; possibly other future EADs go into EAD4), a small document could Update this one and just say that message 4 can also use the same mechanism.

Possible action item here: Some wording could be made more precise to not state that it is not possible, merely that it is not give the optimal-round-trips property (CoAP forward flow is always better because it does not waste an empty POST).

No tag shenanigans: There are possible optimizations w/rt message size (when instead of packing full integrity protected EAD4 into the inner CoAP request, saving the double AEAD tag), but they reach very far across the EDHOC and OSCORE layers, and are probably not worth the hassle. Note that similar optimizations could have been done in early versions of this document – back then, one version considered was to not use OSCORE for the first application request, but to pack the data that would go into an OSCORE plaintext into an EAD3, and the response into an EAD4. That would have brought similar savings to message-3-in-a-request, but at similarly bad or even worse layering violations.

(This is coming out of discussion with @gselander and @marco-tiloca-sics earlier today)