Re: [OPSAWG] comments on draft-ietf-opsawg-mud-acceptable-urls-00

[Michael Richardson <[e-mail]>]

tangtianqing <[e-mail]> wrote:
    tt> I’ve read this draft and I support the adoption. Besides that, I have
    tt> some comments below:

Thank you for your comments.
Bringing the most trivial to the top so that others might notice and comment:

    doc> 5. Changes to RFC8520 Subsequent MUD files are considered valid if: *
    doc> have the same initial Base-URI as the MUD-URL, but may have a
    doc> different final part…

    tt> I suggest that describe “MUD URL”, “MUD-URL”, and “mud-url”
    tt> in advance due to their different meanings.

It's not my intention to make any distinction.
"mud-url" is the attribute in the JSON, but the other two should be
consistent.  I don't know if a hyphen is appropriate here.

    tt> 1)

    doc> 1.  Introduction While MUD files may include signatures, it is not
    doc> mandatory to check them, and there is not a clear way to connect the
    doc> entity which signed the MUD file to the device itself. A malicious
    doc> device does not need to make up a MUD file if there is already an
    doc> available, and already trusted MUD file which it can use to
    doc> impersonate the device.

    tt> I think not checking signatures will cause significant
    tt> vulnerability, and I also find RFC8520 doesn’t mention whether it’s
    tt> mandatory to check signatures. Therefore, I am confused that if there
    tt> is any special purpose or consideration not to check signatures of MUD
    tt> files.

I have changed the scope of the document to make it clear that this process
only applies to situations where the MUD controller checks signatures, and
that all MUD files have them.
I think that the question of how initial trust for RFC8520 is established is
something that the industry will need to work out a bit;  there are many
possible solutions, but most are that layer 8 (political) rather than within
the pervue of the IETF.

I have made some rewrites based upon your comments:
https://github.com/mcr/iot-mud-acceptable-urls/commit/531ade449625960f75279b27ba7411a913feb672
    tt> 2)

    doc> 1. Introduction One defense against this is to not trust MUD URLs
    doc> which are different from the one that was placed in an IDevID. Or if
    doc> the initial MUD URL was not taken from an IDevID, it could be trusted
    doc> on first use.

    tt> What does "this" mean? Does it refer to the problem that a
    tt> device is unable to verify if the MUD URL belongs to itself, or the
    tt> method above that cannot connect the MUD file signer with the device
    tt> itself?

"this" refers to an attack where the malware replaces the MUD URL.
Since your review, I have changed the text a fair bit.
In general, the device does not verify (or is even aware of), it's MUD file contents.
Specifically, a goal of RFC8520 is really to get the policy about the device
to be expressed in a way that the device (even when infected), can not influence.

    tt> If IDevID mechanism is applied, why other MUD URLs exist? Or
    tt> is it better here to say “MUD controller shouldn’t trust other MUD
    tt> URLs than the one placed in an IDevID”?

The IDevID usually can not be updated with a physical device recall.

    tt> 3)

    doc> 2.1.2. Removing capabilities In this case the old device will be
    doc> performing unwanted connections, and the MUD controller when be
    doc> alerting the device owner that the device is mis-behaving. This causes
    doc> a false positive situation (see [boycrieswolf]), leading to real
    doc> security issues being ignored. This is a serious issue as documented
    doc> also in [boywolfinfosec], and [falsemalware].

    tt> Comment > What does “real security issues” mean? Does it means that
    tt> the device owner mistakenly judge that the device is not upgraded as
    tt> misbehaving?

First, I have fixed the first sentence to read:
       In this case the old device will be performing unwanted connections,
       and the MUD controller will then send alerts to the network owner that
       the device is mis-behaving.
   https://github.com/mcr/iot-mud-acceptable-urls/commit/85448e53854219dfa38fa4ad32a209150cd96cda

as there were wording issues.

Second, there is a lot of evidence that when there are many false positives
(alerts for issues which are in fact of actual concern), that human operators will
learn to ignore many of these alerts.

The generic term from from Greek "fabulist and storyteller" Aesop, is known
as the "Boy who cries Wolf", https://fablesofaesop.com/the-boy-who-cried-wolf.html

The other reference article at:
   https://www.infosecurity-magazine.com/opinions/security-alerts-boy-cried-wolf/

begins:
   On a daily basis, almost half of all security operations managers receive
   5,000 alerts per day and, of these, 44% are never investigated.

   Possibly the toughest challenge for an IT security team is managing this
   deluge of security alerts. Considerable time is spent on false positives when
   the stakes are high – failing to detect an active infection can have serious
   consequences.

   Alerts and alarms are designed to draw attention, but when the barrage is
   constant, it’s easy to become desensitized. It’s of no surprise that IT
   and security teams are facing ‘alarm fatigue’ where they are overwhelmed
   by constant notifications and information. As a result, the real threats
   are buried amongst the noise, and often missed or unintentionally
   ignored.

   ....

so the issue is that if we do anything that increases the load of false
positives, then we are doing security a disservice.

    tt> 4）

    doc> 2.1.3. Significant changes to protocols [I-D.reddy-opsawg-mud-tls]
    doc> suggests MUD definitions to allow examination of TLS protocol
    doc> details. Such a profile may be very specific to the TLS library which
    doc> is shipped in a device. Changes to the library (including bug fixes)
    doc> may cause significant changes to the profile, requiring changes to the
    doc> profile described in the MUD file. Such changes are likely neither
    doc> forward nor backward compatible with other versions, and in place
    doc> updates to MUD files are therefore not indicated.

    tt> In my understanding, I think version updates should take
    tt> compatibility into consideration, even for bug fixes. So why do you
    tt> think they are likely not compatible with other versions?

Please read the other document :-)
Bug fixes to the TLS libraries may change how the library behaves, and this
may result in the observed TLS profile (as detailed by
draft-ietf-opsawg-mud-tls ), being different.
The changes argues for changing the MUD URL, not the file, as not-yet-patched
devices will continue expressing the old profile, while patched ones will
express a new profile. (There are some analogies I could make to the
old-COVID-19 and the UK variant here, if that would make it easier)

    tt> 5)

    doc> 3. Threat model for MUD URLs Only the DHCP and LLDP MUD URL mechanisms
    doc> are sufficiently close to the firmware version that they can be easily
    doc> updated when the firmware is updated.

    tt> There is no need to limit this draft to DHCP and LLDP
    tt> mechanisms.  Although the IDvID mechanism makes the MUD URL in the
    tt> IDvID certificate unchangeable, it can be assumed that a new MUD URL
    tt> is carried in the firmware when the device is updated. If the new MUD
    tt> URL matches the rules defined in this draft, then it can be considered
    tt> reasonable.

Firmware update do not update the IDevID.
So any MUD URL in the IDevID will not be changed, and will continue to point
to the original file.

    doc> 3.2. Concerns about same-signer mechanism It is possible to invent
    doc> policy mechanisms that would link the EE certificate to a value that
    doc> is in the MUD file.

    tt> What is the function of linking the EE certificate to a
    tt> value that is in the MUD file? How can it solve the problems brought
    tt> by pinning the CA certificate or pinning the EE certificate?

I have split the next sentences into separate paragraphs to help reading:

  } Pinning the EE certificate defends against malware that changes the
  } product type, but keeps the manufacturer from being able to cycle the
  } validity of the End-Entity Certificate for cryptographic hygiene reasons.

  } Pinning the CA certificate allows the EE certificate to change, but may
  } not defend against product type changes.

    doc> 5. Changes to RFC8520 MUD files contain a self-referential MUD-URL
    doc> attribute that point to a MUD file located on the vendor’s web site.

    tt> This sentence may be mistaken as that the MUD-URL
    tt> attribute in multiple MUD files points to the same MUD file. However,
    tt> in fact, the MUD-URL attribute in a certain MUD file points to the MUD
    tt> file itself.

I'm not sure I understand here.
There is a "mud-url" attribute in a MUD file.
It can point at really... anything.
In my opinion (and the opinion of the document), it ought to point to the
canonical location for the MUD file.

    doc> 5. Changes to RFC8520 The URL found in the MUD-URL attribute is to be
    doc> called the canonical MUD URL for the device.

    tt> How to understand the meaning of “canonical MUD URL”?

The place where the manufacturer puts the MUD file, and which they then embed
into IDevID, DHCP, LLDP, etc.
A MUD file could also be delivered to a MUD controller via a number of other
mechanisms, including, perhaps, USB key.
I'm not sure how to explain further.

    doc> 5. Changes to RFC8520 The MUD-SIGNATURE attribute in the MUD file
    doc> SHOULD be a relative URI (see [RFC3986] section 4.2) with the
    doc> (hierarchical) base URL for this reference being the MUD-URL
    doc> attribute.

    tt> Does this sentence mean that The MUD-SIGNATURE attribute in
    tt> the MUD file includes base URI?
    tt> Does “base URL” here has
    tt> the same meaning with “Base-URI” mentioned in the draft?

RFC8520 was unclear how to interpret a relative URI in the MUD-SIGNATURE.
This document intends to update RFC8520 to say that it is relative to the
provide MUD-URL.

So if the mud-url attribute says:
   https://example.com/models/petrocks/version1.json

and the mud-signature contains: "01.sig", then the signature can be
found at:
   https://example.com/models/petrocks/01.sig

However, a MUD controller which knows that it is loading MUD files from a USB
drive (or CIFS network share, or ZIP file...) might also think that it could
look for the signature first in the same place it found the MUD file itself.
But, that's a local configuration option.

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

    tt> I feel that it’s better to make this requirement normative
    tt> here. Is it appropriate to use “MUST” or “SHOULD”?

agreed.

    doc> 11) 6. Privacy Considerations The MUD URL contains sensitive model and
    doc> even firmware revision numbers. Thus the MUD URL identifies the make,
    doc> model and revision of a device.

    tt> It may be recommended that MUD URLs use a random character
    tt> string instead of the plaintext information, because the plaintext
    tt> information is easy to guess (i.e. “The MUD URL contains sensitive
    tt> model…”)

That is something that the manufacturer could consider, but I believe that
the resulting chaos will not be worth the minor privacy gain.
This is not new as RFC8520 already identified:
   {{RFC8520}} already identifies this privacy concern, and suggests use of
   TLS so that the HTTP requests that retrieve the MUD file do not divulge that
   level of detail.

    doc> 7. Security Considerations …depend upon the MUD-manager either not
    doc> checking signatures, or…

    tt> I suggest that replace “MUD-manager” with MUD controller for
    tt> consistency.

Agreed, thank you for noticing.

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