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

[John Mattsson <[e-mail]>]

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=[e-mail]>
Date: Monday, 24 January 2022 at 16:57
To: John Mattsson <[e-mail]>, [e-mail] <[e-mail]>
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
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://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-523a547beadf021c&q=1&e=d0e610e8-e168-45d3-95fb-39c7150c896c&u=https%3A%2F%2Fgithub.com%2Flake-wg%2Fedhoc%2Fpull%2F234" rel="nofollow">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://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-3d296ae5721cac2b&q=1&e=d0e610e8-e168-45d3-95fb-39c7150c896c&u=https%3A%2F%2Fwww.ri.se%2F" rel="nofollow">https://www.ri.se

Phone: [phone]

Isafjordsgatan 22 / Kistagången 16

SE-164 40 Kista (Sweden)