[OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

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:
----------------------------------------------------------------------

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 an access control 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"


>      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

Updated: s/intended as an access control mechanism/intended as a post-
compromise mechanism/


>          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?