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

[Michael Richardson <[e-mail]>]

Henk Birkholz <[e-mail]> 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.

    > On 22.01.20 02:03, Michael Richardson wrote:
    >> If a vendor is going to put very specific information relating to TLS
    >> libraries into a MUD file, then it is going to be critical that any updates
    >> to the firmware (such as BUG FIXES) result in updates to the MUD TLS profile.

    > Hm. I always assumed that either a MUD file or the parameters to a MUD URI
    > would take care of "versions" or "composition" of the requester (so the
    > requester appends information about that in the URI). Is that not how other
    > people think about it? The idea of a canonical composition of the segments in
    > the URI did not fly IIRC (due to rfc7320 I assume).

Yes, so I assume that the MUD URL will depend upon the firmware version.
In  draft-richardson-opsawg-mud-acceptable-urls-00 I am proposing something
like:
    IDevID MUD URL https://www.example.com/mud/frobits/modelT/base.json
    DHCP MUD URL   https://www.example.com/mud/frobits/modelT/build1176.json

The base.json -> build1176.json transition is either *implicit*, only the
last part can change.  Or we introduce a mud-base-url attribute to the
base.json file.

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