New security considerations #69
Conversation
|
Also, this is intended to replace all other text about security in the document, particularly the text in the strict mode section. |
| The decoder should also check for and reject invalid CBOR for each | ||
| data type or tagged type that is in use for a particular CBOR-based | ||
| protocol. | ||
|
|
There was a problem hiding this comment.
To me this says that I would need to check for invalid mime and nested types. If that is not what is meant then this needs to be clearer
| appropriate resource management to mitigate these attacks. (Items for | ||
| which very large sizes are given can also attempt to exploit integer | ||
| overflow vulnerabilities.) | ||
|
|
There was a problem hiding this comment.
I think that this issue of large allocations should be called out specifically.
| To facilitate | ||
| this, encoder and decoder implementations used in such contexts should | ||
| provide at least one strict mode of operation ({{strict-mode}}). | ||
|
|
There was a problem hiding this comment.
From a security point of view. This paragraph is something that is of importance. It is really necessary to make sure that duplicate keys can be prevented. Allowing duplicate tags is not necessarily verboten.
|
I've made updates that I hope should address most of Jim's comments. It seems like this text might need a tweak after other changes are made to other parts of the document in related to invalid CBOR. |
|
I'm not sure that we should be deleting any of the existing text. The new text should be integrated with it, not replace it. |
|
Comment on first existing paragraph -- It starts "A network-facing application can exhibit v...". This points out some good security characteristics intrinsic in the CBOR design, but nothing the implementor should do. It didn't seem necessary to me, but I'm fine with keeping it. |
|
Comment on the second existing paragraph which starts "Resource exhaustion attacks might attempt to lure..." -- I think my new second paragraph addresses everything in the old paragraph. I avoided mention of stack and allocation because different languages work differently and it seems impractical to instruct the coder on these things. |
|
Comment on the third existing. "Protocols that are used in a security context ... -- I think I have addressed everything in it in my 3rd and 4th paragraphs. I am also attempting to line up with the levels of error handling. Is there something in the 3rd paragraph that I haven't addressed? |
Merged #69 (security considerations) with existing text
I see no reason for us to be wishy-washy in any way on correctness and security for decoder input processing in this day and age and with a modern protocol like CBOR. It is not that hard to get this right.
This lines up with what I would expect to be the internal coding standard of any reasonable modern SW company.