Subject: [Netconf] Adam Roach's No Objection on draft-ietf-netconf-rfc6536bis-07: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Wed, 25 Oct 2017 16:24:55 -0700

Adam Roach has entered the following ballot position for
draft-ietf-netconf-rfc6536bis-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc6536bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Quick note on Table 1:

   | HEAD    | all             | <get>               | N/A             |
   | GET     | all             | <get>               | N/A             |

Shouldn't these be "<get>, <get-config>" rather than just "<get>"?

----------------------------------------------------------------------

I'll note that there's a subtle OPTIONS-related attack here similar to what
Eric calls out regarding PUT and PATCH.

This document appears to put no access restrictions whatsoever on the use of
OPTIONS. RFC 8040, section 4.1 indicates that the answer can change based on
the "specific resource", while RFC7231, section 4.3.7 stipulates that "a
server's communication options typically depend on the resource." The risk here
is that the response to OPTIONS may vary based on the presence or absence of a
resource corresponding to the URL's path. If this is the case and if no access
control is applied to OPTIONS, then it can be used to trivially probe for the
presence or absence of values within a tree.

I believe there should be text either in section 3.2.3 or under the "Security
Considerations" section that warns implementations not to vary their OPTIONS
responses based on the existence of the underlying resource.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Oct 2017 17:20:47 -0700

> https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc6536bis/

I am updating the security considerations section

Andy