[Cbor] Handling malicious CBOR input

Laurence Lundblade <lgl@island-resort.com> Wed, 20 March 2019 17:59 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 75DDC1311CF for <cbor@ietfa.amsl.com>; Wed, 20 Mar 2019 10:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Zgrjl3bvVYmm for <cbor@ietfa.amsl.com>; Wed, 20 Mar 2019 10:59:41 -0700 (PDT)
Received: from p3plsmtpa09-07.prod.phx3.secureserver.net (p3plsmtpa09-07.prod.phx3.secureserver.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B41491311F9 for <cbor@ietf.org>; Wed, 20 Mar 2019 10:59:41 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPSA id 6fV5hchXDHni16fV6hhtCm; Wed, 20 Mar 2019 10:59:40 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E6862165-14D1-48C6-9731-B991570DDEF4"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <C5218628-97A4-4BF7-ADA9-E734A4DCF0BC@island-resort.com>
Date: Wed, 20 Mar 2019 10:59:39 -0700
To: cbor@ietf.org
X-Mailer: Apple Mail (2.3445.9.1)
X-CMAE-Envelope: MS4wfOMgWz2nVWUpkO2PU+x9FRAH0JUVciaIiSAOLMx9YDOuLwiU4RNrEraGs5BqFXBiu1k5AXUzfeB6pYrXzrKkvvJFPk9tvSvEng+bpwwmheCSviPodSue n8zcZinHd1TLrz/0WZehotLWKE+VVAA56QpJ9afZSpjPl6KDn032yAso
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/o2aGB-MqQMy9wCbNnT81bjH7vGg>
Subject: [Cbor] Handling malicious CBOR input
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2019 17:59:54 -0000

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.