Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-23.txt

[Benjamin Kaduk <[e-mail]>]

Hi Eliot,

On Sat, Jun 02, 2018 at 03:40:34PM +0200, Eliot Lear wrote:
> This update contains only the following changes:
> 
>   * A correction (signature -> certificate)
>   * Slightly change language to make clear that the certificate subject
>     must be the sameas the id-pe-mudsigner
>   * Updated dates on the YANG files
> 
> At this point, I really hope we're done.  Eric, Ben?

I think we're basically done -- I have just one quibble which
hopefully is not problematic, and also noted a handful of editorial
things you can deal with at your leisure.  Thanks for going through
the multiple rounds of changes addressing our concerns -- the
document really is much better for it!

At the start of the Security Considerations, we say:

   Based on how a MUD URL is emitted, a Thing may be able to lie about
   what it is, thus gaining additional network access.  This happens
   when a device emits a MUD URL using DHCP or LLDP, and is either
   inappropriately admitted to a class such as "same-manufacturer" or
   given access to a device such as "my-controller", where such access
   would otherwise be disallowed.

To me, "[t]his happens when" indicates that the subsequent
enumeration is an exhaustive list.  I don't really think we've got
enough experience with this stuff to be able to make such a claim,
and the list should instead be treated as illustrative.  I think
that there was some text emailed around that did this nicely,
something like:

%   Based on how a MUD URL is emitted, a Thing may be able to lie about
%   what it is, thus gaining additional network access.  This can happen
%   in a number of ways when a device emits a MUD URL using DHCP or
%   LLDP, such as being inappropriately admitted to a class such as
%   "same-manufacturer", given access to a device such as
%   "my-controller", or being permitted access to an Internet resource,
%   where such access would otherwise be disallowed.


And, here's the editorial stuff.

Section 1.5

   o  A DHCP option[RFC2131],[RFC3315] that the DHCP client uses to
      inform the DHCP server.  The DHCP server may take further actions,
      such as act as the MUD manager or otherwise pass it along to the
      MUD manager.

nit: We lost the immediately previous "URL" that "it" referred to, so we
may want to specifically say "pass the MUD URL along".

Section 13.2

   Prior to processing the rest of a MUD file, the MUD manager MUST
   retrieve the MUD signature file by retrieving the value of "mud-
   signature" and validating the signature across the MUD file.  The Key
   Usage Extension in the signing certificate MUST have the bit
   digitalSignature(0) set.

nit: do we need to go with "MUST be present and have the bit
digitalsignature(0) set"?

                            The subject of this certificate MUST be
   equal to that of the value of id-pe-mudsigner when that extension is
   present in the device certificate.  If these conditions are not met,
   or if it cannot validate the chain of trust to a known trust anchor,
   the MUD manager MUST cease processing the MUD file until an
   administrator has given approval.

nit-level as well, I guess: I might wordsmith this differently.

NEW:

   When the id-pe-mudsigner extension is present in a device's X.509
   certificate, the MUD signature file MUST have been generated by
   a certificate whose subject matches the contents of that
   id-pe-mudsigner extension.  If these conditions are not met,
   or if it cannot validate the chain of trust to a known trust anchor,
   the MUD manager MUST cease processing the MUD file until an
   administrator has given approval.

I might also consider adding something like the following (though
hopefully it would be obvious and thus not necessary to say):

   Before the signature has been validated, both the MUD file and
   the resource retrived from the "mud-signature" URL are unverified
   and should be treated as untrusted input.  In particular, MUD
   managers can impose a cap on the number of bytes they retrieve
   from a "mud-signature" URL, to avoid DoS attacks involving
   presenting a large (invalid) signature file or similar scenarios.

Section 16

   Implementations SHOULD be configurable to
   disallow additive access for devices using MUD-URLs that not emitted
   in a secure fashion such as in a certificate.

nit: "that are not emitted".

   When certificates are not present, Things claiming to be of a certain
   manufacturer SHOULD NOT be included in that manufacturer grouping
   without additional validation of some form.  This will be relevant
   when it makes use of primitives such as "manufacturer" for the
   purpose of accessing Things of a particular type.

What is "it" that makes use of primitives such as "manufacturer"?

   [...] If the actual MUD file has changed, the MUD
   manager MAY check the WHOIS database to see if registration ownership
   of a domain has changed.

Do we need a reference for WHOIS?

Appendix C

   In this sample extension we augment the core MUD model to indicate
   whether the device implements DETNET.  If a device claims not to use
   NETNET, but then later attempts to do so, a notification or exception

That's also supposed to be 'D'ETNET, right?

-Benjamin