Subject: Re: [OPSAWG] CoAP and MUD

From: Michael Richardson <[email-masked]>
Date: Thu, 28 Nov 2019 10:05:47 +0100

Jaime Jiménez <[email-masked]> wrote:
    > here is the draft in case you wanna have a look, it's just 8 pages.
    > https://jaime.win/draft-coap-mud/

Thank you for pointing me at it.
I'm replying to the opsawg list.

> Overall a MUD is emitted as a URL using DHCP, LLDP or through 802.1X, then
> a Switch or Router will send the URI to some IoT Controlling Entity. That
> Entity will fetch the MUD file from a Server on the Internet over HTTP
> [RFC8576].

It might be worth adding that it can be emitted in an IDevID using BRSKI.
That uses the same certificate extension as in 802.1X.
draft-ietf-anima-constrained-voucher/draft-ietf-6tisch-dtsecurity-zerotouch
is more likely to have been used if we are getting to CoAP.

There is an open question in the MUD space as to whether the MUD signature
URL is absolute or if it can be relative.  This affects how the signature
file will be found when using a self-hosted MUD file as you have described.

The signature should NOT be signed by the Thing itself, as that provides no
security against malware.  So that also gets in the way of the device
providing any kind of dynamic capability by changing it's MUD.
The device *could* select from a palate of MUD files which the manufacturer
has signed.  That would be very interesting.

  4.1. Serialization
  TBD write about SenML/CBOR MUDs.

Are you thinking that we could serialize the YANG to CBOR instead of JSON?
I'm mostly for that, but I think that in general, since the ACLs will get
enforced by a non-constrained device, and we can host the MUD files on a
manufacturer resource, that it might be enough that it's JSON+CMS. on the
other hand... CMS. Ick.

Also using udf:// URLs from mathmesh would mean that the MUD file could be
found via any cachable mechanism, with the communication with the
manufacturer only if no other way is fine.  This also authenticates the file,
but not quite in the same way that the signature does.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Jaime Jiménez <[email-masked]>
Date: Thu, 28 Nov 2019 11:14:44 +0200

> I'm replying to the opsawg list.

Thanks, the draft is still work in progress and I have not yet
submitted it to T2TRG, which is its final intended destination. 

As per the feedback I have gotten so far, it seems like an interesting
topic but might require a bit more "cooking". Specially the
justification as to why this is needed, the motives I explain so far do
not seem to be sufficiently convincing. 

> is more likely to have been used if we are getting to CoAP.

Yes, that is something that should be considered. I was also discussing
with others on how Neighbor Discovery (ND) would apply, as it is more
common than DHCP in the very constrained space. 

> has signed.  That would be very interesting.

The whole security part is very raw at the moment, I have not thought in
detail how that would work in practice. 

> manufacturer resource, that it might be enough that it's JSON+CMS. on the

I am just assuming that the device will serialize everything in
SenML/CBOR and not use YANG at all. 

> but not quite in the same way that the signature does.

Very interesitng, I am not familiar with udf:// either, I guess it does still require an
IP address to be usable, right?