Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-acceptable-urls-09

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Michael,

Thanks for the updates.

Changes look good, and I’ll initiated IETF LC on -09, but there are a couple of remaining nits, please see inline. below.  You can either just fix them in your editors copy or post a new revision if you prefer, either works.

Anyway, this completes my AD review.  I may be able to get this on the 2024-03-07 telechat, but it may end up with too many pages, in which case it will end up on the first one after IETF 119 with Mahesh progressing it.

Regards,
Rob


From: OPSAWG <[e-mail]> on behalf of Michael Richardson <[e-mail]>
Date: Wednesday, 7 February 2024 at 01:26
To: Rob Wilton (rwilton) <rwilton=[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Mahesh Jethanandani <[e-mail]>
Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-acceptable-urls-09

version -10 is posted, diff is at:

https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-mud-acceptable-urls-09&url2=draft-ietf-opsawg-mud-acceptable-urls-10&difftype=--html


Rob Wilton \(rwilton\) <rwilton=[e-mail]> wrote:
    > I think that the document is fine and reasonably clear but could do
    > with a bit of language clean up and clarity in a few places.  I’ve
    > included my review comments below and also some grammar nits from a
    > grammar tool at the end.

    > Moderate level comments:

    > (1) p 2, sec 3.  Updating the MUD files in place

    > Would it a better title for this section be: "Possible issues with
    > updating MUD files in place"?

okay.

    > Minor level comments:
    > (2) p 1, sec 1.  Introduction


    >    [RFC8520] provides a standardized way to describe how a specific
    >    purpose device makes use of Internet resources and associated
    >    suggested network behavior.  The behaviors are described in a MUD
    >    file hosted in its manufacturer's server.  The device provides a MUD
    >    URL to the network manager, which can locate this MUD file and
    >    determine the required network authorization of the device.

    > "specific purpose device" sounds like slight strange phrasing to me.

RFC8520 says:
        These devices, which this memo refers to as Things, have a
        specific purpose.

the key point is that they are not, "general purpose devices" (like laptops,
and smartphones).  I'm not sure what to do with your comment; I'd like to
keep this connection to 8520, but maybe the phrase can be changed in some
useful way.
Okay.  Leave it as is.  I don’t think that it is wrong, it just sounds strange to me.  Perhaps other reviews or the RFC editor will have a better suggestion.


    > (3) p 2, sec 1.  Introduction

    >    [RFC8520] does not specify how MUD controllers establish their trust
    >    in the manufacturers' signing key: there are many possible solutions
    >    from manual configuration of trust anchors, some kind of automatic
    >    configuration during onboarding, but also including to Trust on
    > First
    >    Use (TOFU).  How this initial trust is established is not important
    >    for this document, it is sufficient that some satisfactory initial
    >    trust is established.

    > "but also including to" doesn't scan well to me.

Changed to:
  or a Trust on First Use (TOFU) mechanism that accepts the signer on first use.

Okay.

    > (4) p 3, sec 3.1.  Adding capabilities

    >    While there is an argument that old firmware was insecure and should
    >    be replaced, it is often the case that the upgrade process involves
    >    downtime, or can introduce risks due to needed evaluations not
    > having
    >    been completed yet.  As an example: moving vehicles (cars,
    > airplanes,
    >    etc.) should not perform upgrades while in motion!  It is probably
    >    undesirable to perform any upgrade to an airplane outside of its
    >    service facility.  A vehicle owner may desire only to perform
    >    software upgrades when they are at their residence.  Should there be
    >    a problem, they could make alternate arrangements for
    > transportation.
    >    This is constrasted with the situation when the vehicle is parked
    > at,
    >    for instance, a remote cabin.  The situation for upgrades of medical
    >    devices has even more considerations involving regulatory
    > compliance.



    > Perhaps change: This is contrasted with ... => This contrasts this with
    > an alternative situation where the vehicle is parked at, for instance,
    > a remote cabin, where an upgrade failure could cause a much greater
    > inconvenience.

Changed to:

} A vehicle owner may desire only to perform software upgrades when they are
} at their residence.   Should there be a problem, they could make alternate
} arrangements for transportation.
} This contrasts with an alternative situation where the vehicle is parked
} at, for instance, a remote cabin, where an upgrade failure could cause a much
} greater inconvenience.

It's sad that this is no longer a hypothetical situation :-(

Thanks.  I’ve noticed that I proposed text uses where … where.  I hence, I suggest changing the second one to “and where”.


    > (5) p 5, sec 4.  Updating the MUD URLs


    >    The QRcode mechanism is usually done via paper/stickers, and is
    >    typically not under the control of the device itself at all.
    >    However, being applied by a human and not easily changed, a MUD URL
    >    obtained in this fashion is likely trustworthy.  (It may not, due to
    >    mixups in labeling represent the correct device, but this is a human
    >    coordination issue, and is out of scope for this document.)


    > Is this definitely trustworthy?  E.g., we have a spate of scams in the
    > UK where folks put new QR codes on the parking machines directly folks
    > to pay at fraudulent websites instead.  This scenario is obviously
    > different, but would presunably still allow a supply-chain attack to
    > occur?

} However, being applied by a human and not easily changed, a MUD URL
} obtained in this fashion is likely as trustworthy as the rest of the vendors
} packaging.

It's hard to come up with a hack similiar to the parking machine attack.
The MUD QRcode is not for general consumption.  To be useful, an attacker
would have to:
a) find a device accessible.
b) disable or break the device such that it requires human intervention.
c) affix a phony QRcode to the device.
(d) affix a phony MAC address QRcode/barcode to device)
e) wait for human to come, fix the device, realize that it's not properly
   enrolled in their MUD controller, and scan it again.

What are the goals of the attacker?
If it's to enable attacks against the device from the outside, then replacing
the MUD file might work... if it's signed with a key that they enterprise
already trusts.  So this probably means changing the URL to be that of
another device that is trusted, and has the additional policy needed.
They also have to break the device sufficiently that it needs to go through
enrollment again, and be onboarded, but so much that it gets replaced, and/or
detached from it's location to be serviced in workshop.

If it's to enable another device (with a different MAC address) to become
accessible with the new policy, then (d) is required.  That is basically
doing a kind of social engineering attack, getting the admin person to
install some new policy.  Again, requires the signature to be valid.
And that the target MAC address isn't already in the MUD controller.

Perhaps someone else can come up with a different attack?
I think that most of the QRcodes will be scanned by the person who takes the
device out of the vendor's box.  Perhaps slipping extra QRcodes into boxes at
HomeDepot might work here.
Okay.  Thanks for the explanation.


    > (6) p 6, sec 4.2.  Concerns about same-signer mechanism

    >    This works as long as manufacturers use a single key to sign all
    >    products.  Some manufacturers could sign each product with a
    >    different key.  Going logically down this path, if all these product
    >    keys are collected into a single PKI, signed by a common
    >    certification authority.

    > The second sentence doesn't make sense to me.  Or otherwise, as a
    > paragraph it is incomplete.

Rewritten as:
} This works as long as manufacturers use a single key to sign all products.
} Some manufacturers could sign each product with a different key.
} Such manufacturers would probably then collect all the signing keys into a
} certificate infrastructure (PKI), with a single manufacturer CA key.
Okay.

    > (7) p 6, sec 5.  Proposed mechanism

    > Perhaps rename this section to "Proposed mechanism for updating MUD
    > URLs"?

done.

    > (8) p 7, sec 5.  Proposed mechanism

    >    Once the new MUD file is accepted, then it becomes the new "root"
    > MUD
    >    file, and any subsequent updates MUST be relative to the MUD-URL in
    >    the new file.


    > When could this actually change?  I.e., if it only accepts MUD files
    > with the same base URL then, by definition, they must all be peers of
    > each other, right?  Ah, the MUD-URL in the new MUD file can be used to
    > give a new canonical path of where the MUD file should be found.  I
    > think that this text would benefit from being a lot clearer.

Yes, they would all be in the same "directory"

I've rewritten a few parts in that section to use "canonical" rather than "root"
commit: 181d35c
https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-acceptable-urls/commit/181d35ce6d7db672135bee1ade432f24b75eabe0

Looks good.  Thanks.

    > (9) p 8, sec 5.1.1.  Changing file structure


    >    The manufacturer simply changes the MUD-URL contained with the files
    >    at the old location to have a value of
    >    https://example.com/mudfiles/toasters/model1945/mud.json.  The
    >    manufacturer must continue to serve the files from the old location
    >    for some time, or to return an HTTP 301 (Moved Permanently)
    >    redirecting to the new location.


    > Possibly it would be cleared to also indicate that the file must also
    > be served at the new location at the same time.  I.e., for a period of
    > time, the same mud file is served up at two different locations, only
    > one of which is regarded as being tbe canonical path.

https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-acceptable-urls/commit/13ad7e6

Okay.


    > (10) p 8, sec 5.1.2.  Changing hosting URLs


    >    The manufacturer simply changes the MUD-URL contained with the files
    >    at the old location to have a value of
    >    https://example.com/mudfiles/toasters/model1945/mud.json.  The
    >    manufacturer has to continue to host at the old location until such
    >    time as it is sure that all MUD controllers have loaded the new
    > data,
    >    and that all devices in the field have upgraded their URL.  A 301
    >    Redirect that changed the hostname SHOULD NOT be accepted by MUD
    >    controllers.

    > I'm not really convinced that this example is materially different from
    > the one above.

Yes, it's not materially different.
I included both examples because it's exactly these two scenarios that
technical people are likely to argue with marketing people (who think they
run the web sites) about.  I think that it will be easier for the technical
people to get their point across if both cases are explicitely spelt out.

Okay.


    > (11) p 9, sec 7.  Privacy Considerations


    >    The MUD URL contains sensitive model and even firmware revision
    >    numbers.  Thus the MUD URL identifies the make, model and revision
    > of
    >    a device.


    > Should this be "The MUD URL could contain sensitive model and ...,
    > thus, the MUD URL ..."?

fixed.

    > Nit level comments:


    > (12) p 4, sec 3.2.  Removing capabilities

    >    In this case, the old device will be performing unwanted
    > connections,
    >    and the MUD controller will be alerting the network owner that the
    >    device is misbehaving rather than not upgraded.  This causes a
    > false-
    >    positive situation (see [boycrieswolf]), leading to real security
    >    issues being ignored.  This is a serious issue as documented also in
    >    [boywolfinfosec], and [falsemalware].
    > "not upgraded" => "not being upgraded"

fixed.


    > (13) p 5, sec 4.1.  Leveraging the manufacturer signature

    >    When the first time a signature of the MUD file related to a
    >    particular device-type is verified by the MUD controller, the
    >    identity of the signing authority is recorded.  That it, the signing
    >    authority is pinned.  This policy means that subsequent MUD files
    >    must be signed by the same entity in order to be accepted.

    > "When the first time" => "The first time".

fixed.

    > (14) p 5, sec 4.1.  Leveraging the manufacturer signature
    >    The trust and acceptance of the first signer may come from many
    >    sources, for example, it could be manual configured to trust which
    >    signer, or using the IDevID mechanism for the first MUD URL and the
    >    signer of the corresponding MUD file is more trustworthy, or the MUD
    >    controller can use a Trust on First Use (TOFU) mechanism and trusts
    >    the first signer by default.

    > "... manual configured to trust which signer" doesn't scan well.
    > Perhaps something like "... manually configured to trust particular
    > signers, or, as a more trustworthy approach, use the IDevID mechanism
    > for the first MUD URL and as the signed of the corresponding MUD file,
    > "?

I've rewritten it slightly.
I think that the signer can only be TOFU if the URL came from a trusted
source, such as IDevID.
But, a URL that came from an untrusted source could be acceptable if the
signer is from a configured trust anchor.
https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-acceptable-urls/commit/7841c7c

Okay, but please tweak “The first signature be Trust” to “The first signature could be Trust” in the last changed sentence.

    > (15) p 6, sec 4.2.  Concerns about same-signer mechanism
    >    It is possible to invent policy mechanisms that would link the EE
    >    certificate to a value that is in the MUD file.  This could be a
    >    policy OID, or could involve some content in a subjectAltName.
    >    Future work could go in this direction.  This document proposes a
    >    simpler solution.

    > Probably "that direction" is better than "this direction".

fixed.



    > (16) p 9, sec 6.  Polling for changes in MUD files
    >    The manufacturer SHOULD serve mud files from a source for which ETag
    >    Section 2.3 of [RFC7232] may be generated.  Static files on disk
    >    satisfy this requirement.  MUD files generated from a database
    >    process might not.  The use of ETag allows a MUD controller to more
    >    efficiently poll for changes in the file.

    > s/mud/MUD/

fixed.

    > (17) p 10, sec 9.  Security Considerations
    >    3.  somehow get the manufacturer to sign the alternate MUD

    > ... alternative MUD file.


    > Grammar warnings from tooling:

    > Grammar Warnings: Section: 3.1, draft text: It is probably undesirable
    > to perform any upgrade to an airplane outside of its service facility.
    > Warning: This phrase is redundant. Consider using outside.  Suggested
    > change: "outside"

I don't get this suggestion.
The suggestion is to use “outside the service facility” rather than “outside of …”
Thanks,
Rob


    > Section: 5.1.2, draft text: The manufacturer has to continue to host at
    > the old location until such time as it is sure that all MUD controllers
    > have loaded the new data, and that all devices in the field have
    > upgraded their URL.  Warning: "It is sure" is uncommon. Consider using
    > certain.  Suggested change: "certain"

whole sentence got edited out.

    > Section: 7, draft text: Thus the MUD URL identifies the make, model and
    > revision of a device.  Warning: A comma may be missing after the
    > conjunctive/linking adverb 'Thus'.  Suggested change: "Thus,"

fixed.

    > Section: 9, draft text: Prior to the standardization of the process in
    > this document, if a device was infiltrated by malware, and said malware
    > wished to make accesses beyond what the current MUD file allowed, the
    > the malware would have to: Warning: Possible typo: you repeated a word
    > Suggested change: "the"

fixed.

    > Section: 9, draft text: A manufacturer which has not managed their MUD
    > files in the the way described here can deploy new directories of
    > per-product MUD files, and then can update the existing MUD files in
    > place to point to the new URLs using the MUD-URL attribute.  Warning:
    > Possible typo: you repeated a word Suggested change: "the"

fixed.

    > Section: 9.1, draft text: Developers should be aware that many
    > enterprise web sites use outsourced content distribution networks, and
    > MUD controllers are likely to cache files for some time.  Warning:
    > Nowadays, it's more common to write this as one word.  Suggested
    > change: "websites"

oh. okay. fixed.


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide