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

[Carl Wallace <[e-mail]>]

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?