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

[Michael Richardson <[e-mail]>]

M. Ranganathan <[e-mail]> wrote:
    > On Wed, Jan 22, 2020 at 12:21 PM Michael Richardson
    > <[e-mail]> wrote:
    >> 
    >> 
    >> 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.

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

It could be. Bud:
a) we haven't defined the MUD DHCP extension that way.  We could probably
   sign the entire DHCP request with RFC3110. I've done this in the distant past.

b) it doesn't gain us anything. It's not a signature from an IDevID (or
   LDevID) that is interesting.  The malware, having taken over the device
   could do that. That could be as easy, on a *nix machine, as dropping
   a file into /etc/dhclient.d/ with the new MUD URL, and the DHCP
   mechanism would sign it for you.

What we want is a signature from the manufacturer, or possibly, as Eliot
suggests, from a TEE/TPM.   But, how does it know what the MUD URL for this
firmware is?   And, if you've got all that, then you have remote attestation
anyway, so why not just have the RATS Verifier provide the MUD URL as part
of the Attestation Results?

Since remote attestation is not going to be common case for home appliances
in the near future (not because the devices are incapable, but because the
homes are ill-equipped [%]), what we can do do today to easily keep the
MUD URL from changing too much, without locking it down completely?


[%] - the lack of equipment to do remote attestation also means that
    probably also has no secure controller to do onboarding, or evaluate the
    IDevID.   So, MUD will be TOFU.

Henk Birkholz <[e-mail]> wrote:
    Henk> If you do not allow for a MUD URL to change, you avoid a lot of
    Henk> complexity. The simplicity of MUD is one of its main selling
    Henk> points.

Eliot had previously convinced me that updating the MUD file in place was
probably workable, and this was not that big a deal.  
The TLS profile convinces me otherwise.
The need to pin the manufacturer signature probably deals with a lot of the
changes that we might need.

Eliot Lear <[e-mail]> wrote:
    >> 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.

    Eliot> To me this is something that TEEs can really assist with, but we
    Eliot> may need to think about how the URL is communicated.  Should it be
    Eliot> in an idevid long term or in some other signed object?

I think that you really mean a TPM-enabled secureboot environment, which a
TEE can implement.   If the firmware (update) comes with a signed blob that
the boot environment can interpret, then that could also contain a
manufacturer signed URL.  
The SUIT manifest pretty much satisfies this requirement, but we still need a
signed thing to put into a DHCP (or LLDP) package.  That would likely need to
be a simple CoseSign0 object.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [