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

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Apr 2018 04:32:44 -0700

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?

---

From: Eliot Lear <[email-masked]>
Date: Sun, 15 Apr 2018 19:28:09 +0200

Hi Eric,

> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/

MUD is primarily intended to address the former, but provides some
benefit against the latter in some cases.  In particular, MUD is
intended to keep devices from getting infected in the first place.  As a
side-effect, if a device *is* broken into, it may be possible to either
prevent additional access, or otherwise detect the break-in based on a
change in profile.  I propose to state this more clearly in the
introduction, as follows:

NEW:

MUD primarily addresses threats to the device rather than the device as
a threat.  In some circumstances, however, MUD may offer some protection
in the latter case, depending on the MUD-URL is communicated, and how
devices and their communications are authenticated.

**
> context if the firmware can change the client's L2 address).

Yes, configuration is intended to be removed when a device disconnects
or a session terminates.  This would be considered normal garbage
collection.  But whether or not you can simply replace the firmware and
gain the same access will depend on how the MUD-URL is learned.  If it
is in a manufacturer certificate, for instance, that's not something an
attacker will easily replace.  If the assertion is coming via LLDP, or
DHCP, then one has to apply the mitigations discussed in the security
considerations section (and they are numerous).

> characteristics from the URL.

This is a bit of an artifact from some changes in earlier versions,
which did indeed have a schema.  I propose to replace that paragraph as
follows:

A manufacturer may construct a MUD URL in any way, so long as it makes
use of the "https" schema.

> interoperably without some more guidance.

Indeed.  I've proposed some additional text to Robert in his genart
review along the following lines:

NEW:

>    It is expected that the Key Usage extension would contain "Digital
>    Signature" and that the extended key usage would include either "code
>    signing" or "email protection".  What is important is simply that the
>    verification step match the purpose of the signing certificate to its
>    use.  It is not expected that the normal Web PKI will be used.  For
>    one thing, typically key usage does not allow signatures.

I would expect future versions of MUD to refine this, as we're just
getting started.

How about "end devices"?  That makes it clear in the abstract.  I don't
propose to do a global substitute, because we scope the term well in the
introduction, as you note directly below.

> purpose computers (turing complete, etc.)

That these objects might happen to use a general purpose CPU or
operations system doesn't in and of itself make them general purpose
devices.  As a complete SKU they are sold with a single or small number
of uses in mind.  That is what is posited.  Is there a way to make that
clearer?

> in S 1.1 that the communication pattern of other devices is too

I think this statement is predicated on your previous comment, and would
prefer not to change text at this time.

> bulbs over Tor and then I would want it to act as a Tor hidden

I would be happy to add a statement that MUD works best where both
endpoints can be identified in some fashion.

>>      possible.  Implementors should allow for this sort of flexibility of

No I didn't.  While I don't feel that strongly,  I do believe in the
advice we are giving here, it is not required for interoperability or
security, and so I tend to shy away from normative language in such
cases.  To avoid confusion, how about: “Implementors are encouraged to
allow...”, and as a bonus I propose to unscramble the rest of that
sentence which reads a little funny, editorially.

>>      They MUST validate the certificate using the rules in [RFC2618],

Yes I do, thank you.

> Nit: "serialization format"
Ok by me.

>>          the Thing type is known, it may skip this step.

Propose: “or the administrator has established a policy for things
matching this URL” (noting security considerations below).

> This appears to be the only container.

Propose s/container/component/ as the next two state.
> MUST contain
I could envision a manufacturer not wanting to specify access controls,
but still wanting to indicate perhaps the meta-information.  I can
clarify this as follows:

A valid MUD file MUST contain a "mud" container and MAY contain an
optional access-lists container that will be present whenever access
controls are to be requested.

>>      authority component of another Thing's MUD URL.  In its simplest form

This is stated in the YANG.
> "controller" is encoded in the YANG model, perhaps "MUD agent"?

Ok.  You're the last person who's going to complain about this ;-).
"Agent" is probably isn't what we're looking for because it is generally
used a term for a process that runs on a managED device.  How about MUD
manager?
> SYN seems over-specific here, as it doesn't apply to UDP-based

The mechanism is only appropriate for TCP and SYN is merely intended as
an example. Will make this more clear in the text.

> but then you would be able to handle extensions that brought the total

This came as part of a late discussion with mnot and Adam, and it would
require a lot of recoding for one byte.  If you were to look in previous
versions you would have found this to be part of the URL, causing us
some issues with BCP 190.  We should have the discussion about BCP 190,
but want to move forward in the meantime without a big implementation
impact.

> is confusing in the context of string processing because of C

This text is rewritten based on the GENART review.  The requirement for
an acknowledgment is proposed to be removed.  Please see the thread with
Robert for the text.
> This is a decision for the WG, but why aren't you using JWS?

For our purposes we are talking about a file, and its format isn't
really at issue (which is good because it has changed in the life of
this document, and could change again at some point).  The file just
needs signing, and the goal was to integrate with commonly used and
available tool sets.  This having been said, I could easily envision
this evolving in future versions.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Apr 2018 12:22:42 -0700

On Sun, Apr 15, 2018 at 10:28 AM, Eliot Lear <[email-masked]> wrote:

> The document, along with other ballot positions, can be found here:https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>
>
> Rich version of this review at:https://mozphab-ietf.devsvcdev.mozaws.net/D3106
>
>
> MUD is primarily intended to address the former, but provides some benefit
> against the latter in some cases.  In particular, MUD is intended to keep
> devices from getting infected in the first place.  As a side-effect, if a
> device *is* broken into, it may be possible to either prevent additional
> access, or otherwise detect the break-in based on a change in profile.  I
> propose to state this more clearly in the introduction, as follows:
>
> NEW:
>
> MUD primarily addresses threats to the device rather than the device as a
> threat.  In some circumstances, however, MUD may offer some protection in
> the latter case, depending on the MUD-URL is communicated, and how devices
> and their communications are authenticated.
>

LGTM

> Yes, configuration is intended to be removed when a device disconnects or
> a session terminates.  This would be considered normal garbage collection.
> But whether or not you can simply replace the firmware and gain the same
> access will depend on how the MUD-URL is learned.  If it is in a
> manufacturer certificate, for instance, that's not something an attacker
> will easily replace.  If the assertion is coming via LLDP, or DHCP, then
> one has to apply the mitigations discussed in the security considerations
> section (and they are numerous).
>

I'm not following you here. Say it's in a manufacturer certificate, what
stops me from getting my own certificate for Attacker LLC and then serving
a wide open policy? The mitigations don't really seem to do much to
counteract this.

> This is a bit of an artifact from some changes in earlier versions, which
> did indeed have a schema.  I propose to replace that paragraph as follows:
>
> A manufacturer may construct a MUD URL in any way, so long as it makes use
> of the "https" schema.
>

LGTM.

> Indeed.  I've proposed some additional text to Robert in his genart review
> along the following lines:
>
> NEW:
>

This doesn't seem to address my concern, which is that there's no realistic
way of knowing
what trust anchors apply. If it's not WebPKI, then what? There's also a
factual error here:
WebPKI certificates generally do do assert digitalSignature, because
otherwise you
can't do (EC)DHE.

To be honest, I would do a search and replace, but I agree that theis would
resolve the ambiguity here.

> That these objects might happen to use a general purpose CPU or operations
> system doesn't in and of itself make them general purpose devices.  As a
> complete SKU they are sold with a single or small number of uses in mind.
> That is what is posited.  Is there a way to make that clearer?
>

Perhaps "not intended to be used for general purpose computing tasks"

> prefer not to change text at this time.

Hmmm.... No, I don't think you're reading me right here. I'm just saying
that it would be useful upfront to say that MUD
is about saying "this is what communications pattern these devices are
expected to have"

> endpoints can be identified in some fashion.

Sure. I was just objecting to the implication that that's the only way one
might want to run one's system.

> security, and so I tend to shy away from normative language in such cases.
> To avoid confusion, how about: “Implementors are encouraged to allow...”,
> and as a bonus I propose to unscramble the rest of that sentence which
> reads a little funny, editorially.
>

SGTM.

> matching this URL” (noting security considerations below).

SGTM.

> Propose s/container/component/ as the next two state.

SGTM.

> but still wanting to indicate perhaps the meta-information.  I can clarify
> this as follows:
>

SGTM.

> This is stated in the YANG.

OK.

> used a term for a process that runs on a managED device.  How about MUD

OK.

> The mechanism is only appropriate for TCP and SYN is merely intended as an
> example. Will make this more clear in the text.
>

OK.

> versions you would have found this to be part of the URL, causing us some
> issues with BCP 190.  We should have the discussion about BCP 190, but want
> to move forward in the meantime without a big implementation impact.
>

To be clear, it's not about saving a byte, but about having a more legible
and extensible encoding. However, it's a matter of taste, I agree.

> This text is rewritten based on the GENART review.  The requirement for an
> acknowledgment is proposed to be removed.  Please see the thread with
> Robert for the text.
>

OK.

> For our purposes we are talking about a file, and its format isn't really
> at issue (which is good because it has changed in the life of this
> document, and could change again at some point).  The file just needs
> signing, and the goal was to integrate with commonly used and available
> tool sets.  This having been said, I could easily envision this evolving in
> future versions.
>

Sure, this is just a matter of consistency, and have having to only support
one technology platform, but I can see how one would come to a different
decision.

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Mon, 16 Apr 2018 08:27:08 +0200

Hi Eric,

Trimming.

On 15.04.18 21:22, Eric Rescorla wrote:
>     Yes, configuration is intended to be removed when a device
>     disconnects or a session terminates.  This would be considered
>     normal garbage collection.  But whether or not you can simply
>     replace the firmware and gain the same access will depend on how
>     the MUD-URL is learned.  If it is in a manufacturer certificate,
>     for instance, that's not something an attacker will easily
>     replace.  If the assertion is coming via LLDP, or DHCP, then one
>     has to apply the mitigations discussed in the security
> I'm not following you here. Say it's in a manufacturer certificate,
> what stops me from getting my own certificate for Attacker LLC and
> then serving a wide open policy? The mitigations don't really seem to
> do much to counteract this.

I believe this point and one down below, where you write:
> This doesn't seem to address my concern, which is that there's no
> realistic way of knowing
> what trust anchors apply. If it's not WebPKI, then what? 
are related, and so I propose to address them together, and this text
could go into security considerations.  The *intent* is that mud
managers or their providers will keep a list of known trusted signers. 
Examples are likely to include certification bodies (we are aware of at
least one that is very interested), the MUD manager vendor themselves,
and perhaps others.  Because these are early days, I don't want to be
too declarative, but we can say this:

NEW:

---
MUD managers and their administrators MUST NOT automatically trust a
manufacturer's certificate simply because it validates.  Rather, the
certificate MUST be signed by an entity that has previously established
trust for this explicit purpose.  In particular, the WebPKI alone is not
appropriate.
---

That means that just because Joe Evil signed the darn thing doesn't mean
that we should believe it.  On the other hand, I might trust a security
company to vet this stuff.  Would this address your concern?  Also, I'll
correct the previous factual error.

And again, I view this as early days.  The architecture is going to need
some time to mature and evolve.

>     How about "end devices"?  That makes it clear in the abstract.  I
>     don't propose to do a global substitute, because we scope the term
>     well in the introduction, as you note directly below.
>
>
> To be honest, I would do a search and replace, but I agree that theis
> would resolve the ambiguity here.
>
>
>     operations system doesn't in and of itself make them general
>     purpose devices.  As a complete SKU they are sold with a single or
>     small number of uses in mind.  That is what is posited.  Is there
>     a way to make that clearer?
>
>

Ok.

>     I think this statement is predicated on your previous comment, and
>     would prefer not to change text at this time.
>
>
> Hmmm.... No, I don't think you're reading me right here. I'm just
> saying that it would be useful upfront to say that MUD

Ok.  I think that's a good add, and propose to add a statement based on
your quoted text.

Thanks again,

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Apr 2018 05:25:04 -0700

Hi Eliot,

Thanks for continuing the conversation. My question is how this fits into
the system as a whole.

ISTM that there are two ways in which a MUD policy can affect the network's
behavior:

- Additive -- it lets the device do things it otherwise might not be
permitted to do (e.g., accept incoming TCP connections)
- Restrictive -- it stops the device from doing things that it otherwise
would be permitted to do (e.g., make connections to IP addresses on non-443
ports)

In the former case, it's very important not to be able to forge acceptable
MUD policies, but in the latter case, an attacker can just not serve *any*
MUD policy and be in a stronger position than they would be if they had a
valid policy, Thus, it's only in the former (additive) case where forging a
policy is useful to the attacker, and, in fact, it seems like accepting an
unsigned MUD policy would be better than no policy. Given the ubiquity of
non-MUD devices and the relatively limited capabilities that MUD seems to
want to convey, it seems like the additive case isn't very useful.

I should mention one use case that I did think of, where additive would be
immediately useful: "This device is made by the same manufacturer as
another device (and hence they can talk to each other). However, I note
that MUD is actually not capable of securely conveying that, because
there's no proof that the device in hand actually is made by the
manufacturer, only that it possesses a public credential for some device
made by that manufacturer. So, I'm actually left wondering how that feature
is intended to work. I regret not catching this earlier, but perhaps you
could explain?

Thanks,
-Ekr

On Sun, Apr 15, 2018 at 11:27 PM, Eliot Lear <[email-masked]> wrote:

> could go into security considerations.  The *intent* is that mud managers
> or their providers will keep a list of known trusted signers.  Examples are
> likely to include certification bodies (we are aware of at least one that
> is very interested), the MUD manager vendor themselves, and perhaps
> others.  Because these are early days, I don't want to be too declarative,
> but we can say this:
>
> NEW:
>
> ---
>> devices.  As a complete SKU they are sold with a single or small number of
>> uses in mind.  That is what is posited.  Is there a way to make that
>> clearer?
>>
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 16 Apr 2018 08:03:59 -0500

I haven't balloted yet, and this is EKR's ballot thread, but one point is
worth bringing up here ...

On Mon, Apr 16, 2018 at 7:25 AM, Eric Rescorla <[email-masked]> wrote:

> ISTM that there are two ways in which a MUD policy can affect the
> network's behavior:
>

I've read previous versions of this draft and some of the mailing list
discussion, but not a lot. Having said that, I hadn't heard anyone express
the possibility of the additive case described here. The context I always
heard about, was roughly "we've gotta keep all the coke machines on campus
from doing anything except reporting that they need to be refilled", or
whatever variation of cameras, printers, or *mumble* have access to your
network for a specific reason, are running some arbitrary version of some
OS stack that included TCP or UDP capabilities, aren't being maintained
enough to be current on security patches, and aren't being managed, so are
ripe for attacks to create botnets.

Perhaps I need to get out more. Almost certainly. But ... the possibility
of additive policies is interesting, and new to me.

I'll be interested to watch this discussion. Eric, thanks for asking the
question.

Spencer

>>> gain the same access will depend on how the MUD-URL is learned.  If it is
>>> in a manufacturer certificate, for instance, that's not something an

---

From: Eliot Lear <[email-masked]>
Date: Mon, 16 Apr 2018 15:55:29 +0200

Hi Eric,

On 16.04.18 14:25, Eric Rescorla wrote:
> Hi Eliot,
>
> Thanks for continuing the conversation. My question is how this fits
> into the system as a whole.
>
> - Restrictive -- it stops the device from doing things that it
> otherwise would be permitted to do (e.g., make connections to IP
> addresses on non-443 ports)

What you describe is the choice of the network administrator, and not
the standard nor the manufacturer.  You are essentially asking, “what is
the default policy?” and that will vary based on deployment.  It could
be "additive", "restrictive", or something else.  It could be a
walled-off IoT network.  Consider the cases:

  * This device has a MUD file and will be segmented accordingly.
  * This device has no MUD file and we may,
      o 1: give it no access,
      o 2: give it all access,
      o 3: give it some limited access,
      o 4: ask, or
      o 5: other.

All of these are perfectly valid approaches, depending on the deployment.
>
> In the former case, it's very important not to be able to forge
> acceptable MUD policies, but in the latter case, an attacker can just
> not serve *any* MUD policy and be in a stronger position than they
> would be if they had a valid policy,[...]

And so that will depend on the deployment.  And many of the attacks
would be detectable.  All?  I would never be so bold.  But also, MUD is
not an acronym for "magic bullet".  I really did try to spell that out
in the draft.

> I should mention one use case that I did think of, where additive
> would be immediately useful: "This device is made by the same
> manufacturer as another device (and hence they can talk to each
> other). However, I note that MUD is actually not capable of securely
> conveying that, because there's no proof that the device in hand
> actually is made by the manufacturer, only that it possesses a public
> credential for some device made by that manufacturer.

That is the point of building out a PKI, and as I wrote, there are some
interested in providing what amounts to a certification for this
purpose.  This is also something the MUD manager can take on: as time
goes on it can white list signers, and it can flag devices that are not
recognized as being risky.  In addition, if you have someone willing to
take accountability for that device to lay a claim, it may not be
"proof", but that is  good enough in an enterprise environment, where
someone can be called to account for having added the device.

And we have to start somewhere.  The goal here it to establish a “walk
before we run” approach in several dimensions.  I just ask that we be
allowed to walk ;-)

With that, how would you like to proceed?  I've proposed text but could
go further if you like.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Apr 2018 07:03:29 -0700

On Mon, Apr 16, 2018 at 6:55 AM, Eliot Lear <[email-masked]> wrote:

> What you describe is the choice of the network administrator, and not the
> standard nor the manufacturer.  You are essentially asking, “what is the
> default policy?
>

No, I'm not asking that. What I'm looking for is the document to describe
the various use cases and ensure that the mechanisms it provides actually
be able to effect those use cases.

> valid policy,[...]
> And so that will depend on the deployment.  And many of the attacks would
> be detectable.
>

How would those attacks be detectable?

> made by that manufacturer.
>
>
> interested in providing what amounts to a certification for this purpose.
> This is also something the MUD manager can take on: as time goes on it can
> white list signers, and it can flag devices that are not recognized as
> being risky.  In addition, if you have someone willing to take
> accountability for that device to lay a claim, it may not be "proof", but
> that is  good enough in an enterprise environment, where someone can be
> called to account for having added the device.
>

Well, there are two types of PKI here:

1. The one associated with the device certificate
2. The one associated with the MUD signature.

My point is that only the former provides any assurance that the actual
device has anything to do with the manufacturer. In the latter case, I can
just stuff the URL of any manufacturer's MUD policy in my device that I
please.

-Ekr