[secdir] Security review of draft-ietf-netmod-yang-json-08

"Hilarie Orman" <hilarie@purplestreak.com> Mon, 07 March 2016 22:16 UTC

Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@ietfc.amsl.com
Delivered-To: secdir@ietfc.amsl.com
Received: from localhost (localhost []) by ietfc.amsl.com (Postfix) with ESMTP id CEA751CDC8A; Mon, 7 Mar 2016 14:16:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.52
X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_12LTRDOM=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfc.amsl.com []) (amavisd-new, port 10024) with ESMTP id iYtItUGGm4rU; Mon, 7 Mar 2016 14:16:25 -0800 (PST)
Received: from out01.mta.xmission.com (out01.mta.xmission.com []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id B30F71CDC89; Mon, 7 Mar 2016 14:16:25 -0800 (PST)
Received: from in01.mta.xmission.com ([]) by out01.mta.xmission.com with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <hilarie@purplestreak.com>) id 1ad3Rw-0007u7-OK; Mon, 07 Mar 2016 15:16:24 -0700
Received: from [] (helo=rumpleteazer.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from <hilarie@purplestreak.com>) id 1ad3Rp-0005yS-Hw; Mon, 07 Mar 2016 15:16:24 -0700
Received: from rumpleteazer.rhmr.com (localhost []) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u27MG1TU002862; Mon, 7 Mar 2016 15:16:01 -0700
Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id u27MG09g002861; Mon, 7 Mar 2016 15:16:00 -0700
Date: Mon, 7 Mar 2016 15:16:00 -0700
Message-Id: <201603072216.u27MG09g002861@rumpleteazer.rhmr.com>
From: "Hilarie Orman" <hilarie@purplestreak.com>
To: iesg@ietf.org, secdir@ietf.org
X-XM-AID: U2FsdGVkX1/ATdbxDuUcjwhjcQuzef4Y
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ***;iesg@ietf.org, secdir@ietf.org
X-Spam-Timing: total 6693 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 3.2 (0.0%), b_tie_ro: 2.2 (0.0%), parse: 0.66 (0.0%), extract_message_metadata: 16 (0.2%), get_uri_detail_list: 2.3 (0.0%), tests_pri_-1000: 3.2 (0.0%), tests_pri_-950: 1.37 (0.0%), tests_pri_-900: 1.07 (0.0%), tests_pri_-400: 27 (0.4%), check_bayes: 26 (0.4%), b_tokenize: 7 (0.1%), b_tok_get_all: 10 (0.2%), b_comp_prob: 2.6 (0.0%), b_tok_touch_all: 2.9 (0.0%), b_finish: 0.76 (0.0%), tests_pri_0: 670 (10.0%), check_dkim_signature: 0.69 (0.0%), check_dkim_adsp: 266 (4.0%), tests_pri_500: 5968 (89.2%), poll_dns_idle: 5962 (89.1%), rewrite_mail: 0.00 (0.0%)
X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600)
X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/zH2QiTyMLB1rIOJWw-HHXEd_zZQ>
Cc: draft-ietf-netmod-yang-json.all@tools.ietf.org
Subject: [secdir] Security review of draft-ietf-netmod-yang-json-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Hilarie Orman <hilarie@purplestreak.com>
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: Mon, 07 Mar 2016 22:16:27 -0000

                     Security review of
JSON Encoding of Data Modeled with YANG draft-ietf-netmod-yang-json-08

Do not be alarmed.  I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the security area directors.  Document editors and
WG chairs should treat these comments just like any other last call

"This document defines encoding rules for representing configuration,
state data, parameters of RPC operations or actions, and notifications
defined using YANG as JavaScript Object Notation (JSON) text.  YANG is
a data modeling language originally designed to model configuration
and state data manipulated by the Network Configuration Protocol
(NETCONF), NETCONF remote procedure calls, and NETCONF notifications."

I have no specific recommendation for an action on this, just
some observations.

I'm not an expert on YANG, JSON, or XML, but I was taken aback to read
in section 5.5:

     Anydata data node serves as a container for an arbitrary set of nodes
     that otherwise appear as normal YANG-modeled data.  A data model for
     anydata content may or may not be known at run time.  In the latter
     case, converting JSON-encoded instances to the XML encoding defined
     in [I-D.ietf-netmod-rfc6020bis] may be impossible.

That seems ominous, and there are other warnings about the force
fitting of JSON and XML:

   "JSON processing is rather different from XML, and JSON parsers may
   thus suffer from other types of vulnerabilities than their XML
   counterparts.  To minimize these new security risks, software on the
   receiving side SHOULD reject all messages that do not comply to the
   rules of this document and reply with an appropriate error message to
   the sender."

The security section refers back to the security considerations in
section 16 (should be 17) where we read:

   "Data modeled in YANG might contain sensitive information.  RPCs or
   notifications defined in YANG might transfer sensitive information."

   "YANG parsers need to be robust with respect to malformed documents.
   Reading malformed documents from unknown or untrusted sources could
   result in an attacker gaining privileges of the user running the YANG
   parser.  In an extreme situation, the entire machine could be

There being no succinct description of correctness of YANG, JSON, or
XML for NETCONF data, how would one determine that any of it,
including mappings from one to another, was "robust"?  If that simply
means "doesn't cause a buffer overflow or crash", I suppose it's
achievable (and should be explicit).  But how could anyone be sure
that sensitive data was not leaked without a full analysis of the
specifications of all the component parts?  Perhaps this is an
unaddressable question, but one does hope that the extreme situation
does not occur.