[Cbor] Strict mode

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

Return-Path: <lgl@island-resort.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9E0131200 for <cbor@ietfa.amsl.com>; Wed, 20 Mar 2019 11:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFM4qioKpcGY for <cbor@ietfa.amsl.com>; Wed, 20 Mar 2019 11:27:02 -0700 (PDT)
Received: from p3plsmtpa09-06.prod.phx3.secureserver.net (p3plsmtpa09-06.prod.phx3.secureserver.net [173.201.193.235]) (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 93BC51310E0 for <cbor@ietf.org>; Wed, 20 Mar 2019 11:27:02 -0700 (PDT)
Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id 6fvYhoPEgdwXW6fvZhLOon; Wed, 20 Mar 2019 11:27:01 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F5710847-DC05-4A20-B878-DC9A9C1AD10B"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <C9756F68-FAB4-4F06-9DC3-89780012FAE8@island-resort.com>
Date: Wed, 20 Mar 2019 11:27:00 -0700
To: cbor@ietf.org
X-Mailer: Apple Mail (2.3445.9.1)
X-CMAE-Envelope: MS4wfBBWVQWFYpw/uWVKZ24TfkuY/XzTH6mAFhrDZczpKVuHozC8qeW3nvqa8CH7AgU59Ro7SSIqG/naBduUb3eAVG/5cx6j9G6m3J8dWKwOSU3IgS7IX4Ut SUjYpTGlGcyaYguoMrQThops7MC8z7K7C2SUcWep4WtgSmV5ZWU/39TP
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/uqv-JNgH2dCCTkh6lmEzkIfeYJQ>
Subject: [Cbor] Strict mode
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 18:27:05 -0000

Hi again,

So strict mode seems to be the middle of these three:
• 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

I went through the whole CBOR spec and identified almost 20 valid/invalid checks that a decoder could perform. For example, valid UTF-8, tag 1 dates are integer or float, key duplication, base64 uses only allowed base64 characters, MIME data is valid MIME syntax…  Some of these are cheap, easy and obvious. Others are quite expensive and difficult. 

So strict mode seems somewhat of an implied smorgasbord of checks that a generic decoder might perform or not perform. In many cases it will be much cheaper and easier to implement these checks in the next layer up. They might already be there too, so it would be waste for a generic decoder to perform them. For example, a base64 encoder will probably check for allowed base64 characters.

I think it is kind of interesting to describe a CBOR firewall and that such a thing might be useful. I think it is more than strict mode though. It needs to check for well-formed CBOR. If it is generic it should check for as many invalid things as possible. It should also be described as a secondary defense and that the main decoder for a protocol should never rely on it. See section 9.

My thought for the document would be to list all of the almost 20 valid/invalid checks in 4.4 Other Decoding Errors with some discussion on how and when they might be implemented. Then remove mention of the specific valid/invalid checks in 4.11 Strict Mode Decoding. That is kind of duplicate text now. Then make section 4.11 about CBOR Firewalls.

LL