Re: [secdir] secdir review of draft-ietf-json-rfc4627bis-07

Paul Hoffman <> Wed, 18 December 2013 16:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 179641AE1CA; Wed, 18 Dec 2013 08:35:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iPDLvFf8O2BE; Wed, 18 Dec 2013 08:35:22 -0800 (PST)
Received: from (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by (Postfix) with ESMTP id 65EF71AE180; Wed, 18 Dec 2013 08:35:22 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.7/8.14.7) with ESMTP id rBIGZD7n021033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Dec 2013 09:35:14 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Paul Hoffman <>
In-Reply-To: <>
Date: Wed, 18 Dec 2013 08:35:12 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Tobias Gondrom <>
X-Mailer: Apple Mail (2.1827)
Cc:, secdir <>,, The IESG <>
Subject: Re: [secdir] secdir review of draft-ietf-json-rfc4627bis-07
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: Wed, 18 Dec 2013 16:35:24 -0000

Greetings. I see that we did miss responding to you. We had a very hard time getting consensus in the WG leading to IETF Last Call, so we wanted to keep the changes after that to a minimum. Of your nits:

>>> Some small nits / thoughts (as comments, none of them a discuss): 
>>> - section 1: you briefly explain strings, objects and arrays. Do you maybe also want to make a brief statement about the range of allowed numbers or point towards section 6? (though this is not absolutely necessary as you discuss the data types in more detail in section 4-7).  

Our charter was to make as few changes to RFC 4627 as possible, so we left the original prose as-is unless it was actively wrong or caused interoperability issues.

>>> - section 12.  Security Considerations: 
>>> second paragraph: the point about the "eval()" function is a bit shallow, it might be useful to discuss this a bit more and to spell out what would be best practice instead of "use that language's "eval()" function to parse JSON texts." as that "generally constitutes an unacceptable security risk"

The WG didn't come up with any "best practice" other than "don't do that". RFC 4627 includes a (very wrong) example of how to fix the problem, and we didn't want to repeat the mistake of saying "but you might do X instead".

>>> - section 1 or 2: 
>>> it might be useful to spell out what exactly the most important changes are in comparison to 4627 and why. Or mention that this would be discussed in detail in Appendix A. 

In this WG, *every* change became important. :-( 

--Paul Hoffman