Update to error processing

[gselander]

Creating a new issue to overview the various new issues raised around error processing. First set:

A. Request for an error indicating unknown referenced credential

• Request for "unknown credential referenced" / “credential not accepted, try another” error #400
• New error code for unknown credential referenced #401

B. Request for a dedicated ERR_CODE to indicate failure in EAD processing + potential new registry for error cases.

C. Protected error messages

• #375 processing of message_2 and message_3 #398

[gselander]

Just as a reminder, at IETF 110 we had the following candidate EDHOC error classes:

1. Selected cipher suite not supported
2. Message (field) error (syntax error or incorrect protocol field of expected message)
3. Credential/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)
4. Decrypt error (a cryptographic operation failed, including being unable to correctly verify a signature or a MAC in the protocol message)
5. EAD error (unsupported or missing data)
6. Access denied (credential valid but peer not allowed access)
7. Internal error (error not related to the protocol or the peer)

Currently in the draft, only 1. is included (ERR_CODE = 2), 2-7 are "unspecified error" (ERR_CODE = 1).

[gselander]

Regarding item B above. One way is to register an ERR_CODE for EAD, reuse the ead_label in indicate first EAD item to fail, and let the EAD application define ead_error.

error = (
ERR_CODE : int,
ERR_INFO : any,
)

ERR_INFO = (
ead_label : int,
? ead_error : any,
)

[chrysn]

About B, I don't think this fits the criterion of only doing errors that are actionable, at least initially.

If the sender of the EAD were willing to do the EDHOC exchange even without that particular EAD item, it would have made it non-critical. So if it's critical, then the sender already stated things will not continue.

[marco-tiloca-sics]

This means that an EAD application would simply register the ERR_CODE values it needs in the "EDHOC Error Codes" registry, together with the semantics for the accompanying ERR_INFO.

That's also fine; regardless the exact approach, my main point was enabling an EAD application to indicate which exact EAD item processing failed.

At the same time, I was (maybe too) worried about overpopulating the "EDHOC Error Codes" registry by doing so, hence the proposed hierarchical approach of having a single ERR_CODE value registered there (meaning "something went wrong with an EAD item, see ERR_INFO for details that will tell you which EAD item and what went wrong with it).

Regardless, as I understand Section 3.8 of -lake-edhoc-19, an EAD application might be designed to fail and return an EDHOC error message also if the processed of a non-critical EAD item has failed. It's just not a must like in the case of critical EAD items.

[chrysn]

To be clear: I'm not saying that "something was wrong with your EADs" would not make a sensible error code (and I don't have a clear picture of whether it makes sense to distinguish "Understood but your cert is bad" from "Understood but I don't like your EAD"). I'm just saying that it's not actionable, and working under the actionability criterion thus not eligible.

The point about non-critical failed-to-process items is an important one -- "ignore if you don't know it" is not the same as "ignore if processing whatever is in their failed. But looking at how that those are recoverable points to the general topic of recoverability, which it may make sense to think up examples of. When recovering from cipher suite mismatches, much deliberation went into the prevention of downgrade attacks. If the actionability of of an (even non-critical) EAD that failed to process is to retry without it (or with an altered form of it), that is a kind of downgrade attack again for EAD1, as the on-path attacker can deny the peers that EAD without being discovered.

So maybe the requirement for error codes to only be registered (initially) when they are recoverable is a good opportunity to get review of whether the recovery implied by the error code is safe. The error code you suggest for "EAD caused failure" would pass here if it described well which kind of recovery is allowed with it. (The addition would consist mainly of seccons, I figure -- maybe to the extent where it's better done in a document that may be informationally referenced in EDHOC already). (Or it's shorter than I think or can for other reasons fit well in EDHOC, dunno, but my gut feeling is that such a characterization would be large).

[marco-tiloca-sics]

So maybe the requirement for error codes to only be registered (initially) when they are recoverable is a good opportunity to get review of whether the recovery implied by the error code is safe. The error code you suggest for "EAD caused failure" would pass here if it described well which kind of recovery is allowed with it.

Unless we have a simple/trivial characterization of "safe recoverability" (which I don't have out of my hat), I think it's just better for the time being to go for the the first requirement you propose on registering error codes :-)

[gselander]

A & C are done, and we agree to no to B, so closing this.