Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03

Tom Yu <> Fri, 26 February 2016 01:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C75EC1A0199; Thu, 25 Feb 2016 17:01:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7sICxYQpbdvh; Thu, 25 Feb 2016 17:01:38 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E5DE1A0174; Thu, 25 Feb 2016 17:01:38 -0800 (PST)
X-AuditID: 12074423-5c3ff70000006586-9c-56cfa3f17a86
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id EC.C9.25990.1F3AFC65; Thu, 25 Feb 2016 20:01:37 -0500 (EST)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id u1Q11anj029879; Thu, 25 Feb 2016 20:01:36 -0500
Received: from localhost ( []) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id u1Q11Ym1008474; Thu, 25 Feb 2016 20:01:35 -0500
From: Tom Yu <>
To: Mahesh Jethanandani <>
References: <> <>
Date: Thu, 25 Feb 2016 20:01:33 -0500
In-Reply-To: <> (Mahesh Jethanandani's message of "Mon, 15 Feb 2016 13:28:40 -0800")
Message-ID: <>
Lines: 59
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUixG6nrvtx8fkwg8lTuCweHG5hs5jxZyKz xek369gsPix8yOLA4rFz1l12jyVLfjJ5fLn8mS2AOYrLJiU1J7MstUjfLoErY+b130wFM8Uq Lk39wdLA2C3UxcjJISFgInH1w2nmLkYuDiGBNiaJWd8Xs0A4GxklHjYdYAKpEhJ4wyix7IU5 iM0mIC1x/PIusLiIgKHEqQMvwGxmgTyJsx/egdnCAg4SO8+vY4ToTZDYde0MK4jNIqAq0X96 LhPIAk6BFkaJ/uWnwRK8AroSbS1vgTZzcPAIcEosWRoPERaUODnzCQvEfC2JG/9eMk1g5J+F JDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXTO93MwSvdSU0k2M4LB0Ud7B+Oeg0iFG AQ5GJR5ehp9nw4RYE8uKK3MPMUpyMCmJ8gbOPR8mxJeUn1KZkVicEV9UmpNafIhRgoNZSYT3 chlQjjclsbIqtSgfJiXNwaIkzhtz82iYkEB6YklqdmpqQWoRTFaGg0NJgnfFIqBGwaLU9NSK tMycEoQ0EwcnyHAeoOECi0GGFxck5hZnpkPkTzEqSonzmoM0C4AkMkrz4HrBaUOIcd8rRnGg V4R580GqeIApB677FdBgJqDBMzecAxlckoiQkmpgNGpOdxavSUuccfGGLM8FDrnNbv+dq9+c DLgjonY29d2yX5ovr13LXrjyxpFX3zsuCsn5nReR+bI06HqGq7xZUkN063nXc40nPu/NZc96 s7HCPmtd9a+ZKeLHljArdh0Prb00xdkvlkf5y8NvkgZWW4pt581bcuKL9qO6BVd2yVe7B29V nSlZqMRSnJFoqMVcVJwIAIeX6o/2AgAA
Archived-At: <>
Cc:, The IESG <>,
Subject: Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Feb 2016 01:01:40 -0000

Hi Mahesh,

Sorry about the delay.

I was looking at the specific comments in the Security Considerations of
this document about the sensitivity of the contents of /modules/module.
How do the risks of an attacker being able to inspect /modules/module
compare with other information that could be available to an attacker,
such as fingerprinting through non-NETCONF means?

If an attacker has limited NETCONF access on a server, what would the
contents of /modules/module reveal to the attacker that might not
otherwise be discovered by other kinds of probing within the NETCONF

These other risks might be trivial in comparison to the one mentioned in
the document, but lacking specific knowledge of the broader context of
NETCONF and how it is deployed, I'm not sure how they compare.  For
example, is it expected that anonymous or minimally trusted users could
be authorized to use NETCONF to access some public information about a

If these other risks are similar in magnitude to the possible exposures
allowed by /modules/module, you should consider mentioning them, and
give the implementor or operator some guidance about how to weigh these
risks.  If the exposures allowed by /modules/module vastly outweigh
those from other avenues of obtaining similar capability or
configuration information, in most environments and forseeable
deployments, maybe the current text is sufficient.


Mahesh Jethanandani <> writes:

> Tom,
> It is not entirely clear from this e-mail, what action you want the authors to take. 
> YANG module information or more like its encodings are sent over a secure session (SSH/TLS) and are no more specific to this draft than they are to any NETCONF/RESTCONF session. As such it is not clear what you want  the authors to do. Could you clarify or provide text for the Security Consideration section?
> Thanks.
>> On Feb 1, 2016, at 6:03 PM, Tom Yu <> wrote:
>> 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.
>> The Security Considerations of this document seem reasonable.  It might
>> be useful to add a comparison of the risks posed by sensitive
>> information exposed by this YANG module with information exposed by
>> other aspects of NETCONF, or available through methods such as
>> fingerprinting.  Admittedly, a meaningful comparison might be highly
>> context-specific, so a general comparison might have limited utility.
> Mahesh Jethanandani