[secdir] Secdir review of draft-ietf-json-i-json-05

Tero Kivinen <kivinen@iki.fi> Thu, 08 January 2015 14:13 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7A7901A0231; Thu, 8 Jan 2015 06:13:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id X2fbawpqWw6e; Thu, 8 Jan 2015 06:13:37 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 D2E151A3BA0; Thu, 8 Jan 2015 06:13:02 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost []) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t08ECvAS025132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Jan 2015 16:12:57 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t08ECv1x027788; Thu, 8 Jan 2015 16:12:57 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21678.36969.742906.415575@fireball.kivinen.iki.fi>
Date: Thu, 8 Jan 2015 16:12:57 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-json-i-json.all@tools.ietf.org
X-Edit-Time: 14 min
X-Total-Time: 15 min
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/zo1r5v9WlcGeZW3n6BbkfOAMp1o>
Subject: [secdir] Secdir review of draft-ietf-json-i-json-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 08 Jan 2015 14:13:39 -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 describes the restricted version of the JSON called
Internet JSON. This version of JSON is subset of the full JSON
restricting some uses of the full JSON (i.e it says they MUST use
UTF-8, and then it has several MUST NOTs and SHOULD NOTs limiting some
versions of JSON).

During the review process of the draft-ietf-jose-json-* there was lots
of complains about those documents by secdir reviewers, because the
text in the drafts which said that duplicate names can be parsed in
several different ways. This document forbids having duplicate
names, i.e. makes it MUST NOT.

The security considerations section is very short only saying:

   All the security considerations which apply to JSON (see RFC 7159)
   apply to I-JSON.  There are no additional security considerations
   specific to I-JSON.

And the security considerations section in RFC7159 is also quite
short, only warning about not using the eval when parsing json.

I agree that as this is only restricting the use of JSON, this does
not give any new security ocnsiderations, although I would have
expected the original JSON to have bit longer security considerations
section (especially as the format is not very simple and there are
easy ways to mess up things, but on the other hand most of security
considerations issues are going to be in the applications or protocols
using the JSON, not the actual JSON definition itself).

Anyways it might be good idea to add text to the security
considerations section, that as I-JSON restricts and limits some of
the dangerous formats of the original JSON, it might be considered to
be more secure than the original JSON, and perhaps also mention that
security critical usages of the JSON should use I-JSON instead of JSON
(perhaps even provide references to the jose specifications).

In general I think the document is ready.