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 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 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. 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 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 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.