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

[Benjamin Kaduk <[e-mail]>]

On Mon, Jun 04, 2018 at 07:50:47PM +0200, Eliot Lear wrote:
> Ben,
> 
> Barring any objections to the below I will issue a new draft with edits
> tomorrow.  Now please see below.

Okay, thanks.  (I'm okay with leaving out the extra text about the
file+signature being untrusted input until the signature is
verifeid.)

-Benjamin

> On 04.06.18 17:40, Benjamin Kaduk wrote:
> > 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.
> 
> I think that's fine.
> >
> >
> > 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"?
> 
> That is fine.
> >
> >                             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.
> 
> Ok.
> >
> > 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.
> 
> I would rather leave this out for the very reasons you state.  The draft
> is already quite wordy.
> >
> > 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".
> 
> Ok
> >
> >    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"?
> 
> the MUD manager.
> >
> >    [...] 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?
> 
> I don't think so.  RFC Editor will sort if so.
> >
> > 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?
> 
> Indeed.  Thanks.
> 
> Eliot
> 
>