Draft: draft-ietf-lake-edhoc

Commentary: This should address all open issues regarding errors . Align with very common standard that 0 means success and everything else means error Specify that success is for internal use in the application , it therefore makes sense to use any and let the application define what to store . No sense in forcign application to support 0 , it is not needed for interoperability over the wire . 
 I kept error codes positive as proposed by IOTOPS , but changed the more general error " unspecified " comes before the more specific " wrong ciphersuite " because allows for more specific errors to follow in a structured way in the table aligned better with the subsubsections describing the cipher suite negotiation . 
  and I are happy with this now . Unless there are any comments we will soon merge this . 
 Looks good . 
 At the last interim there was a suggestion to standardize classes of error messages and to ask the IoT groups in IETF about what classes of error messages that should be standardized . The error message should then be augmented with a error message class . int ? array of int ? Shoudl the optional text string remain . That can not be used for any automation . But might be useful for loggging for later reading by a human . The initial classes or error message might not provide much info , e.g. " authentication error " 
 Mailthread in iotops : 
 Proposal after discussion in Hackathon : error = ( ? Cx : bstridentifier , DIAGMSG : tstr , ERRCODE : int / 2 int , ? SUITESR : [ supported : 2 suite ] / suite , ) Top - level ERRCODEs : ( 0 . Success ) field error ( syntax error or incorrect protocol field of expected message ) cipher suite not supported ( include SUITES_R in message ) /context error ( error related to establish certificate / raw public key context for processing message , including certificate expired , revoked , unsupported , corrupt , unknown CA , or other issue in processing the credential ) error ( a cryptographic operation failed , including being unable to correctly verify a signature or a MAC in the protocol message ) data error ( unsupported or missing auxiliary data ) denied ( credential valid but peer not allowed access ) error ( error not related to the protocol or the peer ) Selected comments during Hackathon : Relation to errors on other layer , e.g. CoAP errors or error in application . - EDHOC does not require CoAP so could have use for specified own errors . - Does " 5 . AD error " belong to EDHOC ? Perhaps , auxiliary data provides means for security applications to reuse EDHOC and this would be a channel to send errors in those applications . [ Not sure if this helps but , alternatively , errors could be encoded as auxiliary data , which may require an AD - field in the error message ] - Does " 6 . Access denied " belong to EDHOC ? Perhaps , it provides a suitable error to the requirement " Verify that the identity of the Responder is an allowed identity for this connection " Further comments are welcome . Happy to make the list shorter if possible . 
 Other thoughts : We can put some of these error classes into an " x. unspecified error " bucket if we do n't think they are not meaningful to act upon individually . We can define a class of errors " y. general error " and allow implementations to use class y for any error , including those properly belonging to some class above . This would allow implementations to only support some of the specified errors above , potentially listed in the applicability statement . ( That would render the list of classes above just a RECOMMENDATION . ) 
 Many OSs , shells , and programming languages ( e.g. C ) use 0 for success and everthing non - zero ( negative or positive ) is considered an error . HTTP and Coap use postive numbers only where 2 . or 2xx is considered success . I think we should probably follow one of these convensions instead of making a new one . The specification should also probably define that everything else than whatever we decide for success is considered an error . 
 I made a PR addressing all known issues regarding this . 
 This is ready to merge unless there are any objections . 
 The PR has been discussed and merged . Closing
Mailing list commentary: Hello IOTOPS , There is a discussion in the LAKE WG regarding the potential need to standardize error messages appearing in a security handshake protocol targeting IoT devices . Is this something IOTOPS could contribute to and/or review ? Assuming this might be the case , here is a background and some draft error categories for discussion . Background : LAKE is specifying a lightweight authenticated Diffie - Hellman exchange called EDHOC [ 1 ] similar to the TLS 1.3 handshake but targeting constrained IoT. The protocol consists of 3 messages and an error message which may be sent in response to any non - error message . The error message essentially consists of a diagnostic message field containing a text string targeting the peer administrator . All errors are fatal and cause the protocol to discontinue . The intent with the error message is to provide a hint about the error to the peer application , to enable logging of errors and appropriate management operations . ( Note that since the protocol failed to establish security the error message is unprotected and needs to be treated accordingly . ) The question is what error messages need to be standardized , if any . Detailed information can be provided by using the diagnostic text string . But standardizing detailed error information adds complexity to the specification and implementation , which would contradict one of the design objectives . But perhaps we can we identify a small set of error categories ( codes ) that require to be singled out , for example because how they impact operations . Such categories could potentially be complemented with text providing additional details . Please find below a first sketch of error categories ( inspired by error alerts from TLS 1.3 [ 2 ] ) . Two questions ( going in opposite directions ): 1 . Do we need to make more distinctions / are there missing error categories ? 2 . Are these distinctions necessary , or can we remove / group together some of them ? Draft error categories : A. message field error ( syntax error or incorrect protocol field ) B. integrity error ( unable to correctly verify a signature or a MAC ) C. credential error ( error related to the attempt to use a certificate / raw public key as a basis for autentication , e.g. , certificate expired , revoked , unsupported , corrupt , unknown CA etc . ) D. access denied ( credential valid but peer not allowed access ) E. internal error ( error not related to the protocol or the peer ) F. auxiliary data error ( unsupported or missing extension ) cipher suite not supported ( this particular error has already been specified with a special message field , see Section 6 ) Any comments are welcome . Thanks  [ 1 ] [ 2 ]
Paragraph (version A):
The Initiator MUST select its most preferred cipher suite,
conditioned on what it can assume to be supported by the
Responder.  If the Initiator previously received from the
Responder an error message with error code 1 (see wrong-selected)
indicating cipher suites supported by the Responder which also are
supported by the Initiator, then the Initiator SHOULD select the
most preferred cipher suite of those (note that error messages are
not authenticated and may be forged).
Paragraph (version B):
The Initiator MUST select its most preferred cipher suite,
conditioned on what it can assume to be supported by the
Responder.  If the Initiator previously received from the
Responder an error message with error code 2 (see wrong-selected)
indicating cipher suites supported by the Responder which also are
supported by the Initiator, then the Initiator SHOULD select the
most preferred cipher suite of those (note that error messages are
not authenticated and may be forged).
Paragraph (version A):
ERR_CODE - error code encoded as an integer.
Paragraph (version A):
The remainder of this section specifies the currently defined error
codes, see fig-error-codes.  Error codes 1, 0 and -1 MUST be
supported.  Additional error codes and corresponding error
information may be specified.
Paragraph (version A):
Error code 0 is used for unspecified errors and contain a diagnostic
message.
Paragraph (version A):
For error messages with ERR_CODE == 0, ERR_INFO MUST be a text string
containing a human-readable diagnostic message written in English.
The diagnostic text message is mainly intended for software engineers
that during debugging need to interpret it in the context of the
EDHOC specification.  The diagnostic message SHOULD be provided to
the calling application where it SHOULD be logged.
Paragraph (version A):
Error code 1 MUST only be used in a response to message_1 in case the
cipher suite selected by the Initiator is not supported by the
Responder, or if the Responder supports a cipher suite more preferred
by the Initiator than the selected cipher suite, see resp-proc-msg1.
Paragraph (version B):
ERR_CODE - error code encoded as an integer.  The value 0 is used
for success, all other values (negative or positive) indicate
errors.
Paragraph (version B):
The remainder of this section specifies the currently defined error
codes, see fig-error-codes.  Error codes 1 and 2 MUST be supported.
Additional error codes and corresponding error information may be
specified.
Paragraph (version B):
Error code 0 MAY be used internally in an application to indicate
success, e.g. in log files.  ERR_INFO can contain any type of CBOR
item.  Error code 0 MUST NOT be used as part of the EDHOC message
exchange flow.
Paragraph (version B):
Error code 1 is used for errors that do not have a specific error
code defined.  ERR_INFO MUST be a text string containing a human-
readable diagnostic message written in English.  The diagnostic text
message is mainly intended for software engineers that during
debugging need to interpret it in the context of the EDHOC
specification.  The diagnostic message SHOULD be provided to the
calling application where it SHOULD be logged.