Subject: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 17 Mar 2016 04:33:47 -0700

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

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

- I would have thought that it'd be useful to point out any
issues with round-tripping, e.g. going from XML to JSON and
back to XML or vice-versa. But I didn't see any mention of
that. How come?

- I'm not sure if anyone has considered XMLDSIG or use of JOSE
with YANG. If one did, then this kind of mapping would not
allow one to preserve digital signatures without a lot of
work. I assume that that's considered ok. (Which it can be,
depending on how one does object level security, if one does
object level security.)

- It's not clear to me if the discussion of the secdir review
[1] concluded. It seemed to just stall. Is there more to be
said? (If so, be great if the shepherd would kick that
discussion.)

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06408.html

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Mar 2016 16:07:07 +0100

Hi Stephen,

thanks for your comments, please see my responses inline.

I believe fifth paragraph in sec. 3 is what you are asking for:

   With the exception of anyxml and schema-less anydata nodes, it is
   possible to map a JSON-encoded data tree to XML encoding as defined
   in [I-D.ietf-netmod-rfc6020bis], and vice versa.  However, such
   conversions require the YANG data model to be available.

> depending on how one does object level security, if one does

I am not an expert on digital signatures and their representations, but
I'd say they could be modelled as YANG's "binary" type (and transferred
base64-encoded). This should work equally well in XML and JSON,
including round trips.

> said? (If so, be great if the shepherd would kick that

I don't have much more to say without seeing alternative proposals.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Mar 2016 16:19:14 +0100

> base64-encoded). This should work equally well in XML and JSON,

Lada, I think Stephen asks about JSON encoded YANG-defined data that
is signed, that is, the JSON serialization itself is signed. What
happens to the signature if you convert the JSON to corresponding XML
serialization. I think the answer is that the signature is broken in
this case and I think this is quite natural.

Object signatures so far never came up in the NETCONF/YANG context
(well not quite correct, I think there is some related discussion
aroud the zero-config draft) but even if they do, I think we will have
to accept that signatures are encoding specific. And I think this is
not a big deal; if I sign my HTML encoded email, then the signature
likely won't apply to a text-only rendering of the same email.

/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: Eliot Lear <[email-masked]>
Date: Mon, 21 Mar 2016 16:30:03 +0100

> likely won't apply to a text-only rendering of the same email.

However this goes, it should be well documented somewhere.  This will
not be the first time this comes up (he says, knowingly).

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Mar 2016 16:43:22 +0100

> not be the first time this comes up (he says, knowingly).

I am somewhat surprised. Do people really expect that signatures
computed over a certain encoding of some data can be applied to a
different encoding of the same data? If I sign a tar archive and then
convert the content to a zip archive, do people really assume the
signature is still valid?

If this is a surprise, perhaps object signature RFCs should say
something about this. Does it make sense to have a statement in every
data encoding RFC saying that 'if you transform the encoding to a
different encoding, a signature calculated over the original encoding
will not be valid anymore'?

/js

---

From: Eliot Lear <[email-masked]>
Date: Mon, 21 Mar 2016 16:53:46 +0100

Hi Juergen,

I think there is a miscommunication:

On 3/21/16 4:43 PM, Juergen Schoenwaelder wrote:

> different encoding of the same data?

Not at all what I meant  (sorry if I was confusing).  I just meant that
we should be explicit as to what architectural component is responsible
for object signature and verification.  And it would be nice if there
were a few examples somewhere.

Eliot

---

From: Kent Watsen <[email-masked]>
Date: Mon, 21 Mar 2016 15:55:01 +0000

the zerotouch draft uses object signing.   XMLSIG was used in earlier draft, but was replaced with a binary type leaf called 'signature' having the following description:

description
          "A PKCS #7 SignedData structure as specified by RFC<https://tools.ietf.org/html/rfc2315>
           2315<https://tools.ietf.org/html/rfc2315>, Section 9.1<https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-07#section-9.1> encoded using the ASN.1 distinguished
           encoding rules (DER), as specified in ITU-T X.690.
           This signature is generated using the owner's private
           private key and an owner-selected digest algorithm over
           the redirect-information or the bootstrap-information
           nodes, which ever is present, and in whatever encoding
           they are presented in (e.g., XML, JSON, etc.).";
           // is there a canonical format?
        reference
          "RFC 2315<https://tools.ietf.org/html/rfc2315>:
              PKCS #7: Cryptographic Message Syntax Version 1.5
           ITU-T X.690:
              Information technology - ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER),
              Canonical Encoding Rules (CER) and Distinguished
              Encoding Rules (DER).";
      }

Note a question regarding canonical format.  As the draft stands, no format is canonical format is required.  The data can be however the data is provided, by the server when pulling on the RESTCONF resource URL, or how it is encoded in a message buffer, or encoded to a file on disk.

The use of PKCS #7 signing was selected to simplify implementations, especially on resource-constrained devices.  Use of DER encoded ASN.1 structure was selected to be consistent with other parts of the draft as well as parts of the server-model draft (in the keychain section).

Thanks,
Kent

On Mar 21, 2016, at 11:30 AM, Eliot Lear <[email-masked]<mailto:[email-masked]>> wrote:

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 21 Mar 2016 18:10:57 +0100

Hi Kent,

Thanks for the pointer.  The zeroconf draft is cool beans to be sure. 
That describes an enrollment mechanism for devices that make use of
802.1AR.  Very ANIMAesque.  What I'm suggesting, and perhaps it's a bit
late for this draft, is just a statement in this draft along the lines
that "signing and verifying happens at the JSON level; see [ref] for how
to do it", and for extra credit an example would be exceedingly cool. 
That way we as developers know what to do (again, I'm neither a JSON nor
netmod expert - just trying to make use of what's there for what I am
expert at (or so I think)).

Eliot

On 3/21/16 4:55 PM, Kent Watsen wrote:
>
> the zerotouch draft uses object signing.   XMLSIG was used in earlier
> draft, but was replaced with a binary type leaf called 'signature'
> having the following description:
>
>
>
> description "A PKCS #7 SignedData structure as specified by RFC
> <https://tools.ietf.org/html/rfc2315> 2315
> <https://tools.ietf.org/html/rfc2315>, Section 9.1
> <https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-07#section-9.1>
> encoded using the ASN.1 distinguished encoding rules (DER), as
> specified in ITU-T X.690. This signature is generated using the
> owner's private private key and an owner-selected digest algorithm
> over the redirect-information or the bootstrap-information nodes,
> which ever is present, and in whatever encoding they are presented in
> (e.g., XML, JSON, etc.)."; // is there a canonical format? reference
> "RFC 2315 <https://tools.ietf.org/html/rfc2315>: PKCS #7:
> Cryptographic Message Syntax Version 1.5 ITU-T X.690: Information
> technology - ASN.1 encoding rules: Specification of Basic Encoding
> Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding
> Rules (DER)."; }
> Note a question regarding canonical format.  As the draft stands, no
> format is canonical format is required.  The data can be however the
> data is provided, by the server when pulling on the RESTCONF resource
> URL, or how it is encoded in a message buffer, or encoded to a file on
> disk.
>
> The use of PKCS #7 signing was selected to simplify implementations,
> especially on resource-constrained devices.  Use of DER encoded ASN.1
> structure was selected to be consistent with other parts of the draft
> as well as parts of the server-model draft (in the keychain section). 
>
> Thanks,
> Kent
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Mar 2016 09:10:43 +0100

> expert at (or so I think)).

This I-D is an object encoding specification. Why would this document
have to talk about possible object signatures?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 22 Mar 2016 09:47:07 +0100

> On 22 Mar 2016, at 09:10, Juergen Schoenwaelder <[email-masked]> wrote:
> 

+1

These issues are important but they should IMO be dealt with separately.

Thanks, Lada

---

From: Benoit Claise <[email-masked]>
Date: Tue, 22 Mar 2016 15:54:37 +0100

Dear all,
>     conversions require the YANG data model to be available.
Thanks.
> base64-encoded). This should work equally well in XML and JSON,
I skipped this point above for now as the thread goes on.
> I don't have much more to say without seeing alternative proposals.
I re-reviewed the security directory review, and from my vantage point, 
I believe that Lada addressed the review.

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Tue, 22 Mar 2016 15:59:08 +0100

> These issues are important but they should IMO be dealt with separately.
Ok. Where should it be described? RFC6087bis?

Regards, Benoit
> .

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Mar 2016 16:42:23 +0100

On Tue, Mar 22, 2016 at 03:59:08PM +0100, Benoit Claise wrote:
> >>On 22 Mar 2016, at 09:10, Juergen Schoenwaelder 
> >><[email-masked]> wrote:
> >>

I think such considerations belongs into documents making use of
object signatures and close to 100% of the YANG models today don't
so I do not even think this qualifies for RFC6087bis.

/js

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Mar 2016 16:10:47 +0000

> I believe that Lada addressed the review.

In case it helps, I've no problems with that.
S

---

From: Eliot Lear <[email-masked]>
Date: Tue, 22 Mar 2016 17:12:24 +0100

Hi Juergen,

> so I do not even think this qualifies for RFC6087bis.

I think there are AT LEAST two areas where signatures are going to be
necessary:

  * There exist multi-level authorization schemes today that rely on
    signatures.  Those have to be transported.
  * Manufacturer usage descriptions (MUDs) have extremely broad scope in
    terms of the number of devices that are intended to use the same
    description (think thousands to millions).  And so an unauthorized
    change could have a similarly broad impact.

Thus, wherever the YANG experts think signatures should happen in each
encoding case is fine with me; but I'd suggest that I'm not the only
person who's going to want to know.  Is it THAT hard to at least add a
reference?  Because if it is, that would cause me to wonder if the
mechanisms are really in place to do the right thing.

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Mar 2016 17:23:37 +0100

> mechanisms are really in place to do the right thing.

Eliot,

I simply fail to understand what the problem is and I fail to see
which addition (ideally in concrete words) is proposed to fix the
problem.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Mar 2016 09:50:00 -0700

> which addition (ideally in concrete words) is proposed to fix the

This seems like a protocol issue, not a data modeling issue.
NETCONF and RESTCONF both have very strict security requirements
to protect the instance documents which are intended to conform to YANG
schema.

> /js

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>