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

Carl Wallace <> Tue, 16 December 2014 17:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7B1EE1A6FFC for <>; Tue, 16 Dec 2014 09:20:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zl_PAS7vhKgm for <>; Tue, 16 Dec 2014 09:20:44 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B5DC1A7001 for <>; Tue, 16 Dec 2014 09:20:14 -0800 (PST)
Received: by with SMTP id q108so8475785qgd.34 for <>; Tue, 16 Dec 2014 09:20:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=0fxKMhit1l919aKpJsfmon/veFkEGA5Jc+XiShoO8Qg=; b=bo99zwlA08kgT9nEzm0+ryvT9xAk6bxfeNpvYoUhIBP0qtAa1vhB5Aq0RPSVg4OXF8 SLVuH2Wni8Kk4xgicFCOpzUcvXsgglwMojCk3voeskEgaAGamhJb57o10gTgZXVgCsR7 E1PZbUvIL6o3El84QaOToCno95kJi0RRkY2MXVATlr7IsTu/tGyTN4Cx/9451MyaN/Bp azKY+9L7ULk3gQm1HdU2f7QuMXFgS2yg48hurCjrgwap7Q2w2P0BUTG5+uyOob92khhq 5RzFfNcdifKTDgAm9r7YTq2qo9buypknnuaNW0Ka20WO+PiCRD+g0jRkvl490n1pF839 d9Qg==
X-Gm-Message-State: ALoCoQmd/6kBjE9PAFnP61bKWC3ginYZx1o1khrPGH7FOiPFnIJrWF13jxd1nJTDwtjTbGUXPt8u
X-Received: by with SMTP id e5mr67068908qae.71.1418750413411; Tue, 16 Dec 2014 09:20:13 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id r16sm1364509qay.10.2014. (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Dec 2014 09:20:12 -0800 (PST)
User-Agent: Microsoft-MacOutlook/
Date: Tue, 16 Dec 2014 12:20:08 -0500
From: Carl Wallace <>
To: Nico Williams <>
Message-ID: <>
Thread-Topic: [secdir] secdir review of draft-ietf-json-text-sequence-11
References: <> <20141216000109.GP3241@localhost> <> <20141216163238.GT3241@localhost>
In-Reply-To: <20141216163238.GT3241@localhost>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Dec 2014 17:20:49 -0000

On 12/16/14, 11:32 AM, "Nico Williams" <> wrote:

>> >> [...]
>> >That's a good point.  Signing individual JSON text sequence elements is
>> >outside the scope of this document.  Either a complete sequence is
>> >signed, or individual texts are signed with a wrapper.  I wouldn't
>> >recommend transferring a sequence of texts and a parallel sequence of
>> >signatures, say.
>> It’s probably worth stating up front the process of encoding a JSON text
>> sequence alters the JSON text sequence elements and that signing
>> individual elements is outside the scope.
>OK, that will be section 3 (security considerations text), something
>   Parsing and re-encoding a JSON text sequence need not produce the
>   same sequence of octets.  Do not rely on being able to reproduce the
>   same inputs to a cryptographic integrity protection function.

If supporting signing is not important to anyone, OK. This seems like a
significant sacrifice, especially when positioned against the benefit of
adding but not removing <LF>s.

>> >> - Section 2.3 should clarify that malformed JSON text sequences are
>> >> not fatal (I.e., arriving at an RS without having seen a LF).
>> >
>> >That's covered in detail in section 2.4.  I wouldn't want to replicate
>> >any part of 2.4 in 2.3.
>> I don’t recall seeing any mention of malformed JSON text sequences. I
>> think you either get to a next <RS> or end of the stream.
>Section 2.3 actually says "malformed" in its first sentence.  It
>mentions truncation only as an example of why a JSON text might be
>malformed, in the second sentent.

I am making a distinction between failure to parse a JSON text and failure
to parse a JSON text sequence. I think the text only addresses the former.

>> [extensive discussion of the LF elided]

How can a decoder know that <RS>123<LF><RS> was what the originator
intended and not something that was terminated by the text sequence
encoder? The originator may have intended <RS>1234<ws><LF><RS>. There
seems to be some assumption that the supplier of JSON text may fail to
self-delimit but would not fail to supply the full value. It’s a contrived
example, but how should an incremental JSON parser handle texts returned
from a parser operating on the sequence: <RS>123<LF><RS>4<ws><LF><RS>?
Would it be two values 123 and 4 or one value 1234? Why is it not be
preferable to report an error here <RS>123<LF><RS> instead of trying to
auto-terminate it when encoding the sequence?

>> OK, though as noted above I still don’t see the need for adding the <LF>
>> in the encoder without removing it in the corresponding parser.
>There is no need to remove it in the sequence parser, though the
>sequence parser may do it.  The sequence parser need only reject
>top-level number/true/false/null values whose text did not end in a
>whitespace.  A sequence parser could do this by insisting that the
>sequence element end in an LF, and it can remove the trailing LF as well
>as leaving it in, as the trailing LF's presence (or absence) does not
>affect the validity of the JSON text to be parsed.

Is this universally true where JSON text is incrementally packaged into a
text sequence?

>Adding the LF in the sequence encoder does not hurt, since all JSON
>texts can end with arbitrary amounts of ws.  It merely helps delimit
>sequence elements, both to ensure that top-level numbers/true/false/null
>are delimited, and to help keep lines shorter for users using $PAGER and
>$EDITOR to view JSON text sequences.
>Delimiting otherwise non-self- delimiting texts is an important

I guess we just disagree on whether the text sequence encoder is
necessarily in a position to terminate data that may be incrementally
supplied or incompletely supplied by a caller and whether or not this
important function should be allocated to the caller instead of to the
JSON text sequence encoder.  One alternative would be to add a <ws> only
when a non-self-delimited text is passed to a non-incremental encoder,
then encode that altered value into the sequence (and terminate all
sequence elements with <RS> only).