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

Nico Williams <nico@cryptonector.com> Tue, 16 December 2014 16:32 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47C31A1BEC; Tue, 16 Dec 2014 08:32:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkqnXX6kmgFl; Tue, 16 Dec 2014 08:32:43 -0800 (PST)
Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 97FD51A1BE7; Tue, 16 Dec 2014 08:32:43 -0800 (PST)
Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 5E16720047B89; Tue, 16 Dec 2014 08:32:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=4hMu9oTSxBLkrgbUDDoOaLHHQ20=; b=iGEsr2CRJCo FRJs9Xv3yOZWF+Lhyiaba3QQNogeZ8PKqcxWFqbQVQ6xXtvJG+UQiue1TZxejmPZ Czz3sy/1+cBH7Uz9VHQv9qT74YYFrFV3tp0uJ8x7kv6frx0tkFyU9NTDquSGsDuK gYfTEULVcr9nn3Yt5Jx0I9rWoTtafCYs=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id E95AA20047B88; Tue, 16 Dec 2014 08:32:42 -0800 (PST)
Date: Tue, 16 Dec 2014 10:32:42 -0600
From: Nico Williams <nico@cryptonector.com>
To: Carl Wallace <carl@redhoundsoftware.com>
Message-ID: <20141216163238.GT3241@localhost>
References: <D0B1EECD.29290%carl@redhoundsoftware.com> <20141216000109.GP3241@localhost> <D0B587AB.2948E%carl@redhoundsoftware.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <D0B587AB.2948E%carl@redhoundsoftware.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/xRAOppTow83YEjiHEm5ztOtusp8
Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Dec 2014 16:32:44 -0000

On Tue, Dec 16, 2014 at 07:51:32AM -0500, Carl Wallace wrote:
> On 12/15/14, 7:01 PM, "Nico Williams" <nico@cryptonector.com> wrote:
> ><snip>
> >> 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
> >
> >Though it turns out that RFC7159's security considerations section was
> >probably too brief.  Anyways.
> 
> Seems a good place to augment since you have noticed shortcomings.

Indeed.

> >> [...]
> >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
like:

   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.

> >> - 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).
> >
> >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.

There is also mention of malformed JSON texts in section 2.4 (explaining
why 'true' must not be produce upon merely consuming the 'e' in it, as
the next octet might not be a ws, nor RS).

Here's the proposed change:

OLD:
2.3.  Incomplete JSON texts are not fatal

NEW:
2.3.  Incomplete or malformed JSON texts are not fatal

(and s/textm/text,/)


> >> - 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.
> >
> >Are you thinking of a a sequence like <RS> <JSON-text-w/o-trailing-LF>
> ><JSON-text> ... being parsed as two JSON texts?
> 
> I was thinking more like <RS> <some fraction of JSON possibly a single
> character>.

The ABNF for encoding assumes proper operation, yes.  The parser ABNF
takes care of malformed JSON texts.  This may be a simplification, but I
think it's a useful one.

> >Or are you thinking of a <RS> <JSON-text-containing-RS> <LF>?
> >
> >The latter must yield a parse error from the JSON text parser.
> >
> >As to the former... I think I'd thought about it and left it as-is,
> >though I can't recall why, with the security considerations text about
> >smuggling being sufficient (except it's not quite).
> >
> >How about this new text:
> >
> >   After reading and parsing a JSON text, the sequence parser MUST skip
> >   to the RS byte following the JSON text (or terminate if at end of
> >   input).
> 
> I think this text would be a nice addition. I noticed the lack of calling
> out "read until end if no <RS>" but it seemed implied.

OK.

> [extensive discussion of the LF elided]
>
> 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.

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
function.

Nico
--