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

[Nico Williams <[e-mail]>]

On Fri, May 23, 2014 at 12:02 PM, Tim Bray <[e-mail]> wrote:
> Clearly the current language is confusing readers of the spec. So I suggest
> that you be careful to define specialized terms that you are going to use in
> the spec.  An even better solution would be to structure the spec to avoid
> having to bring in this level of implementation idiosyncrasy.
>
> The more I think about the resync-after-error problem, the unhappier I get.
> If the JSON texts in sequences were required to be JSON objects, and
> required to start on new lines, this would be immensely easier for
> implementors.

That is not sufficient.  Consider this text:

{ "foo":
{ "bar":"baz" }
}

Clearly looking only for LF '{' is insufficient.

The text describes how to ensure that resynchronization can be done safely.

First, it says that "writers SHOULD validate (parse) any untrusted
JSON text inputs".  Then it gives two methods that, together with
validation, make resynchronization possible.

One method is to remove all newlines from JSON texts (a trivial
operation, see below) prior to writing them to the log file.  Then the
only boundary that matters is newlines, and that's very easy to search
for reliably.

The other method is to prefix every text with another text consisting
of something like 'null' (or 'true', or any value which will by
convention have no meaning other than as a resynchronization helper).
Also a trivial operation.

(Note that because newlines in strings must always be escaped, then
only newlines interior to any JSON text are... superfluous whitespace
that can be safely removed without having to parse and re-encode the
JSON text.)

Most attacks on loggers are easily thwarted by checking that any JSON
text to be logged is valid.  This leaves only one attack vector:
forcing a write by the logger to fail after starting -- this is a
non-trivial attack to mount, and it is trivially defeated by either
removing internal newlines from texts prior to writing them, or by
prefixing them with a meaningless-by-convention text (e.g., 'null').

Nico
--