[secdir] SecDir Review of draft-bormann-cbor-04

Matthew Lepinski <mlepinski.ietf@gmail.com> Mon, 12 August 2013 01:53 UTC

Return-Path: <mlepinski.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 701CA21F9DA1; Sun, 11 Aug 2013 18:53:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 410tIaKU8kFv; Sun, 11 Aug 2013 18:53:02 -0700 (PDT)
Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 292EE21F9EFF; Sun, 11 Aug 2013 18:45:27 -0700 (PDT)
Received: by mail-qc0-f174.google.com with SMTP id c1so3125806qcz.33 for <multiple recipients>; Sun, 11 Aug 2013 18:45:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=njq15XjIZ/ty7zTpZFOOBTIhoWvGZyw6l5rTA8PVkBA=; b=o0pxx1+HejVlnuGZ0CXofK2b+j3pA1ppaLPPOR7k4vCgTVSUsA3TB1IHzCLzjusprt 786SrxMpLU9n9mrw1ryitUx+cDAecKD/GS3i9QhdZ5CPhVd2Gmd6tmJ61doT5FCaADJm bXnrulsNc6kpGzl+YdXfwMZw1r4NTVVIg3E7YSNczay2EJlKGDPws1p+fEvnhHhLp9Z6 P62GCjaau3H/iJIVlliXww9eEFgOgJBZvsZXwpNxmu6f6HCfnb020QB/aV/jksP0cg1w QzGaMWH12GLn36n/u/3HlJyCCDy9PWk4rXx/NDpnDaItSes1v1BEyCqvpMQK1E2VTTLC 9B3g==
MIME-Version: 1.0
X-Received: by with SMTP id o8mr14828054qag.112.1376271926658; Sun, 11 Aug 2013 18:45:26 -0700 (PDT)
Received: by with HTTP; Sun, 11 Aug 2013 18:45:26 -0700 (PDT)
Date: Sun, 11 Aug 2013 21:45:26 -0400
Message-ID: <CANTg3aCsgH=7+ZF6DRSaNgufRDVe4bGQByNhzO6_=t-hANH8Zw@mail.gmail.com>
From: Matthew Lepinski <mlepinski.ietf@gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-bormann-cbor.all@tools.ietf.org
Content-Type: multipart/alternative; boundary=001a1133dd144d898904e3b6478a
Subject: [secdir] SecDir Review of draft-bormann-cbor-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 12 Aug 2013 01:53:03 -0000

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.

This document appears ready for publication.

This document specifies the CBOR (Compact Binary Object Representation)
binary encoding format. The document is generally clearly written, and in
particular, is to be commended for providing a clear explanation of why one
would want to specify yet another binary encoding for arbitrary objects.

One minor note:
In the security considerations section, the authors explain potential
vulnerabilities in network protocols due to parser errors. (This is good
cautionary guidance to provide implementers.) However, at the very end of
the section, they suggest that an encoder/decoder used in a security
context should provide at least one "strict" mode of operation. I would
suggest adding another sentence or two explaining what the phrase "strict
mode of operation" means in this context.