Re: [secdir] secdir review of draft-ietf-jsonbis-rfc7159bis-03

Benjamin Kaduk <> Wed, 08 March 2017 03:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1B90129480; Tue, 7 Mar 2017 19:30:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sUhQ77D-etSr; Tue, 7 Mar 2017 19:30:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1D91F129469; Tue, 7 Mar 2017 19:30:40 -0800 (PST)
X-AuditID: 1209190c-6c7ff70000005cc1-9f-58bf7add58da
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 72.52.23745.DDA7FB85; Tue, 7 Mar 2017 22:30:38 -0500 (EST)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id v283UbdT026028; Tue, 7 Mar 2017 22:30:37 -0500
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id v283UXJs001011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Mar 2017 22:30:36 -0500
Date: Tue, 7 Mar 2017 21:30:33 -0600
From: Benjamin Kaduk <>
To: Barry Leiba <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsUixCmqrHuvan+EwbZVQhaHFl9itZj17Aej xbON81ksPix8yOLA4tGyqpfZY8mSn0wBTFFcNimpOZllqUX6dglcGZtWtjEV/Beu+H33LXsD 4x/+LkZODgkBE4m/t54xdTFycQgJtDFJHNzZxgaSEBLYwCix6wEvROIKk8TZ6c3sIAkWARWJ 0zP+sYLYbEB2Q/dlZhBbREBT4vnnKUwgNrNAucSRU9vB6oUF3CV2nf8EFOfg4AXa9mazBsT8 aokra6aBtfIKCEqcnPmEBaJVS+LGv5dg5cwC0hLL/3GAhDkFAiU27loPViIqoCzRMOMB8wRG gVlIumch6Z6F0L2AkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrqFebmaJXmpK6SZGcNhK8uxg PPPG6xCjAAejEg+vx9l9EUKsiWXFlbmHGCU5mJREeQ9m7o8Q4kvKT6nMSCzOiC8qzUktPsQo wcGsJMLbbgmU401JrKxKLcqHSUlzsCiJ80poNEYICaQnlqRmp6YWpBbBZGU4OJQkeBsrgRoF i1LTUyvSMnNKENJMHJwgw3mAhreB1PAWFyTmFmemQ+RPMSpKifNeqgBKCIAkMkrz4HpBaUUi e3/NK0ZxoFeEeQ+AtPMAUxJc9yugwUxAg7Vd94IMLklESEk1MMZtUV8ZXJXCphC01XTy4ldn pwXI37knsOVamFZQ307tAwfuMH4PTFrPGLbUhEvf6LnK098+P2Y/05zLsT3wtLrS1OLEtd8e iWxt37s4w3Hjo8zHl0VVb1RYKGknL/jlu8ZPaael5px7b7hu25iKWDwRz5l24QzTwpyHiVVf UgN/CB6Q698pOVeJpTgj0VCLuag4EQDC+67mBgMAAA==
Archived-At: <>
Cc:, IETF discussion list <>, secdir <>
Subject: Re: [secdir] secdir review of draft-ietf-jsonbis-rfc7159bis-03
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Mar 2017 03:30:42 -0000

Hi Barry,

On Tue, Mar 07, 2017 at 09:52:37PM -0500, Barry Leiba wrote:
> Hi, Ben.
> A note on the Internationalization points:
> > I'm also concerned about the freewheeling use of Unicode.  While
> > this document does discuss the potential encodings and lists UTF-8
> > as the default (and most interoperable), I think it would benefit
> > from a stricter warning that parties using JSON for communication
> > must have some out-of-band way to agree on what encoding is to be
> > used.  I would expect that this is usually going to be done by the
> > protocol using JSON, but could see a place for the actual
> > communicating peers to have out-of-band knowledge.  (An application
> > having to guess what encoding is being used based on heuristics is a
> > recipe for disaster.)
> >
> > Additionally, the document makes no mention of Unicode
> > normalization, which can be a minefield.  The precis working group
> > has a lot of work in this area, from which the executive summary is:
> > it's a lot of work to do things correctly, and being sloppy usually
> > leads to vulnerabilities.  The most obvious issue would be in (the
> > comparison of) field names using strings that can be represented
> > differently in different normalization forms (for example, e with
> > acute accent), which can be either U+00e9 or U+0064 and the
> > combining character U+0301.  Simply converting to Unicode code
> > points is insufficient for an implementation to cause those strings
> > to compare as equivalent.  I think this document should at least
> > mention that Unicode normalization forms exist and should be
> > considered by protocol designers when using JSON with characters
> > outside of US-ASCII.
> I believe that all of this is the realm of the protocol *using* JSON,
> and doesn't belong in the JSON spec itself.  The JSON spec makes it
> clear what the encoding options are, and leaves things such as the set
> of allowed characters (and any restrictions on them), the
> normalization and canonicalization, and the comparison rules to the
> next level... and I believe that's how it should be.  Different uses
> of JSON will have different needs in these regards, and *those*
> specifications are the right places to say that.

I agree that it is appopriate for the JSON spec to merely list out the
options and leave decisions to the consuming applications/protocols.
However, it seems irresponsible to not mention that those designing
such protocols should be aware of the potential issues.