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

On 22.01.20 19:31, M. Ranganathan wrote:
> Am I missing something obvious.

No, not at all. I am not aware of potential procedural caveats and in 
principle this sounds fine. Alas, now the "trust in the MUD URL" relies 
on the protection of the private key. If that key is not 
shielded/isolated properly and the integrity of the devices is 
compromised, the trustworthiness of the MUD URL is gone without any 
indications, consecutively. Please mind, maybe I am the one missing 
something now.

The burden of providing evidence about the "trust in the MUD URL" lies 
with the device in this scenario.

If you embed it in the device's DevID, this burden is with the trust 
anchor, I think. Although a complementary entity is required to 
remediate loss of device integrity, still (as in most cases). A 
compromised device alone can and will use any MUD URL it wants.

Maybe I am over-simplifying my point, but I think that is one main 
difference. Analogously, I am still not convinced that changing the MUD 
URL is not dangerous in principle.

If you do not allow for a MUD URL to change, you avoid a lot of 
complexity. The simplicity of MUD is one of its main selling points.

Viele Grüße,

Henk

On 22.01.20 19:31, M. Ranganathan wrote:
> 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
> 
> 
> 