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

Nico Williams <nico@cryptonector.com> Wed, 17 December 2014 23:41 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 E31351A0045; Wed, 17 Dec 2014 15:41:20 -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 M6E_mTMA6Sma; Wed, 17 Dec 2014 15:41:19 -0800 (PST)
Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DF5721A001C; Wed, 17 Dec 2014 15:41:19 -0800 (PST)
Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id A15BF59807A; Wed, 17 Dec 2014 15:41:19 -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; s=cryptonector.com; bh=kFYA7eTt4r8cRI 3hTRXpiLpZ3xE=; b=NO2rAOnjiTeJdQHTrCZ1gSvGkw+UEQlJvZXkQ8ARMgItHX JDovSuNCUm8HJwtfVt+lqQ65ZBtBnOZWCjFVZymBC81YP+7xdsvupv/Mrvb0gjd9 aY+GKMa3Cg8/nj3vaQTSHXWGcxwaKz9IEOnKnWdBUYEEDVqUgdRzhXrGFJ948=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPA id 3D3B4598065; Wed, 17 Dec 2014 15:41:19 -0800 (PST)
Date: Wed, 17 Dec 2014 17:41:18 -0600
From: Nico Williams <nico@cryptonector.com>
To: Carl Wallace <carl@redhoundsoftware.com>
Message-ID: <20141217234113.GH9443@localhost>
References: <D0B587AB.2948E%carl@redhoundsoftware.com> <20141216163238.GT3241@localhost> <D0B5C964.2954A%carl@redhoundsoftware.com> <20141216174829.GZ3241@localhost> <D0B5DC2E.295DB%carl@redhoundsoftware.com> <20141216193707.GE3241@localhost> <D0B5F9D2.29691%carl@redhoundsoftware.com> <20141216213533.GI3241@localhost> <D0B64568.29705%carl@redhoundsoftware.com> <20141217185523.GA3241@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20141217185523.GA3241@localhost>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/5RFuufpzqtFS2_dWLRzLQzetnnA
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: Wed, 17 Dec 2014 23:41:21 -0000

On Wed, Dec 17, 2014 at 12:55:23PM -0600, Nico Williams wrote:
> On Tue, Dec 16, 2014 at 09:13:55PM -0500, Carl Wallace wrote:
> >                                          [...]. I still think the solution
> > is to remove the delimiters added by the JSON text sequence encoder in the
> > JSON text sequence decoder.  This seems cleaner to me.  It would probably
> > require the encoder to reject inputs that have not been properly
> > terminated or perhaps have a flag to auto-add <ws> to non-self-delimited
> > top level values before adding the <LF> where such is safe to do.
> 
> Tolerating a missing LF seems like a fine thing to do if the top-level
> value was nonetheless valid and delimited.
> 
> On the other hand it adds some ambiguity if some sequence parser
> implementations can tolerate it and others can't.

I continue to think that the best thing to do is have a recommendation
as to how to handle ambiguities, and point them out.

Therefore I don't think we should say that the parser MUST strip the
trailing LF, but SHOULD (or MAY not strip it) would be fine, and should
address the concern about alterations to JSON texts that can then affect
cryptographic integrity protection.

So, how about these changes to section 2.1:

    The ABNF [RFC5234] for the JSON text sequence parser is as given in
    Figure 1.

-     JSON-sequence = *(1*RS possible-JSON)
+     JSON-sequence = *(1*RS possible-JSON LF)
+     LF = %x0A; "line feed" (LF), see RFC20
      RS = %x1E; "record separator" (RS), see RFC20
               ; Also known as: Unicode Character 'INFORMATION SEPARATOR
               ;                TWO' (U+001E)
      possible-JSON = 1*(not-RS); attempt to parse as UTF-8-encoded
                                ; JSON text (see RFC7159)
      not-RS = %x00-1d / %x1f-ff; any octets other than RS

                      Figure 1: JSON text sequence ABNF

    In prose: a series of octet strings, each containing any octet other
-   than a record separator (RS) (0x1E) [RFC0020], all octet strings
-   separated from each other by RS octets.  Each octet string in the
-   sequence is to be parsed as a JSON text in the UTF-8 encoding
-   [RFC3629].
+   than a record separator (RS) (0x1E) [RFC0020], and each such octet
+   string prefixed by an RS octet and suffixed by an LF octet.  Each
+   octet string in the sequence is to be parsed as a JSON text in the
+   UTF-8 encoding [RFC3629].

    If parsing of such an octet string as a UTF-8-encoded JSON text
    fails, the parser SHOULD nonetheless continue parsing the remainder
    of the sequence.  The parser can report such failures to applications
    (which might then choose to terminate parsing of a sequence).
    Multiple consecutive RS octets do not denote empty sequence elements
    between them, and can be ignored.

+   JSON text sequence parsers MAY include the LF suffix (from the
+   sequence encoding) when parsing a JSON text sequence element, but it
+   is best not to when the sequence parser's output is the element JSON
+   texts rather than an internal representation of the parsed element
+   JSON texts.
+
    There is no end of sequence indicator.

?

Nico
--