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

Chris Lonvick <lonvick.ietf@gmail.com> Fri, 28 September 2018 16:19 UTC

Return-Path: <lonvick.ietf@gmail.com>
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 C72CF130E6C; Fri, 28 Sep 2018 09:19:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 2AmZcgAVKJM0; Fri, 28 Sep 2018 09:19:27 -0700 (PDT)
Received: from mail-yb1-xb44.google.com (mail-yb1-xb44.google.com [IPv6:2607:f8b0:4864:20::b44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD17130E6B; Fri, 28 Sep 2018 09:19:27 -0700 (PDT)
Received: by mail-yb1-xb44.google.com with SMTP id o8-v6so2853459ybk.13; Fri, 28 Sep 2018 09:19:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=pyyO6rULtq1J23OPJXR/zuPTFwuoQISXBQ8tRGSXs5E=; b=J4F7j/MMZ2HY3bRyvoibnr23LQgx956LmPW3BxbyO6WQTOduXjPNcOePNz8B4x09j7 QZ1TYaeH8mCYnP90CbJ6W0xL1BJw/i/M1BvNmoVR+t48GJm1fse7RIB7v9aV413chFCg bDeo8o/zmnz1ViNmuB2uELaywwlBKQK2GImey/WH91CMEUJutMyiXPbLiqfw/rXkN6YZ FIo950PTr0Dcz3yU9C2nBjJL0qr0BgXmdtsP0pCCl7jz9+39FJ8IKD9LtF4wq6oJHWd1 DDtRVHSQnTvmVr3J77NIYwH48rEa+ejYvOueV0OOPFg20i7hSoMkz/x2ClRvsHF+c+eD L7Ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=pyyO6rULtq1J23OPJXR/zuPTFwuoQISXBQ8tRGSXs5E=; b=I/dygLx5slV9suDSp9AzeTVVi0hCFAjUteFcXjC8Z3ylT3Heu0sZlhc6kyernb6NMf ZEOV+gDO5sjYS/ikrshR0iZGRsJQVb0dTGIY6kTNM4btCwPOsRWiTgCzwl+OWeAR4s// XSlC+gfISl76RGfk/7mf6e1bqMXvO/2V0esz1n4XAHP0durkVcxY7wlVNGWeAyeQI8WB 8Jss7fAxv6j/mCWOlst2YBu0f3HQFjAA9pRXcRsfKvY1X5wnuUlEX3CJMzyxG7eyjQHf 7wUwDQemRQrNZ0un9F7HWFcdbak9MfVZnV6FAm63o34qUk7Bgal1GSUzZZ46wXWda6YQ za2A==
X-Gm-Message-State: ABuFfogtROLdQ0spUCe4NDPOEjwhRnWc0CoJQwxfDR3ZcRxr9CySqhde HbkaOWEe2g41YAIc2H8ZYX8lVrgd
X-Google-Smtp-Source: ACcGV60Ykag1fN6crUZyDYHNk++85Yh5R+QUhZ6Kr8nwzycdlJCstl2H0iPueUbhHtX/myyXyXtGTQ==
X-Received: by 2002:a25:1f54:: with SMTP id f81-v6mr8627075ybf.164.1538151111034; Fri, 28 Sep 2018 09:11:51 -0700 (PDT)
Received: from Chriss-MacBook-Air.local (c-73-19-199-54.hsd1.tn.comcast.net. [73.19.199.54]) by smtp.googlemail.com with ESMTPSA id n186-v6sm2500809ywn.16.2018.09.28.09.11.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Sep 2018 09:11:50 -0700 (PDT)
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-cbor-cddl.all@ietf.org
From: Chris Lonvick <lonvick.ietf@gmail.com>
Message-ID: <5BAE5278.9060005@gmail.com>
Date: Fri, 28 Sep 2018 12:10:32 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------000306090908010609020009"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/_3iSpOJW6em-kDQ8d4VCm6FwB_A>
Subject: [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: Fri, 28 Sep 2018 16:19:30 -0000

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..."

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.

Best regards,
Chris