From: Marco Tiloca Subject: Review of draft-richardson-mud-qrcode-02 Date: Sat, 11 Dec 2021 17:03:49 +0100 To: draft-richardson-mud-qrcode@ietf.org Cc: rfc-ise@rfc-editor.org Hi all, I was asked to review this draft for possible publication as an Independent Submission. In general, I believe it would be good to publish it an an Independent Submission Informational RFC. The introduction section does a good job in motivating the protocol and what real-world gaps it fills. I do not see any particular harm for the Internet in it either. Please, see below some more detailed comments and suggestions to hopefully improve the document. Best, /Marco [Abstract] * Please, expand the MUD acronym. [Introduction] * "to communicate the URL of the resulting JSON [RFC8259] format file to a network enforcement point"    I suggest to rephrase as: "to communicate to a network enforcement point the MUD URL, i.e., the URL of the resulting MUD file in JSON [RFC8259] format" * "no manufacturers include MUD URLs in their products as there are no gateways that use them.  No gateways include code that processes MUD URLs as no products produce them."    I suggest to rephrase this as follows, unless the claims "no manufacturers" and "no gateways" are actually factual.    "manufacturers are not motivated to (and thus likely do not) include MUD URLs in their products, as they believe that there are no gateways using those URLs. At the same time, gateways have little incentive to (and thus likely do not) include code that processes MUD URLs, as it is believed that no products have and disseminate them." * "Such an action ..."    Perhaps clarify that this refers to affixing and not scanning. * The QR-based protocol is presented as a convenient alternative when the mechanisms from RFC 8520 are not available to use, on the device or the gateway.    Suppose those mechanisms are available instead, at least on the device. I guess it would still be useful to possibly apply also a sticker to the device anyway, in case the gateway does not have support for the RFC 8520 mechanisms, right?    But then, if the device supports the RFC 8520 mechanisms and has also a sticker, should the network operator not let the device first use those, before considering the QRcode as backup option? [Section 2] * "Although this document is not an IETF Standards Track publication, it adopts the conventions for normative language to provide clarity of instructions to the implementer."    I think you can remove this sentence. As per the update done to BCP 14 in Section 2 of RFC 8520, the BCP 14 terminology is applicable to "IETF documents", not only to Standards Track documents. * The paragraph with the BCP 14 terminology is now included twice. * It would be good to also include: i) the usual disclaimer about the readers expected to be familiar with ...; ii) any key terms among the most used ones, e.g., MUD file and MUD URI, even though not newly defined in this document. [Section 3] * s/in the next section/in Section 3.1 * I am not knowledgeable on QRcode format and encoding, so I mostly trusted the correctness of Section 3 and its subsections. It would be good if an expert can also have a close look at these details. [Section 3.2.2] * "It is the Product Name in ASCII."    This would better be the second or third sentence in the paragraph, rather than the last one. [Section 3.2.4] * As to the mentioned lifetime of the QRcode, does it refer to an expiration of the QRcode (encoded in the QRcode itself ?) or to its expected physical deterioration that would prevent a scanning from working? * "the privacy stance of the service is well understood"    And presumably also "fine to accept" for the end user, right? :-) [Section 3.2.5] * If I understand correctly, you are reusing an already defined Data Record to specify the MAC address. Then, the section title can simply be "Device MAC Address", i.e., with no need to specifically involve MUD. * Here it is mentioned that "a unique identifier must be provided to the MUD controller". However, it becomes clear only later in Section 7 that the actual use and inclusion of a MAC address in the QRcode is optional, since the network operator might rely on other means to associate policies to a device. I think it should be clarified here already, i.e., "If a MAC address is used as unique device identifier (which is RECOMMENDED if possible), then it MUST be included in this Data Record". [Section 4] * "(ACLs) implemented"    Do you mean "enforced in the system/network"? Or implemented by whom? Also, ACLs are a particular way to enforce access control. Perhaps you actually mean "access control policies"? * "... it is prudent to use a MUD URL which points to a MUD file which will only have new features added over time, and never have features removed."    Is it actually possible to make such a prediction in a reliable way? If not, what is the practical course of action to take if features are at some point removed for some reason? [Section 7] * "It is conceivable that something more active is concealed in the sticker: an NFC or RFID tag for instance."    I understand that one has to just live with this and its consequences, but what are they? Is this just about the "smuggling" of NFCs/RFIDs in itself, or can those be used to build up something more and worse? * s/may become a trusted device/may be seen as a trusted device * "Another issue with the stickers ..."    Right, so could you add some more discussion on possible mitigations? I suppose that either there is absolute trust in the good faith and correctness of the party applying the sticker, or it is good that the network/system administrator inspects and sanity-checks the QR code before deploying the device (which is probably good to do anyway). This requires to know the party that applied the sticker. * "Including the MAC address requires that the QRcode for that device requires that a unique sticker be created for each device."    This would read better as: "Including the MAC address requires that a unique sticker with a QRcode be created for each device." * "This makes it more likely that a policy will be applied to the wrong device."    Unless the intention is actually applying a same policy to all devices, I suppose that a network operator should indeed rely on different means than MAC addresses to uniquely identify devices. * I think it would be good to add considerations on the security of the (access to the) physical premises, and on the trust required on the network operators performing device deployment and QRcode scanning on those premises. [Section 10.1] * I think that the reference [grcode] can be an informational reference instead. [Section 10.2] * I wonder if [isoiec18004] should rather be a normative reference. [Nits] * Section 1 - s/No gateways/At the same time, no gateways - s/described here/described in this document - s/will need to non-firmware/will need to be non-firmware * Section 3.1 - s/Seperator/Separator (2 occurrences) * Section 3.2 - s/It's presence/Its presence * Section 5 - s/about 30/to about 30 - s/to be applied/and to be applied * Section 6 - s/should not placed/should not be placed * Section 7 - s/of at QRcode/of a QRcode - s/sticker or ... will not affect/sticker nor ... will affect - s/camoflage the device/camouflage those devices - s/addresss/address - s/then has to/has to - s/having the MAC address include/having the MAC address includes -- Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistagången 16 SE-164 40 Kista (Sweden)