Last Call Review of draft-ietf-json-text-sequence-09
review-ietf-json-text-sequence-09-secdir-lc-wallace-2014-12-18-00
Request | Review of | draft-ietf-json-text-sequence |
---|---|---|
Requested revision | No specific revision (document currently at 13) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2014-12-16 | |
Requested | 2014-11-27 | |
Authors | Nicolás Williams | |
I-D last updated | 2014-12-18 | |
Completed reviews |
Genart Last Call review of -09
by David L. Black
(diff)
Genart Last Call review of -11 by David L. Black (diff) Secdir Last Call review of -09 by Carl Wallace (diff) Opsdir Last Call review of -09 by David L. Black (diff) Opsdir Telechat review of -11 by David L. Black (diff) |
|
Assignment | Reviewer | Carl Wallace |
State | Completed | |
Request | Last Call review on draft-ietf-json-text-sequence by Security Area Directorate Assigned | |
Reviewed revision | 09 (document currently at 13) | |
Result | Has issues | |
Completed | 2014-12-18 |
review-ietf-json-text-sequence-09-secdir-lc-wallace-2014-12-18-00
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?