Re: [Mud] CoAP and MUD

[Jaime Jiménez <[e-mail]>]

On Thu, Nov 28, 2019 at 10:05:47AM +0100, Michael Richardson wrote:
> 
> Jaime Jiménez <[e-mail]> 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.

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. 

> 
> > 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.

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. 

> 
> 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.

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

> 
>   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.

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

> 
> 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.

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

> 
> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
>