Subject: Re: [netmod] [OPSAWG] Comments on draft-lear-ietf-netmod-mud-02

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 10 Jun 2016 15:48:30 +0000

Canonicalization is the way to avoid file content being mangled or represented differently by different (software) entities that try to create or verify digital signature over it. It doesn't matter if your file is binary or not. And CMS by itself won't save you either.‎ This problem (ensuring there is only one way to represent the contents of the file in question) is what you need to show that you solved.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Eliot Lear
Sent: Friday, June 10, 2016 06:08
To: Cullen Jennings; [email-masked]; [email-masked]
Subject: Re: [OPSAWG] Comments on draft-lear-ietf-netmod-mud-02

Hi Cullen,

Generic answer to your message: please send text. More specifics below.

On 6/7/16 11:57 PM, Cullen Jennings wrote:
> I like how this is evolving ... few things 
>
> Few small things ....
>
> If you use CMS, I think you need to deal with how the JSON in canonicalized before being signed. I will suggest that the standards the IETF created for signing JSON would be a better choice for signing JSON than CMS - that's how most other JSON based stuff does it. 

Within the bounds of widely available tooling I'm open to it, but would
need to be convinced. I am somewhat comfortable with the CMS approach
in which what we are signing is a file – the fact that it is JSON in
incidental. What I would want see is a tool that can sign a JSON object
and another one that can validate a signature through a chain of trust. 
In addition, there is a relationship between the signer of the MUD file
and, if 802.1AR is in play, the signer of that certificate that should –
somehow– be demonstrated. Ptrs welcome.

>
> Putting the last updated and cache validity in the file may not be a good plan. More importantly putting it inside the stuff that is singed seems problematic. 
"Cache Validity" may be a misnomer here. The intent is that because
there may be millions of Things out there in tens of thousands of
deployment, the manufacturers can hint at how long they do NOT wish to
hear from a requester. View this as a minimum validity period, but by
no means a maximum. Last-updated is just that, but I don't understand
your concern.

>
> The "ietf-mud:direction" stuff seems a bit under specified. Does from-device mean that if the device imitates the flow, responses to the flow also need to flow to the device? It seems like the ietf-netmod-acl-model draft might be a better place to specify this. 

Personally I would be happy for it to go into the ACL model, if that is
netmod's wish. The only issue with that, and it is not a big issue, is
that we chose terminology that was slightly mud-oriented so as to avoid
confusion as to what "in" and "out" might mean. This can also be
included as a separate augmentation in a separate module if people think
that's appropriate but it is necessary for MUD, and so that's why it is
where it is at the moment. Again, happy to go with other approaches so
long as the WG is okay with them.

>
> Use of "ietf-mud" as prefix in the JSON for "ietf-mud:direction" is not how JSON typically does this. You don't need a namespace because we know this is a mud file thus know the namespace. A big reason some people moved from XML to JSON was exactly to get rid of namespace. 

What's in there is what validates against pyang and yang2xml. No
namespace is assumed on the outside, but rather the outer is ACL, and
then on use where inner comes in, you need to name the namespace, or the
tools will assume that MUD is invalid, as I understand it. Again, I am
not a YANG expert. If the YANG people tell me I'm off base, I'd be
happy to fix what's there.

>
> It's not a great practice to put ":" in the names of json attributes because the way people use them in some languages often have them unquoted which you can't do if there is a : in the name. You can do it, but "-" or "_" might be better than ":" here. 

I'm concerned about tool breakage as well, then. However, this is how
things are specified in draft-ietf-netmod-yang-json-10. We would need
to revisit that there, and I'm happy with whatever outcome of that
discussion would be.

>
> It would be great to have an simple example JSON file in the introduction instead of (as well as a complete example in section 6)

Good idea.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Fri, 10 Jun 2016 19:03:51 +0200

Hi Uri,

> Canonicalization is the way to avoid file content being mangled or represented differently by different (software) entities that try to create or verify digital signature over it. It doesn't matter…

I totally get it.  From a MIME perspective it'll be something like
application/mud+json, encoded in UTF-8, and transported accordingly
(HTTPS is 8-bit clean).  This is not going to be our problem.

Eliot

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 10 Jun 2016 17:12:51 +0000

Just "encoding" is not enough - it's *how exactly*‎ the file is encoded.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Eliot Lear
Sent: Friday, June 10, 2016 13:04
To: Blumenthal, Uri - 0553 - MITLL; Cullen Jennings; [email-masked]; [email-masked]
Subject: Re: [OPSAWG] Comments on draft-lear-ietf-netmod-mud-02

Hi Uri,

Eliot