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

From: John Mattsson <[email-masked]>
Date: Mon, 24 Jan 2022 12:08:43 +0000

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

---

From: Marco Tiloca <[email-masked]>
Date: Mon, 24 Jan 2022 16:57:13 +0100

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:
> 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.
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
Department: Computer Science
Unit: Cybersecurity

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

Phone: +46 (0)70 60 46 501
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

---

From: John Mattsson <[email-masked]>
Date: Mon, 24 Jan 2022 17:54:22 +0000

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 | tstr | Do not automatically retry error
2 | tstr | 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.

John

From: Marco Tiloca <marco.tiloca=[email-masked]>
Date: Monday, 24 January 2022 at 16:57
To: John Mattsson <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Lake] Error message => Discontinue #208

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

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

Hi,

1 | tstr | Unspecified

or

Cheers,

John

--

Marco Tiloca

Ph.D., Senior Researcher

Division: Digital System

Unit: Cybersecurity

https://www.ri.se

SE-164 40 Kista (Sweden)