Re: [Lake] Error message => Discontinue #208

[Marco Tiloca <[e-mail]>]

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 | tstr | Sender error
2 | tstr | 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 ERR_CODE 
1 (Sender error) and the use of 5.00 responses for ERR_CODE 2 (Receiver 
error).

Best,
/Marco

On 2022-01-24 13:08, John Mattsson wrote:
>
> Hi,
>
> Issue #208 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 #234
>
> https://github.com/lake-wg/edhoc/pull/234
>
> 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 | tstr | Unspecified
>
> Should EDHOC instead have have something like?
>
> 1 | tstr | Unspecified Initiator error
>
> 2 | tstr | Unspecified Responder error
>
> or
>
> 1 | tstr | Unspecified Sender error
>
> 2 | tstr | 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
>
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www.ri.se

Phone: [phone]
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)