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

Carl Wallace <carl@redhoundsoftware.com> Tue, 16 December 2014 17:20 UTC

Return-Path: <carl@redhoundsoftware.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 7B1EE1A6FFC for <secdir@ietfa.amsl.com>; Tue, 16 Dec 2014 09:20:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zl_PAS7vhKgm for <secdir@ietfa.amsl.com>; Tue, 16 Dec 2014 09:20:44 -0800 (PST)
Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5DC1A7001 for <secdir@ietf.org>; Tue, 16 Dec 2014 09:20:14 -0800 (PST)
Received: by mail-qg0-f47.google.com with SMTP id q108so8475785qgd.34 for <secdir@ietf.org>; Tue, 16 Dec 2014 09:20:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.224.7.197 with SMTP id e5mr67068908qae.71.1418750413411; Tue, 16 Dec 2014 09:20:13 -0800 (PST)
Received: from [192.168.2.39] (pool-173-79-132-199.washdc.fios.verizon.net. [173.79.132.199]) by mx.google.com with ESMTPSA id r16sm1364509qay.10.2014.12.16.09.20.10 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Dec 2014 09:20:12 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.4.3.140616
Date: Tue, 16 Dec 2014 12:20:08 -0500
From: Carl Wallace <carl@redhoundsoftware.com>
To: Nico Williams <nico@cryptonector.com>
Message-ID: <D0B5C964.2954A%carl@redhoundsoftware.com>
Thread-Topic: [secdir] secdir review of draft-ietf-json-text-sequence-11
References: <D0B1EECD.29290%carl@redhoundsoftware.com> <20141216000109.GP3241@localhost> <D0B587AB.2948E%carl@redhoundsoftware.com> <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
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Y6lnDL-KtKm1g-GaEEhf4wTT8SU
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 17:20:49 -0000

On 12/16/14, 11:32 AM, "Nico Williams" <nico@cryptonector.com>; wrote:

><snip>
>> >> [...]
>> >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.

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

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.

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

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

>
>Nico
>--