Original text:
Pass EAD_1 to the security application. <del> If any processing step fails, the Responder SHOULD send an EDHOC error message back, formatted as defined in error, and the session MUST be discontinued.  Sending error messages is essential for debugging but MAY be skipped due to, for example, denial-of-service reasons, see dos.  If an error message is sent, the session MUST be </del>  discontinued. 5.3. cipher suite.  The verification process depends on the method, see asym-msg2-proc. <del> If any processing step fails, the Initiator SHOULD send an EDHOC error message back, formatted as defined in error.  Sending error messages is essential for debugging but MAY be skipped if, for example, a session cannot be found or due to denial-of-service reasons, see dos.  If an error message is sent, the session MUST be </del>  discontinued. 5.4. application.  The application can now derive application keys using the EDHOC-Exporter interface. <del> If any processing step fails, the Responder SHOULD send an EDHOC error message back, formatted as defined in error.  Sending error messages is essential for debugging but MAY be skipped if, for example, a session cannot be found or due to denial-of-service reasons, see dos.  If an error message is sent, the session MUST be </del>  discontinued. After verifying message_3, the Responder is assured that the Pass EAD_4 to the security application. <del> If any processing step fails, the Responder SHOULD send an EDHOC error message back, formatted as defined in error.  Sending error messages is essential for debugging but MAY be skipped if, for example, a session cannot be found or due to denial-of-service reasons, see dos.  If an error message is sent, the session MUST be </del>  discontinued. 6. processing associated to the currently defined error codes. Additional error codes may be registered, see error-code-reg.  An EDHOC error message can be sent by either endpoint as a reply to any non-error EDHOC message.  How errors at the EDHOC layer are transported depends on lower layers, which need to enable error messages to be sent and processed as intended. <del> Errors in EDHOC are fatal.  After sending an error message, the sender MUST discontinue the protocol.  The receiver SHOULD treat an error message as an indication that the other party likely has discontinued the protocol.  But as the error message is not authenticated, a received error message might also have been sent by an attacker and the receiver MAY therefore try to continue the protocol. </del> error SHALL be a CBOR Sequence (see CBOR) as defined below where:

Reviewer comments:
I think this is ready to merge. This addresses Marcos and Seans comments. Remaining discussions should be handled by separate PRs.
From Marco's review: [Section 5.2.3] "If an error message is sent, the session MUST be discontinued." Is this sentence actually required? Regardless sending an error message or not, the session is discontinued if any processing step fails, which is the reason for possibly sending an error message. Or are there situations where an error message is sent even if no processing step fails?
This sentence does not talk about failed processing, it is a general implication stating the necessity of discontinuing the session if an error message is sent (for whatever reason), in contrast to the converse statement in the preceding sentence which states that there is no necessity of sending an error message if the session is discontinued. But it is not explained why you would send an error unless processing has failed. Do we have any example?
I don't see the problem here at all. In general in security protocols there is no connection between some processing step failing, sending an alert, and terminationg the connection. Error => processing fails is not true. It is not defined when an error is sent. Close?
When to send an error is left for the implementation. Does that need to explained better?
Related comment from Sean Let's go over and make sure the document answer When is the protocol discontinued? When is an error sent? How does the other party get information about discontinue and the type of error? My understanding Up to the implementation/application when to discontinue the protocol. My feeling is that this is broader than "processing step fails" When the protocol is discontinued, an error MUST be sent, expect if that cannot be done due to DoS. The error tels the other party that the protocol has been discontinued and why it has been discontinued. A party receiving an error knows that the other party discontinues or that an attacker sent the error. In DoS situation the other party gets no information.
I will make a suggested PR for this in the upcoming weeks.
I made a PR to try to address the two comments from Marco and Sean which where quite different but both involve error. As in HTTP and CoAP the intention is that error can be both "client errors" and "server errors". I removed duplicate text from the processing sections and expanded the text in the error section. The PR likely needs some further update but is hopefully a good start for discussion.
EDHOC is not following the standard client error server error design of HTTP and CoAP. Is this intentional? This is the highest level grouping in HTTP and CoAP. As far as I can remember that was not even discussed. Instead of 1 Unspecified Should we not have something like 1 Unspecified Initiator error 2 Unspecified Responder error or 1 Unspecified Sender error 2 Unspecified Reciever error Also is "Unspecified" a good name? The intention is that it is specified in the tstr.
URL While working on this I noticed than one cause for Marcos comment might be that EDHOC only talkes about what HTTP and CoAP calls "client error", i.e., there was something wrong in the received message. HTTP and CoAP defines errrors into two classes "client error" (there is something wrong with you) and "server error" (there is something wrong with me). EDHOC does currently not follow this design and only has a single error 1 Unspecified Should EDHOC instead have have something like? 1 Unspecified Initiator error 2 Unspecified Responder error or 1 Unspecified Sender error 2 Unspecified Reciever error The choice would likely be whatever is easiest for an implementation. I think we should discuss this. This type of high level classes was not discussed before. We only discussed what kind of detailed errors we should standardized and agreed on none. Also is "Unspecified" a good name? The intention is that it is specified in the tstr.
Marco wrote: URL I think it's good to have something like in your second proposal and without "Unspecified" (as you say, the error is specified in the text string), that is: 1 Sender error 2 Receiver error Without bothering about which among client and server exactly has the Initiator or Responder role in the EDHOC session, the above can be read as: 1 --> "something wrong done by the sender of the message that resulted in this error message" 2 --> "something locally wrong happened at the receiver of the message that resulted in this error message" The mapping with high-level classes from CoAP/HTTP would be limited to responses only, and for CoAP it was basically sketched in Appendix A.3.1: "In particular, it is RECOMMENDED that such error responses have response code either 4.00 (Bad Request) in case of client error (e.g., due to a malformed EDHOC message), or 5.00 (Internal Server Error) in case of server error (e.g., due to failure in deriving EDHOC key material)." This can be expanded to highlight the use of 4.00 responses for ERRCODE 1 (Sender error) and the use of 5.00 responses for ERRCODE 2 (Receiver error).
URL Or would the right choice be to differentiate between errors where the message might be retried and errors where the message may be retried later? 1 Do not automatically retry error 2 May retry later error Most be not client errors should not be retried while most but not all server errors might be retried. Carsten had the opinion that different EDHOC errors should lead to different automatic processing. But I think nothing like the above was ever discussed.
I can't even understand the sentence. These are passive constructions, so I don't know who is acting on the fact that "an error message was sent" (and how that is detected), and I don't know who is acting when performing the mandate "the protocol is discontinued". (I hope that doesn't mean that we need a new standard because the old EDHOC was discontinued. Is this about the protocol run?) Sorry to be pedantic, but I really don't know what this all means.
The current plan is to merge the current PR which addresses Marco's and Sean's review comments. Additional things has be discussed more and handles with other PRs More EDHOC errors (client, server) or (retry, do not retry) or (unsuported X) Use of CoAP error codes, current recommendation is to use 4.00 and 5.00 and always use diagnistic payload. Seemed during the design meeting that implementatins do other stuff, should discuss and maybe update specification. Any new error with negotiation should probably not be done. To do that in a safe way would require significant changes. An implementation could assign ciphersuite1+application profile1 and ciphersuite+application profile2 to the private ciphersuite numbers to get secure negotiation of application profiles. Maybe that should be discussed.
Apart from the error code / progress hints as mentioned in the previous comment, we have now resolved the remaining comments from Marco and Sean of this issue in PR (which is now merged). NAME NAME - let us know if you disagree with the resolution.
Looks good to me. Hi John, I think it's good to have something like in your second proposal and without "Unspecified" (as you say, the error is specified in the text string), that is: 1 Sender error 2 Receiver error Without bothering about which among client and server exactly has the Initiator or Responder role in the EDHOC session, the above can be read as: 1 --> "something wrong done by the sender of the message that resulted in this error message" 2 --> "something locally wrong happened at the receiver of the message that resulted in this error message" The mapping with high-level classes from CoAP/HTTP would be limited to responses only, and for CoAP it was basically sketched in Appendix A.3.1: "In particular, it is RECOMMENDED that such error responses have response code either 4.00 (Bad Request) in case of client error (e.g., due to a malformed EDHOC message), or 5.00 (Internal Server Error) in case of server error (e.g., due to failure in deriving EDHOC key material)." This can be expanded to highlight the use of 4.00 responses for ERRCODE 1 (Sender error) and the use of 5.00 responses for ERRCODE 2 (Receiver error). Best, /Marco Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden URL Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistagången 16 SE-164 40 Kista (Sweden)

Hi, Issue was opened based on two different review comments from Marco and Sean on different aspects of error messages. I have tried to address Marco's and Sean's comments in PR URL While working on this I noticed than one cause for Marcos comment might be that EDHOC only talkes about what HTTP and CoAP calls "client error", i.e., there was something wrong in the received message. HTTP and CoAP defines errrors into two classes "client error" (there is something wrong with you) and "server error" (there is something wrong with me). EDHOC does currently not follow this design and only has a single error 1 Unspecified Should EDHOC instead have have something like? 1 Unspecified Initiator error 2 Unspecified Responder error or 1 Unspecified Sender error 2 Unspecified Reciever error The choice would likely be whatever is easiest for an implementation. I think we should discuss this. This type of high level classes was not discussed before. We only discussed what kind of detailed errors we should standardized and agreed on none. Also is "Unspecified" a good name? The intention is that it is specified in the tstr. Cheers, John

Revised text:
Pass EAD_1 to the security application.  <ins> If any processing step fails, the Responder MUST send an EDHOC error message back, formatted as defined in error, and the session MUST be </ins> discontinued. 5.3. cipher suite.  The verification process depends on the method, see asym-msg2-proc.  <ins> If any processing step fails, the Responder MUST send an EDHOC error message back, formatted as defined in error, and the session MUST be </ins> discontinued. 5.4. application.  The application can now derive application keys using the EDHOC-Exporter interface.  <ins> If any processing step fails, the Responder MUST send an EDHOC error message back, formatted as defined in error, and the session MUST be </ins> discontinued. After verifying message_3, the Responder is assured that the Pass EAD_4 to the security application.  <ins> If any processing step fails, the Responder MUST send an EDHOC error message back, formatted as defined in error, and the session MUST be </ins> discontinued. 6. processing associated to the currently defined error codes. Additional error codes may be registered, see error-code-reg. <ins> There are many kinds of errors that can occur during EDHOC processing.  As in CoAP, an error can be triggered by errors in the received message or internal errors in the recieving endpoint. Except for processing and formatting errors, it is up to the implementation when to send an error message.  Sending error messages is essential for debugging but MAY be skipped if, for example, a session cannot be found or due to denial-of-service reasons, see dos. Errors messages in EDHOC are always fatal.  After sending an error message, the sender MUST discontinue the protocol.  The receiver SHOULD treat an error message as an indication that the other party likely has discontinued the protocol.  But as the error message is not authenticated, a received error message might also have been sent by an attacker and the receiver MAY therefore try to continue the protocol. </ins> An EDHOC error message can be sent by either endpoint as a reply to any non-error EDHOC message.  How errors at the EDHOC layer are transported depends on lower layers, which need to enable error messages to be sent and processed as intended.  error SHALL be a CBOR Sequence (see CBOR) as defined below where: