[Cbor] Handling malicious CBOR input

[Laurence Lundblade <[e-mail]>]

Hi all,

Carsten described three levels of error handling here <https://github.com/cbor-wg/CBORbis/issues/45>:
• well-formed (vs. syntactic error). Not well-formed is now MUST NOT generate/accept.
• valid (vs. semantic error). Protocol encoders now MUST generate valid CBOR.
• expected (vs. unexpected by application). This is application-specific and often expressed in CDDL.

The middle one is more or less strict mode by my understanding (checking for valid/invalid CBOR). Strict mode still has a lot of text says it is a particularly useful way to defend against malicious input. The seems off to me. I think it has to be defended against at all three levels.

Before I go off and try for a pull request, here’s what I was thinking:

The main focus on malicious input is section 9 Security Consideration.  It gets improved with a discussion of the three levels of error handling and how each level must do their part. 

Text is also added to section 9 that says malicious input is pervasive and inevitable, that even in closed environments and walled gardens, even signed and encrypted CBOR input can not be assumed to be safe.

Then section 4.3 Syntax Errors mentions malicious input and references section 9. I would also like to disallow “take some other action” in this section.

There is also a mention and reference to section 9 in 4.4 Other Decoding Errors. The malicious input text in section 4.11 Strict Decoding Mode would largely be moved to section 9 and there would be a reference to section 9.

LL