Re: [Json] Working Group Last Call on draft-ietf-json-text-sequence

[Tim Bray <[e-mail]>]

>From section 1:


   Ideally such datasets could be parsed and processed one element at a
   time.  Even if each element must be parsed in a not-online manner due
   to local choice of parser, the result will usually be sufficiently
   online: limited by the size of the biggest element in the sequence
   rather than by the size of the sequence.


The second sentence is klunky and I don’t understand what it’s trying
to say.  I suggest attaching the first sentence to the previous para
and just losing the 2nd sentence.

=====================

Just lose section 2.1.  Section 2 says perfectly clearly what a JSON
sequence is, and requires that the material separating the texts MUST
include one newline; so this language is at best redundant.  How about
putting a one-liner after the ABNF in section 2 saying.


“The effect of the ABNF is that the JSON texts in a JSON Text Sequence
are separated by whitespace which MUST include at least one newilne
(U+000A) character.”

=====================

3., first para: missing word, should be “until they are closed”.

=====================

I suggest removing section 3. It’s not hard to construct something
that could appear in the middle of a JSON text that would match
“boundary”. As you note, this will not be a very common circumstance,
and I’m thinking of a bunch of different approaches I’d use.  In
practice, the best solution is probably to arrange that records
deterministically start with "\n{".


Having said that, this is obviously an attack surface. I wonder how
well deployed JSON parsers would survive bogus sequences constructed
with careful maliciousness to drive typical parser implementations
into severe CPU or memory burn?  I bet I could construct a byte stream
that would cause serious pain to most of the popular parsers.

=====================

Security considerations:

- Why does the lack of an end-of-seq indicator constitute a security
issue?  I can believe it might be but there needs to be some sort of
threat model

- this paragraph...


   JSON text sequence parsers based on non-incremental, non-online JSON
   text parsers will not be able to efficiently parser JSON texts in
   which newlines appear; attempting to parse such sequences with non-
   incremental, non-online JSON text parsers creates a compute resource
   exhaustion vulnerability.

Huh? What does the word “online” mean in this context?  Not a
rhetorical question, I genuinely don’t get it.  I propose the
following rewrite for Security Considerations


<div>

All the security considerations of JSON [RFC7159] apply to JSON Text Sequences.


An attacker could try to cause breakage in JSON Text Sequence
processing software by arranging for a JSON text in a sequence to be
very large, for example by including very large keys or values in JSON
objects.  JSON allows parsing software to impose limits on the such
lengths, and implementors receiving software SHOULD implement and
enforce such limits.


An attacker could try to cause breakage in JSON Text Sequence
processing software by including syntactically broken JSON texts which
are designed to cause misbehavior in software attempting
resynchronization.

</div>



On Thu, May 22, 2014 at 4:00 PM, Paul Hoffman <[e-mail]> wrote:

> This begins a two-week Working Group Last Call on
> draft-ietf-json-text-sequence <
> http://tools.ietf.org/html/draft-ietf-json-text-sequence>. We are seeking
> any and all comments on the document in order to assess the strength of
> consensus for it. If you are on this mailing list and have not yet read the
> document, please do so now, and then comment on the list. If you have
> already read the draft and commented, please feel free to do so again.
>
> As a reminder, comments can be anywhere in the continuum of "looks fine"
> to "terrible idea"; they can include questions; they can include
> suggestions for singificant editorial changes; they can include minor
> editorial notes.
>
> --Matt Miller and Paul Hoffman
> _______________________________________________
> json mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/json
>



-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)