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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 067151A87B8 for <>; Tue, 16 Dec 2014 12:44:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9kBHPCsYoV10 for <>; Tue, 16 Dec 2014 12:44:13 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4FE301A87A3 for <>; Tue, 16 Dec 2014 12:44:13 -0800 (PST)
Received: by with SMTP id e89so10628806qgf.24 for <>; Tue, 16 Dec 2014 12:44:12 -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=ico8deUiK2k0TK0LwpeGBtSpTQ5qwr7AKuxiu6x/zwA=; b=M8FERo0qDihCs5+XjfffmoR5FrpcURpGSMv8Sp/8C96VIzbdaBQVoCT5rT7c6WfLIn /6LGWB3h3AhKlEOPHfNU/xNE8N9m25OfsytIKlsl1Ep8h8cwMIc+eEATmTbPr++JcBDs fVzlCa3S+LZN8XqJ4UHkJLLR2d+4wxM7EL+eE9wZEiNtwUB4eUiDnamsQ+4D1kbriva9 YKRx3o6WMBCt1FSxkMpU3g+WCV2LVl9va6ZnAAHes6SJWgrB7QTP8Wex/zolUKBtEdwC DXzHJwdjWOsphl/rlm2C9jiZ6u+29Lm1CixWJDSfOIekx9Ci2sFQSdP2MhUSOwkyXXrR wNIA==
X-Gm-Message-State: ALoCoQmyNXQBk1EKbNStYHdix2/vZ0GP8zVSuWF6g2lH2jUnEQY5AdhdveVZytiwz55he64QVv92
X-Received: by with SMTP id g92mr66700872qge.77.1418762652541; Tue, 16 Dec 2014 12:44:12 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id t2sm1887282qae.6.2014. (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Dec 2014 12:44:11 -0800 (PST)
User-Agent: Microsoft-MacOutlook/
Date: Tue, 16 Dec 2014 15:44:05 -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> <> <20141216174829.GZ3241@localhost> <> <20141216193707.GE3241@localhost>
In-Reply-To: <20141216193707.GE3241@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 20:44:15 -0000

On 12/16/14, 2:37 PM, "Nico Williams" <> wrote:

>Although such an encoder is not considered in the I-D, we could add some
>text about it.  I'd rather say: don't do that, always encode the JSON
>texts to encode the JSON text sequence.
>><snip>>Of course a properly functioning encoder on a properly function
>> >is in a position to terminate each element.  How can this be in doubt?
>> The JSON text encoder may be on one system and the JSON text sequence
>> encoder may be on another system (one of the examples in the draft is
>> logs, so this must already be assumed as possible). In the example
>> if the text encoder fails after sending 123, the text sequence encoder
>> will add an <LF> and a decoder will not detect truncation. How can this
>> in doubt?
>It's not.  I just don't think one should encode JSON text sequences this
>way.  After lunch I'll propose text explicitly requiring sequence
>encoders to also invoke the JSON text encoder.

Most of the words in this now very long thread stem from this. I will wait
to review new text. I don’t think there is any lack of clarify on the
signature issue. Most of the remainder is related to the document’s
recognition of <RS>123<RS> as a detachable truncation problem but not
<RS>123<LF><RS> where the truncation occurred prior to invoking the
sequence encoder.