Draft: draft-ietf-lake-edhoc

Commentary: I think this is ready to merge . This addresses  and Seans comments . Remaining discussions should be handled by separate PRs . 
 From  '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 do n'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 can not 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  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 . 
 While working on this I noticed than one cause for  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 . 
  wrote : 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  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 ) . 
 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 .  had the opinion that different EDHOC errors should lead to different automatic processing . But I think nothing like the above was ever discussed . 
 I ca n't even understand the sentence . These are passive constructions , so I do n't know who is acting on the fact that " an error message was sent " ( and how that is detected ) , and I do n't know who is acting when performing the mandate " the protocol is discontinued " . ( I hope that does n'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 do n't know what this all means . 
 The current plan is to merge the current PR which addresses  '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  and Sean of this issue in PR ( which is now merged ) . - let us know if you disagree with the resolution . 
 Looks good to me .
Mailing list commentary: Hi , 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 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 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
Hi , Issue # 208 was opened based on two different review comments from and Sean on different aspects of error messages . I have tried to address 's and Sean 's comments in PR # 234 While working on this I noticed than one cause for 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 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 ,
Paragraph (version A):
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
discontinued.
Paragraph (version A):
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
discontinued.
Paragraph (version A):
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.
Paragraph (version B):
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.