[secdir] secdir review of draft-ietf-json-text-sequence-11

Carl Wallace <carl@redhoundsoftware.com> Sat, 13 December 2014 18:25 UTC

Return-Path: <carl@redhoundsoftware.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5773E1A1AA5 for <secdir@ietfa.amsl.com>; Sat, 13 Dec 2014 10:25:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
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 1RanYDf-jQM8 for <secdir@ietfa.amsl.com>; Sat, 13 Dec 2014 10:25:47 -0800 (PST)
Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF471A0103 for <secdir@ietf.org>; Sat, 13 Dec 2014 10:25:47 -0800 (PST)
Received: by mail-qa0-f52.google.com with SMTP id dc16so6612897qab.11 for <secdir@ietf.org>; Sat, 13 Dec 2014 10:25:46 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-type:content-transfer-encoding; bh=OgRxAIr2vC+UHTrl3OpqesKDFcd9BYAItfD6vw3qxlg=; b=Wavu7ux/BCE9oR/qOb/iuVFQG4JUY0RCaHnlEbqIJyBPazF5HblJh49OM/ckJ377aJ D9SDU8Oz9lgD3GKAuVUZ24cLLqvhb7FIk+YwUj34CJnN2+27sC2Que1kAEAQAQ/2Fj5d Lb9ZtmuLm92ZSPq4aji21JkTHOenWVNvreu4/5tToCZl2OJ8Lo5prVaq3L2UnLWOB9Hb VX4q43GeXw7h/QnHExx3FomdZR1anOlSa4uR3D3Drn2MJZntNaJUPvU/9/MekE+HBf/I W3RIbz4kBmRnvRgjlqrZqqSoQQMQy8KspBUG9wuV1uskZqyLbGQ545FrUViD9/T0ego0 c3SQ==
X-Gm-Message-State: ALoCoQliptYVFAKMM3Ela3/D4XkZiTqTFQO1hRFPCMISUs3Qr4BSAshD8EXuf9bB+V1ZMfYdmrjn
X-Received: by 10.224.88.8 with SMTP id y8mr40844188qal.47.1418495146845; Sat, 13 Dec 2014 10:25:46 -0800 (PST)
Received: from [192.168.2.58] (pool-173-79-132-199.washdc.fios.verizon.net. [173.79.132.199]) by mx.google.com with ESMTPSA id v5sm5153301qaj.2.2014.12.13.10.25.39 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Dec 2014 10:25:46 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.4.3.140616
Date: Sat, 13 Dec 2014 13:25:33 -0500
From: Carl Wallace <carl@redhoundsoftware.com>
To: <secdir@ietf.org>, <iesg@ietf.org>, <draft-ietf-json-text-sequence@tools.ietf.org>
Message-ID: <D0B1EECD.29290%carl@redhoundsoftware.com>
Thread-Topic: secdir review of draft-ietf-json-text-sequence-11
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/NmKp0rCFVD4Sa1Oo9OiwoyG6UKk
Subject: [secdir] secdir review of draft-ietf-json-text-sequence-11
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: Sat, 13 Dec 2014 18:25:49 -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 with the intent of improving security
requirements and considerations in IETF drafts.  Comments not addressed in
last call may be included in AD reviews during the IESG review.  Document
editors and WG chairs should treat these comments just like any other last
call comments.

This document describes a means of encoding and parsing arbitrarily large
sequences of JSON texts. The document claims no new security
considerations beyond those in RFC 7159.  I have some concern that the
addition of a LF by the JSON text sequence encoder that is not removed by
the JSON text sequence parser has the potential to break detached JSON web
signatures that cover JSON text sequence elements.  A few general comments
and questions are below:

- In the abstract of version 11 the hex value for ASCII line feeds was
changed to 0x1E from 0x0A.
- In section 2.1, shouldn’t possible-JSON be defined as *(not-RS) to allow
for parsing of <RS><RS><RS>?
- Section 2.3 should clarify that malformed JSON text sequences are also
not fatal (I.e., arriving at an RS without having seen a LF).
- The second paragraph of Section 2.3 suggests that an incremental JSON
parser may be used across content from multiple sequence elements.  The
ABNF for encoders does not seem to support this.
- The last sentence of the second paragraph in Section 2.4 is a bit
confusing. If a JSON-text has no trailing ws and the LF from the JSON text
sequence is used to match the ws rule, should this be reported as a
malformed JSON text sequence, a malformed JSON-text or neither?
- In section 2.4, the “parsers” referenced in the second and third
paragraphs should be qualified as JSON text sequence parsers or JSON
parsers.  
- In section 2.4, assuming the parser is a JSON text sequence parser, why
is the MUST drop in the third paragraph necessary given potential use of
incremental parsers mentioned in section 2.3 and later in 2.4? How do you
distinguish between a “non-self-delimited top-level value” and a piece of
JSON-text being parsed incrementally?
- The examples for possibly truncated JSON texts seem to assume that the
LF appended by a JSON text sequence encoder is absent. How would a
truncated JSON text within a properly delimited JSON text sequence be
detected? For example, if a component feeding JSON text elements to a JSON
text sequence encoder failed where the JSON text sequence encoder
succeeds, the result would be a truncated JSON text within a valid JSON
text sequence. I realize the ABNF should preclude encoding invalid JSON
texts but there is no text that instructs encoders to fail when invalid
JSON texts are detected.
- The failure to address the LF in the parser section seems like it could
cause problems for re-encoding.  What would prevent accumulation of LF
characters as a JSON text sequence was encoded, parsed, re-encoded,
re-parsed and re-encoded?