Eric Rescorla has entered the following ballot position for draft-ietf-opsawg-mud-20: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Re-posted due to pilot error. Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3106 The threat model for MUD doesn't seem clear, at least to me. It seems like there are at least two potential threat models: - Telling the network how to configure access control to prevent the device from being compromised - Telling the network how to configure access control the limit the damage in case a device is compromised (e.g., avoiding its use in a botnet). Are both of these in scope? If so, the latter seems to need substantially more analysis -- and perhaps mechanism -- because it seems relatively easy for the attacker to evade access control limits once it has replaced the firmware on the device (as noted below). In either case, the document needs to be clear about this, whether in the security considerations or elsewhere. IMPORTANT > The certificate extension is described below. > > The information returned by the MUD file server (a web server) is > valid for the duration of the Thing's connection, or as specified in > the description. Thus if the Thing is disconnected, any associated > configuration in the switch can be removed. Similarly, from time to IMPORTANT: What does "disconnected" mean in this context? Does a reboot count? What if I am wireless? This is a critical question if MUD is intended as a post-compromise mechanism. Say that an attacker compromises the firmware for a device and then forces a reboot followed by a 2 hour pause before the wireless NIC is activated. Will this result in configuration removal? If so, MUD seems of limited use, because it can then make itself appear to be a new device with a new MUD configuration. (This is of course true in general in a wireless context if the firmware can change the client's L2 address). > https://example.com/lightbulbs/colour/v1 > > The MUD URL identifies a Thing with a specificity according to the > manufacturer's wishes. It could include a brand name, model number, > or something more specific. It also could provide a means to > indicate what version the product is. IMPORTANT: Are you just using "identify" loosely here? I see how it can be *based* on those characteristics, but absent a schema it doesn't seem like the MUD controller can infer any of those characteristics from the URL. > -in mudfile -binary -outform DER - \ > -certfile intermediatecert -out mudfile.p7s > > Note: A MUD file may need to be re-signed if the signature expires. > > 12.2. Verifying a MUD file signature IMPORTANT: This seem underspecified. Is the intention that these certificates will be rooted in the WebPKI? Something else? I realize that IETF tends to be kind of vague about where trust anchors come from, but at the end of the day its hard to see how to implement this interoperably without some more guidance. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- > > Abstract > > This memo specifies a component-based architecture for manufacturer > usage descriptions (MUD). The goal of MUD is to provide a means for > Things to signal to the network what sort of access and network I realize that "Things" has become a marketing term, but it's opaque and unnecessary here. "elements" would be the conventional term. > it continues to make sense for general purpose computing devices > today, including laptops, smart phones, and tablets. > > [RFC7452] discusses design patterns for, and poses questions about, > smart objects. Let us then posit a group of objects that are > specifically not general purpose computers. These devices, which I don't think this makes sense. These devices usually *are* general purpose computers (turing complete, etc.) and not infrequently run the same operating systems (Android, for instance), but they're intended for specific purposes. In fact the core of the problem is that they are general purpose computers but embedded in a limited purpose device. > specifically not general purpose computers. These devices, which > this memo refers to as Things, have a specific purpose. By > definition, therefore, all other uses are not intended. The > combination of these two statements can be restated as a manufacturer > usage description (MUD) that can be applied at various points within > a network. I would make the point here that the purpose of the MUD is to describe the communications pattern. You only really get that by the statement in S 1.1 that the communication pattern of other devices is too complicated to profile. > can say about that light bulb, then, is that all other network access > is unwanted. It will not contact a news service, nor speak to the > refrigerator, and it has no need of a printer or other devices. It > has no social networking friends. Therefore, an access list applied > to it that states that it will only connect to the single rendezvous > service will not impede the light bulb in performing its function, This *might* be true, but imagine that I wanted to control my light bulbs over Tor and then I would want it to act as a Tor hidden service. > a public key. In these cases, manufacturers may be able to map those > identifiers to particular MUD URLs (or even the files themselves). > Similarly, there may be alternative resolution mechanisms available > for situations where Internet connectivity is limited or does not > exist. Such mechanisms are not described in this memo, but are > possible. Implementors should allow for this sort of flexibility of Do you mean SHOULD? > 1.6. Processing of the MUD URL > > MUD controllers that are able to do so SHOULD retrieve MUD URLs and > signature files as per [RFC7230], using the GET method [RFC7231]. > They MUST validate the certificate using the rules in [RFC2618], > Section 3.1. ITYM 2818. > > The files that are retrieved are intended to be closely aligned to > existing network architectures so that they are easy to deploy. We > make use of YANG [RFC7950] because of the time and effort spent to > develop accurate and adequate models for use by network devices. > JSON is used as a serialization for compactness and readability, Nit: "serialization format" > domain reputation service, and it may test any hosts within the > file against those reputation services, as it deems fit. > > 4. The MUD controller may query the administrator for permission to > add the Thing and associated policy. If the Thing is known or > the Thing type is known, it may skip this step. What is a "Thing type"? > > 2.1. The IETF-MUD YANG Module > > This module is structured into three parts: > > o The first container "mud" holds information that is relevant to This appears to be the only container. > > o The third component augments the tcp-acl container of the ACL > model to add the ability to match on the direction of initiation > of a TCP connection. > > A valid MUD file will contain two root objects, a "mud" container and MUST contain? > extension example can be found in Appendix C. > > 3.9. manufacturer > > This node consists of a hostname that would be matched against the > authority component of another Thing's MUD URL. In its simplest form In what encoding? > the expression as is appropriate in their deployments. > > 3.13. controller > > This URI specifies a value that a controller will register with the > MUD controller. The node then is expanded to the set of hosts that The use of "controller" and "MUD controller" is very unfortunate terminology. Could you perhaps rename one of these? Given that "controller" is encoded in the YANG model, perhaps "MUD agent"? > corresponding direction. [RFC6092] specifies IPv6 guidance best > practices. While that document is scoped specifically to IPv6, its > contents are applicable for IPv4 as well. When this flag is set, and > the system has no reason to believe a flow has been initiated it MUST > drop the packet. This node may be implemented in its simplest form > by looking at naked SYN bits, but may also be implemented through SYN seems over-specific here, as it doesn't apply to UDP-based protocols. > reserved = 1*( CHAR ) ; from [RFC5234] > > The entire option MUST NOT exceed 255 octets. If a space follows the > MUD URL, a reserved string that will be defined in future > specifications follows. MUD controllers that do not understand this > field MUST ignore it. This is a matter of taste I suppose, but why not just have two chunks in the option. The cost would be one byte in the non-extension case but then you would be able to handle extensions that brought the total length above 255. > 9.2. Server Behavior > > A DHCP server may ignore these options or take action based on > receipt of these options. If a server successfully parses the option > and the URL, it MUST return the option with length field set to zero > and a corresponding null URL field as an acknowledgment. Even in What this means here is "no URL field"? Generally, the use of "null" is confusing in the context of string processing because of C semantics. > > Because MUD files contain information that may be used to configure > network access lists, they are sensitive. To insure that they have > not been tampered with, it is important that they be signed. We make > use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] for > this purpose. It's very odd to be using CMS here when you are serializing in JSON. This is a decision for the WG, but why aren't you using JWS? _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg