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

From: Randy Presuhn <[email-masked]>
Date: Tue, 22 Mar 2016 20:57:12 -0700 (GMT-07:00)

Hi -

>From: Juergen Schoenwaelder <[email-masked]>
>Sent: Mar 22, 2016 9:23 AM
>To: Eliot Lear <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, Stephen Farrell <[email-masked]>
>Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT)
>
>On Tue, Mar 22, 2016 at 05:12:24PM +0100, Eliot Lear wrote:
>> Hi Juergen,
>> 
>> On 3/22/16 4:42 PM, Juergen Schoenwaelder 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.
>> >
>> 
>> 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,
>
>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.

The problem is that the current approach does not address representing
blobs of configuration data as (signed) documents independent of the
protocol used for shoveling those blobs around.

Randy

---

From: Kent Watsen <[email-masked]>
Date: Thu, 24 Mar 2016 11:42:19 +0000

All,

I believe that this thread's issue is resolved if the following text is added to the Security Considerations section:

"This document defines a JSON encoding for YANG-defined data. It does not defined any mechanisms for signing or encrypting said data.  Use of an external mechanism, such as PKCS #7 [RFC2315] or JOSE [RFC7515 and RFC7516], is needed for such cases."

Elliot, Randy, Stephen?

Kent   // document shepherd

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 Mar 2016 12:46:23 +0100

> "This document defines a JSON encoding for YANG-defined data. It does not defined any mechanisms for signing or encrypting said data.  Use of an external mechanism, such as PKCS #7 [RFC2315] or JOS…

WFM.  Thank you!

Eliot

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 24 Mar 2016 13:12:05 +0100

> On 24 Mar 2016, at 12:42, Kent Watsen <[email-masked]> wrote:
> 
> 
> All,
> 

I am fine with adding this sentence although, as a matter of fact, the document does not define an infinite number of other mechanisms. There is no general requirement to support signing and encrypting for YANG-modelled data, also because, as Andy pointed out, our protocols so far demand a secure transport.

I any case, we can make this edit only after IETF 95, right?

Lada 

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

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 Mar 2016 14:18:11 +0100

Hi Lada,

On 3/24/16 1:12 PM, Ladislav Lhotka wrote:
> I am fine with adding this sentence although, as a matter of fact, the
> document does not define an infinite number of other mechanisms. There
> is no general requirement to support signing and encrypting for
> YANG-modelled data, also because, as Andy pointed out, our protocols
> so far demand a secure transport.

Just for context,  encrypted transport addresses only in flight attack. 
That's not always the only form that needs to be protected against.  At
least in the use case I'm dealing with, where an intermediary system –
one that is storing files – is attacked, and due to the scope of the
risk, we want an additional layer.  This also allows files to be passed
around without having to worry about the path.  That's not in my
specific use case today, but it is something that has been done.

Eliot

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 24 Mar 2016 15:23:18 +0100

Hi Eliot,

I agree it would be useful to be able to sign configuration data in an encoding-independent way, but it is not an aim of this document to deal with this problem. Encoding-specific approaches are of course available, this probably needn't be mentioned.

Lada

> On 24 Mar 2016, at 14:18, Eliot Lear <[email-masked]> wrote:
> 
> 
> Hi Lada,
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 Mar 2016 16:06:08 +0100

Hi Lada,

> I agree it would be useful to be able to sign configuration data in an encoding-independent way, but it is not an aim of this document to deal with this problem. Encoding-specific approaches are of…

I totally understand, and I'm not even asking that this group take on
coding that stuff in an independent way.  A simple reference in security
considerations along the lines that Kent suggested is fine.

Eliot

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 24 Mar 2016 16:07:27 +0100

> On 24 Mar 2016, at 16:06, Eliot Lear <[email-masked]> wrote:
> 
> Hi Lada,
> 

OK, let's do it.

Lada