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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 17 March 2016 23:51 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 0D5AA12D641; Thu, 17 Mar 2016 16:51:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 QPF_jlBRiFwU; Thu, 17 Mar 2016 16:51:34 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9D1812D5CD; Thu, 17 Mar 2016 16:51:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 205EFBE58; Thu, 17 Mar 2016 23:51:32 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HFmMZGivdIq; Thu, 17 Mar 2016 23:51:25 +0000 (GMT)
Received: from [10.87.48.75] (unknown [86.46.16.138]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3B524BE51; Thu, 17 Mar 2016 23:51:24 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458258684; bh=gXzC7KAVdq301oehrXqPvvAbuiFQCNPavkxlWWzI5Ps=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=gAByiHuMDbPQdKS0+q5p5nbSLxTiINA5yKjFraYJ95CVvyZfiBjcFjrzr52IQ+hwF f/s9UHvRhPFSA/+it0KjhIkMAZQ9NqkGgYlIO3c0ub6aP/NtlzQaUyUeZd5XUQ6387 ez2g9x9s+wxdeRmFUgxKQ3hiBHMNahlIq7Y07xtw=
To: Hilarie Orman <hilarie@purplestreak.com>
References: <201603172239.u2HMdFff018872@rumpleteazer.rhmr.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56EB42FB.9040006@cs.tcd.ie>
Date: Thu, 17 Mar 2016 23:51:23 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <201603172239.u2HMdFff018872@rumpleteazer.rhmr.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms010001080802020404070807"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/3bKUgC_3-bw4nWGigM2-9tzqexU>
Cc: lhotka@nic.cz, draft-ietf-netmod-yang-json.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Security review of draft-ietf-netmod-yang-json-08
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: Thu, 17 Mar 2016 23:51:37 -0000

Thanks Hilarie,

Ok, I'll take a peek again at the thread. For some reason
it was also daunting to me so I tried to re-delegate again,
I guess I find XML + anydata just off-putting as a concept;-)

Anyway, I'll get back tomorrow.

Cheers,
S.

On 17/03/16 22:39, Hilarie Orman wrote:
> It is difficult to feel that the generic dont-worry response ("knows
> what he or she is doing", "almost never", and "pay(s) attention to the
> data model", etc.)  is sufficient to address security concerns.  My
> review boils down to "surely you can do better", but I do not have the
> expertise to write specific text that would improve the situation.
> 
> Hilarie
> 
>>  From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
>>  Date: Thu, 17 Mar 2016 14:31:03 +0000
> 
>>  Hi folks,
> 
>>  This thread seemed to just trail off.
> 
>>  Hilarie, did you want to follow up more or do we think
>>  the document is all set?
> 
>>  Thanks,
>>  S.
> 
>>  On 08/03/16 15:31, Ladislav Lhotka wrote:
>>  > Hi Hilarie,
>>  >=20
>>  > thank you for the review, please se my responses inline.
>>  >=20
>>  > Hilarie Orman <hilarie@purplestreak.com> writes:
>>  >=20
>>  >>                      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
>>  >> comments.
>>  >>
>>  >> "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 n=
>>  odes
>>  >>      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 latt=
>>  er
>>  >>      case, converting JSON-encoded instances to the XML encoding defin=
>>  ed
>>  >>      in [I-D.ietf-netmod-rfc6020bis] may be impossible.
>>  >=20
>>  > An "anydata" node represents data for which no schema is specified in
>>  > the data model. The schema for such data may be known at run time, but
>>  > the consensus in the NETMOD WG was to keep the possibility that this is=
> 
>>  > not the case. And if the schema is not available, translation between
>>  > XML and JSON encodings cannot be done because, for example, we use the
>>  > data model info for translating namespace identifiers.
>>  >=20
>>  > As long as we want to keep the option of specifying schema-less data in=
> 
>>  > the data model, we have to live with this. I don't think it is really
>>  > ominous, also because normal configuration and state data should almost=
> 
>>  > never be modelled with "anydata".
>>  >=20
>>  >>
>>  >> 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 th=
>>  e
>>  >>    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."
>>  >=20
>>  > Implementors might be tempted to apply the Postel Principle and be
>>  > liberal on the receiving side. This paragraph warns against doing so,
>>  > unless, of course, the implementor knows what he or she is doing.
>>  >=20
>>  >>
>>  >> The security section refers back to the security considerations in
>>  >> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-11
>>  >> 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=
>>  =2E
>>  >>    Reading malformed documents from unknown or untrusted sources could=
> 
>>  >>    result in an attacker gaining privileges of the user running the YA=
>>  NG
>>  >>    parser.  In an extreme situation, the entire machine could be
>>  >>    compromised."
>>  >>
>>  >> 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
>>  >=20
>>  > In fact, it is one of the most important virtues of data modelling that=
> 
>>  > the correctness of configuration or state data can be reliably
>>  > verified. In the context of draft-ietf-netmod-yang-json, correctness ha=
>>  s
>>  > two aspects:
>>  >=20
>>  > 1. All data is required to be I-JSON compliant [RFC 7493] which helps
>>  >    avoid common JSON-specific interoperability and security problems.
>>  >=20
>>  > 2. The data model precisely specifies the schema, data types of all
>>  >    values, and also semantic constraints.
>>  >=20
>>  > If an implementor pays attention to data model definitions (including
>>  > textual descriptions), then I believe the risk of any data-induced
>>  > issues is effectively minimised.
>>  >=20
>>  >> 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.
>>  >>
>>  >=20
>>  > This question isn't specific to this document - sensitive data may be
>>  > present in any encoding. It is also one of the duties of a good data
>>  > model to identify such data, and sec. 6 in RFC 6087 puts forward specif=
>>  ic
>>  > requirements in this direction.
>>  >=20
>>  > Thanks, Lada