Re: [secdir] SECDIR review of draft-ietf-cbor-cddl-05

Carsten Bormann <cabo@tzi.org> Tue, 06 November 2018 23:05 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C5F130E09; Tue, 6 Nov 2018 15:05:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 DVXdHv7Hg3cj; Tue, 6 Nov 2018 15:05:40 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 51A40130E11; Tue, 6 Nov 2018 15:05:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wA6N5R2V024609; Wed, 7 Nov 2018 00:05:32 +0100 (CET)
Received: from [IPv6:2001:67c:1232:144:5806:ec29:caf1:467b] (unknown [IPv6:2001:67c:1232:144:5806:ec29:caf1:467b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42qQBF3Tt3z1Bqf; Wed, 7 Nov 2018 00:05:25 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <5BAE5278.9060005@gmail.com>
Date: Wed, 7 Nov 2018 06:05:20 +0700
Cc: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-cbor-cddl.all@ietf.org, cbor@ietf.org
X-Mao-Original-Outgoing-Id: 563238319.030874-67ebffb30a8d9e341cbc27ad2556a927
Content-Transfer-Encoding: quoted-printable
Message-Id: <7DEE4371-FA16-490B-B148-7E237DA5308E@tzi.org>
References: <5BAE5278.9060005@gmail.com>
To: Chris Lonvick <lonvick.ietf@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/7FkheGS4HcAy7H4-JRm8zQUAdg0>
Subject: Re: [secdir] SECDIR review of draft-ietf-cbor-cddl-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2018 23:05:44 -0000

Hi Chris,

thank you for this review.

> On Sep 28, 2018, at 23:10, Chris Lonvick <lonvick.ietf@gmail.com> wrote:
> 
> Hello,
> 
> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. 
> 
> The summary of the review is READY with nits.
> 
> I skimmed through the draft and agree with the author's statement in the first paragraph of the Security Considerations section:
>    This document presents a content rules language for expressing CBOR
>    data structures.  As such, it does not bring any security issues on
>    itself, although specification of protocols that use CBOR naturally
>    need security analysis when defined.
> 
> (As a very minor nit, I'd suggest using "analyses" rather than "analysis".)
> 
> Nit 1: The authors have made a good effort at identifying some of the topics that may be considered in a security considerations section of specifications that use protocols using CDDL to define CBOR structures. However, I would recommend that those bullet points be used to supplement a normative reference to RFC 3552 “Security Considerations Guidelines". 

> 
> Perhaps adding the following between the first and second paragraphs:
>    Guidelines for writing security considerations are defined in Security Considerations Guidelines [RFC 3552] 
>    (BCP 72).  Implementers using CDDL to define CBOR structures in protocols must follow those guidelines.
> 
> Then change the start of the second paragraph from “Topics that may be..." to "Additional topics that may be..."

I think this is a very good idea.  It is now addressed (with slightly different wording) in
https://github.com/cbor-wg/cddl/commit/d3b2483f1b7a94eb9ba9cab22143c43f1be8909d
(which will be in -06).

> Nit 2: I am not very familiar with all of this, but it seems to me that RFC 8152, "CBOR Object Signing and Encryption (COSE)" should be a normative reference rather than an informative reference, and some mention should be made of it in the Security Considerations section. Reference is made in RFC 8152 to CDDL (4th paragraph in Section 1.3):
>    As well as the prose description, a version of a CBOR grammar is
>    presented in CDDL.  Since CDDL has not been published in an RFC, this
>    grammar may not work with the final version of CDDL.  The CDDL
>    grammar is informational; the prose description is normative.
> 
> I may be off base here, but it just seems that since 8152 has been published as a Standards Track document, then this draft should normatively reference it and any subsequent updates to 8152 should normatively reference the Standards Track RFC issuing from this draft. 

It is indeed true that COSE (RFC 8152) uses CDDL, and even goes ahead to quickly define the subset it uses in its section 1.3 (with the slightly confusing title “CBOR grammar”).
That does not make the COSE specification a normative reference for CDDL though — many protocols specified in CDDL will not make use of COSE, and those that do will rightly reference COSE as a normative reference.  There is no need to read section 1.3 of RFC 8152 to use the specification of CDDL.
I do agree that a COSEbis (which might be started about now) could use the specification of CDDL as a normative reference (if the downref is accepted), but we don’t have to have a position on that now.

Grüße, Carsten