Re: [Cbor] [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14

Carsten Bormann <cabo@tzi.org> Tue, 11 August 2020 23:24 UTC

Return-Path: <cabo@tzi.org>
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 8D8173A0DC9; Tue, 11 Aug 2020 16:24:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 wvmCShEXtLIO; Tue, 11 Aug 2020 16:24:20 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A6FA3A0DBE; Tue, 11 Aug 2020 16:24:19 -0700 (PDT)
Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BR86R6B8Sz17r5; Wed, 12 Aug 2020 01:23:59 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <A21FB7FB-664B-4632-BE14-93629BCD01B9@gmail.com>
Date: Wed, 12 Aug 2020 01:24:01 +0200
Cc: cbor@ietf.org, secdir@ietf.org, Last Call <last-call@ietf.org>, Laurence Lundblade <lgl@island-resort.com>, draft-ietf-cbor-7049bis.all@ietf.org
X-Mao-Original-Outgoing-Id: 618881041.389055-e7d65e16d11098fbbf08f2f18de616d3
Content-Transfer-Encoding: quoted-printable
Message-Id: <DCA65CE9-F134-4F84-A1D6-12FAA73A3A57@tzi.org>
References: <159705005508.2366.4819563096010229406@ietfa.amsl.com> <B3108FFC-319E-4D8B-8DF4-A866585781DE@island-resort.com> <D3AA9975-187F-485A-A13E-6A878607DBCF@gmail.com> <6A1090D8-D012-4A04-BC4A-9CF23E791DA2@tzi.org> <A21FB7FB-664B-4632-BE14-93629BCD01B9@gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/YrAQl7JmuX_G8WJtMrz30YMyKfo>
Subject: Re: [Cbor] [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14
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: Tue, 11 Aug 2020 23:24:24 -0000

On 2020-08-11, at 21:14, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
> 
>> 
>> I understand that, but realistically, without a list of (potential) validity checks in the RFC, there will be wide variance in what is documented by decoders – if any. In fact I checked a few implementations just now, and most of them do not document what validity checks they perform. Those that document something are hard to compare. If you make a canonical list, people would have a starting point.
> 
>    To be fair, you probably checked RFC 7049 implementations, and RFC 7049 didn’t have such a requirement (improving the discussion of validity was one of the major work items in 7049bis, see Appendix G.3).
> 
>    One point to keep in mind is that, with CBOR, most validity processing happens in the processing of tags, and that is an extension point.  So a list in 7049bis will never be complete.  Even if it only covers base CBOR and the tags registered in 7049/7049bis, a detailed version is likely to be tedious and highly dependent of specific implementation approaches.
> 
>    Trying to imagine the outcome of this exercise, my visual image right now is a PICS Proforma, so I think I’ll better stop here...
> 
>    Grüße, Carsten
> 
> Hi Carsten,
> 
> You are addressing this issue from the point of view of a spec writer, I suggest you take the POV of the implementer,

I took the view of the implementer of a generic decoder (which I happen to also be IRL), faced with a PICS Proforma.

Just in case that term doesn’t already send you running for the hills, there are some standards that come with a [not so] little word document that you are supposed to fill in to describe what your implementation of that standard really does.

> the user of a decoder. Those people are not CBOR experts, and when faced with free-form and probably terse documentation of a decoder's validity checking would never know what they need to consider to add as application-level checking.

I certainly can agree with that.  Still, I would like to learn about other places where IETF has done something like that, so we can learn from those efforts.

> I realize that tags are an extension point, but if we are to avoid decoding-related vulnerabilities, I suggest you list validity checks for the base CBOR and tags in RFC7049+bis.

Would that also be a good thing for a separate document, possibly including more tags?

Grüße, Carsten