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

Barry Leiba <> Wed, 08 March 2017 02:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66C97128B37; Tue, 7 Mar 2017 18:52:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J198sQIeTZK1; Tue, 7 Mar 2017 18:52:39 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D434120724; Tue, 7 Mar 2017 18:52:39 -0800 (PST)
Received: by with SMTP id h10so83890375ith.1; Tue, 07 Mar 2017 18:52:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wJOp1LVW4UtJRSWiIUfPM+7tXGn2Q6qPgP1YEk6n1uk=; b=JhV8puMkw8F3nSDNDOo3jmz24ZhUgYiTkbqHsQ4ZF6KOoteqo7HmFLsc6xInxy4CdK Brp/v1MyjHtf+0zvJHG1h+Zc/goqH54EJULM/ajFll6MvsbNONT7xikQv9QQBTR06G+5 wRzLIqqxa4sW5jQt36NuVGdrHtdI9n+ZeAokLLji2Y+yFIAzBomAoN23Er1yL4wi7UcB qxZsIo6Kh6lv9+pQ5naoK1Qm75RC+jsLfIJKViHLIC7V17mGys+5nUWCKPBjDeK3lJXq pGg7Huj9Ct25grbKpv5BOWAJtUPApabHfnPiObqkjs1rdY0K9yxrnzOxk2tRLdFdGJ+A aolA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wJOp1LVW4UtJRSWiIUfPM+7tXGn2Q6qPgP1YEk6n1uk=; b=Iu0jDuvn+IlaKrBbSU3+D3NxF0iArUIKqGmRYWer/dJFN9zODfoZbCsK8ckKnYUmyy HPBTKixBdE80zcPMya+TGeuMJ3gggV127vLxevqATevC64CiwGD1SyMDAHk/dBaRrC4I KyjNPyrsEbVT935tpJiLbgjtJSonKMTnnPccmx+ZV6KTvMOZaV9w4VED99fwIH2WHAr2 DjAq6Dzct4N+foQCZRl5j1Bzc9jXiSC9FB7Ep7TIpH6yf2QB6u4uTK8JQ1YW0lU+4N8z 8Vnaed/qRto7u6MnM/mWeNkvhDbkXvUtibEhilz2NWHB014+WKXcJrFhic77czkPoNkW /hCg==
X-Gm-Message-State: AMke39nwtKApka7s1sqn7iHM4WC7bF2y+QXSpPay+gHNLUEcUG2ytcMjcDKHGfNXGbn8nzwN5kbRsLTYN27P3A==
X-Received: by with SMTP id m123mr4321768ite.120.1488941558346; Tue, 07 Mar 2017 18:52:38 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 7 Mar 2017 18:52:37 -0800 (PST)
In-Reply-To: <>
References: <>
From: Barry Leiba <>
Date: Tue, 7 Mar 2017 21:52:37 -0500
X-Google-Sender-Auth: OY5Elvczs5e1sNmTDoLMMtjd1is
Message-ID: <>
To: Benjamin Kaduk <>
Content-Type: text/plain; charset=UTF-8
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 02:52:40 -0000

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.