Re: [Mud] how to increase trust in MUD URL

On Wed, Jan 22, 2020 at 12:21 PM Michael Richardson
<mcr+ietf@sandelman.ca> wrote:
>
>
> Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:
>     > On 22.01.20 02:03, Michael Richardson wrote:
>     >> But, updating the URL in IDevID is difficult to do. Quite reasonably it might
>     >> be impossible without a device recall.  The IDevID version is much easier to
>     >> invest trust into.  And it clearly links back to the manufacturer.
>
>     > This is one of the biggest issues that came to my mind ad-hoc. Is changing
>     > the URI really an option? I would assume this type of encapsulation is
>     > trustworthy, I think.
>
> Changing the URI in an IDevID is not, in my opinion, feasible.
> While I can imagine ways for an IDevID to be renewed online, I would prefer
> that it be buried so deep into the TPM that it can't be changed in the field.

I  see some words to the contrary in
https://tools.ietf.org/html/draft-richardson-opsawg-mud-acceptable-urls-00

i.e. I see the following:

"The DHCP and LLDP mechanisms are not signed, but are asserted by the device. "

Why can't the MUD URL emitted by the device using DHCP be signed with
the device private key?

If the IDevID for the device can be sent to the MUD Controller using a
trusted agent  then the
Device can just send a signed MUD URL in the DHCP request (or LLDP),.

With this mechanism, it may not be necessary to imbed the MUD  URL in
the device certificate
and the device can freely change the MUD URL with firmware updates.

Onboarding mechanisms (e.g. DPP) can be used to authenticate the
device against the certificate.

With this setup, it is not necessary to include the MUD URL as part of
the device certificate.

Am I missing something obvious.

>
> --
> Mud mailing list
> Mud@ietf.org
> https://www.ietf.org/mailman/listinfo/mud

-- 
M. Ranganathan