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

Carl Wallace <> Thu, 18 December 2014 12:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 559FF1A883B for <>; Thu, 18 Dec 2014 04:12:42 -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=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U-UZRHa_DuLu for <>; Thu, 18 Dec 2014 04:12:40 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 708C71A888B for <>; Thu, 18 Dec 2014 04:12:40 -0800 (PST)
Received: by with SMTP id r5so729256qcx.30 for <>; Thu, 18 Dec 2014 04:12:39 -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=2/6MHDUmDfuPOxXZHoskLiG7VZUgnvgmVEq5jULxeDw=; b=ZLKZlsAq7pVEpnjoYRNITckEWe2oC8AnV8pxwxGJwaITKdrcdbifnzDnKEJ79chz1V uvuB1HAjUIUM9eDQu4DSvzfj+RmFLemgBxuBtKTfIVAVuJJdRhQ21LwYGnAHZ0osoNDq ABb7ZJbAYStls2JWmMpbPTv8HqMgoL+nCJaUlsL33e/WM8xHHCFhwLbb4oVFFRHDJ9iw tUKu5ytY1Ii984Fl6XZ78HMTXFcmHDUwOmjYncKbdhu0tx5hxSrAyfNyuCyhmoTArxS3 WX20aoLY4UmuxqJ3N3KyUwkjBO2edIwnqRUViwgCZOrEAn06jh2gb3aqBfF7PDsb0ZcZ t70A==
X-Gm-Message-State: ALoCoQlzKBfNL72BFKNUe0qhw9w0zzOTrU9J6HNzPB1UOTqoQ+npYavlRuf7q4s10GIKpiLQr5Cg
X-Received: by with SMTP id r5mr2902970qch.28.1418904759522; Thu, 18 Dec 2014 04:12:39 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id k11sm6591031qgf.18.2014. (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Dec 2014 04:12:39 -0800 (PST)
User-Agent: Microsoft-MacOutlook/
Date: Thu, 18 Dec 2014 07:12:34 -0500
From: Carl Wallace <>
To: Nico Williams <>
Message-ID: <>
Thread-Topic: [secdir] secdir review of draft-ietf-json-text-sequence-11
References: <> <20141216163238.GT3241@localhost> <> <20141216174829.GZ3241@localhost> <> <20141216193707.GE3241@localhost> <> <20141216213533.GI3241@localhost> <> <20141217185523.GA3241@localhost> <20141217234113.GH9443@localhost>
In-Reply-To: <20141217234113.GH9443@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: Thu, 18 Dec 2014 12:12:42 -0000

On 12/17/14, 6:41 PM, "Nico Williams" <> wrote:

>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
>> > 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
>> > require the encoder to reject inputs that have not been properly
>> > terminated or perhaps have a flag to auto-add <ws> to
>> > 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.

The suggestion is not to tolerate a missing <LF> but to not always add
them in the text sequence encoder in the first place. The <LF> addition
would essentially be an extension of the JSON text encoder (albeit
implemented in the text sequence encoder).  There would be no ambiguity.
The parser would always leave it in. Where integrity mechanisms are used,
the auto-<LF> would need to be turned off and the source responsible for
properly terminating inputs to the text sequence encoder.

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

Thinking more about stripping out the <LF>, that won’t always work either
for the same reason you have the parser reject non-self-delimited texts
that do not end with a <LF>. The text sequence encoder could terminate
before the <LF> is written possibly leaving a <LF> added by the source
exposed (and removed by a decoder). The parser really can’t know if the
JSON encoder or JSON text sequence encoder added a trailing <LF>.