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

Benjamin Kaduk <kaduk@mit.edu> Wed, 08 March 2017 03:30 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B90129480; Tue, 7 Mar 2017 19:30:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUhQ77D-etSr; Tue, 7 Mar 2017 19:30:40 -0800 (PST)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D91F129469; Tue, 7 Mar 2017 19:30:40 -0800 (PST)
X-AuditID: 1209190c-6c7ff70000005cc1-9f-58bf7add58da
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (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 outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v283UbdT026028; Tue, 7 Mar 2017 22:30:37 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (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, 07 Mar 2017 21:30:33 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Barry Leiba <barryleiba@computer.org>
Message-ID: <20170308033033.GI30306@kduck.kaduk.org>
References: <20170308014823.GF30306@kduck.kaduk.org> <CAC4RtVBJU80fKw+eqBXbvCmXy=k8fyu5d_x_KqoHZYp6Mp62FQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAC4RtVBJU80fKw+eqBXbvCmXy=k8fyu5d_x_KqoHZYp6Mp62FQ@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/secdir/c7PNBMaXSElcXq-QLdj6rvort38>
Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, IETF discussion list <ietf@ietf.org>, secdir <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-jsonbis-rfc7159bis-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: 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.

-Ben