Subject: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-rfc6020bis-12: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 18 May 2016 03:51:37 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-netmod-rfc6020bis-12: 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-netmod-rfc6020bis/

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

- I'm not sure I properly understand what the rpc and action
statements really do, but can an action statement result in
sensitive information being in a place in the model that
previously only contained non-sensitive information? If so,
does that warrant a mention in the security considerations,
like the existing one about RPCs? (I mean the 3rd para of
section 17.) 

- anydata (section 7.10) is new, right? Doesn't that mean
that new kinds of stuff (that might be dangerous) can be
found in a module? So if it's true that before yang 1.1 a
parser only had to be careful to parse XML correctly, and if
the addition of anydata means that a parser (via some
extension mechanism) might now be parsing say images, (say
via ImageMagick:-) then that'd likely create new potential
vulnerabilities and might be worth a mention in section 17.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 May 2016 14:18:49 +0200

> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/

They define a signature of an RPC call. The rpc statement defines a
global RPC while an action defines an RPC that is tied to some data
object (a method in OO slang but YANG is not OO). Are RPC special from
a privacy perspective? I do not know, I guess multiple answers are
valid here (including no they aren't since they are not worse than
other YANG defined data objects but of course you can define RPCs that
are bad form a privacy perspective but this is equally true for
regular data objects or notifications so I am not sure RPCs are in any
way special).
 
> vulnerabilities and might be worth a mention in section 17.

YANG defined data can be encoded in XML (the original encoding) but
also in JSON and people are working on CBOR. In YANG 1 we had anyxml,
which is problematic with other encodings since it is 'any XML' not
not 'any YANG-defined data' and hence we now have anydata, which means
'any YANG-defined data'. This means anydata is a subset of anyxml if
you use XML encoding. anydata is more restictive than anyxml and no it
anydata does not open the floor to let parsers parse image format or
anything like that.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 18 May 2016 16:39:39 +0200 (CEST)

> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/

I think you are right, and we should do:

OLD:

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

NEW:

  Data modeled in YANG might contain sensitive information. RPCs, actions,
  and notifications defined in YANG might transfer sensitive information.

/martin