Re: [Gen-art] Genart early review of draft-ietf-opsawg-mud-08

[Eliot Lear <[e-mail]>]

Hi Robert,

Thanks now for BOTH of your reviews.  I've a number of proposals below.

On 9/7/17 5:51 PM, Robert Sparks wrote:

> There is one aspect of caching semantics we should probably capture,
> which is that the cache-validity period should exceed the HTTP cache
> or expiry period as specified by max-age or Expires.  Does that sound
> about right to you?
> Goes in the right direction. Do you expect POST to work with this?

There is no particular POST operation required, but if someone wanted to
POST a MUD file, so long as they also POST a signature file, it should
be fine.

>>
>>> I think there needs to be more discussion of the PKI used for signing MUD
>>> files.
>>
>> We do have some discussion in Section 12.2.  I'm happy to add an
>> additional sentence or two, but would seek guidance on where you
>> think we're missing.
> So, are you expecting to reuse the web PKI here? Will the MUD files be
> signed with the same credentials used by the HTTP server? I'm thinking
> you aren't, and are waving your hands at where trust lies with the
> recommendation that signers be validated directly etc. Either way, I
> think you need to be more explicit and that what you expect for
> establishing trust is going to take more than a couple of sentences.

You're right.  I don't think we want to interlock the signature of the
file with the cert used on the web server.  It *could* be that, but the
focus on trust has to be the signer of the file.  How about something
like this:

    The purpose of the signature on the file is to assign accountability
    to an entity, whose reputation can be used to guide administrators
    on whether or not to accept a given MUD file.  It is already common
    place to check web  reputation on the location of a server on which
    a file resides.  While it is likely that the manufacturer will be
    the signer of the file, this is not strictly necessary, and may not
    be desirable.  For one thing, in some environments, integrators may
    install their own certificates.  For another, what is more important
    is the accountability of the recommendation, and not the
    cryptographic relationship between the device and the file. 


??

This follows the philosophy we've used previously in efforts like DKIM.


>>
>>> Consider discussing whether the stacks used by typical things will let
>>> them add DHCP options (or include bits in the other protocols being 
>>> enabled). If it's well known (I can't say) that these stacks typically
>>> _won't_ provide that functionality, then you should punch up the
>>> discussion of the controllers mapping other identifiers to MUD URLs on
>>> behalf of the thing.
>>
>> I agree.  We allude to this in the draft.  We say, for instance:
>>> It is possible that there may be other means for a MUD URL to be
>>> learned by a network.  For instance, if a device has a serial number,
>>> it may be possible for the MUD controller to perform a lookup of the
>>> device, if it has some knowledge as to who the device manufacturer
>>> is, and what its MUD file server is.  Such mechanisms are not
>>> described in this memo, but are possible.
>>
>> The case we have in mind is LoRaWAN.  Should we go further?
> I think explicitly acknowledging that some things stacks limit their
> behavior will pay back. 

How about a replacement paragraph:

    It is possible that there may be other means for a MUD URL to be
    learned by a network.  For instance, some devices may already be
    fielded or have very limited ability to communicate a MUD URL, and yet
    can be identified through some means, such as a serial number or a
    public key.  In these cases, manufacturers may be able to map those
    identifies 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
    how MUD URLs may be learned.

>
>>> You suggest the DHCP Client (which is a thing) SHOULD log or report 
>>> improper acknowledgments from servers. That's asking a bit much from
>>> a thing. I suspect the requirement is unrealistic and should be removed
>>> or rewritten to acknowledge that things typically won't do that.
>> I think there's a philosophical thing hiding here, though: what
>> expectations should we have of device.  As a SHOULD we're saying, if
>> you have good cause not to, ok.  But otherwise, for the sake of the
>> sanity of the customer, please log.
> Why not acknowledge in the document that the expectation is that most
> won't be able to.
> Painting as explicit and accurate picture as possible can only do
> good, no?
> (Again, I'm not trying to _assert_ that the majority of things can't,
> but that's my suspicion. People who work with this things on a daily
> basis should weigh in.)

Obviously a Thing can be literally anything.  I agree we are setting a
bit of a bar here, but I would rather not let implementors off the
hook.  From an implementation standpoint, the device is already awake in
this case in order to process the packet, and so we're not talking about
excess power consumption.  In the case of really low power, DHCP isn't
going to be in the picture.
>>
>>> The security and deployment considerations sections talk about what the
>>> need for coordination if control over the domain name used in the URL
>>> changes. It should talk more about what happens if the new administration
>>> of the domain is not interested in facilitating a transition (consider
>>> the case of a young company with a few thousand start-up-ish things out
>>> there that loses a suit over its name). Please discuss whether or not
>>> suddenly losing the MUD assisted network configuration is expected to
>>> leave the devices effectively cut-off. 
>>
>> It should not, and here's why:
>>
>>   * Assuming the device has already been used, there is no reason to
>>     simply delete the MUD file from one's cache.  The cache-validity
>>     value is meant as a timer to keep implementations for harassing
>>     the MUD file server, but there's the information is still useful,
>>     even if it may not have been freshened.
>>
> Hrmm - there should be some description about using the information
> even if the cache has expired. That might have security ramifications
> (it at least enables an attacker to cause a set of devices to use old
> information by attacking the access to what might be newer information).

It may be worth "logging and/or reporting".   I think we need
implementation experience to tell us exactly how long to wait before
doing so, however. See below.

>>   * In the case where the MUD file service is unavailable when the
>>     device is first turned up, it's as if it had not included a
>>     MUD-URL in the first place.  While this may be a downgrade
>>     attack, there is, as I understand it, really no way to get around
>>     it, other than for the MUD controller to log a problem.
>>
> Worth a short discussion in the text.

How about this:

    It may not be possible for a MUD controller to retrieve a MUD file at
    any given time.  Should a MUD controller fail to retrieve a MUD file,
    it SHOULD consider the existing one safe to use, at least for a time.
    After some period, it SHOULD log that it has been unable to retrieve
    the file.  There may be very good reasons for such failures, including
    the possibility that the MUD controller is in an off-line environment,
    the local Internet connection has failed, or the remote Internet
    connection has failed.  It is also possible that an attacker is
    attempting to prevent onboarding of a device.  It is a local
    deployment decision as to whether or not devices may be onboarded in
    the face of such failures.



>>  *
>>
>>
>>
>>
>>> Right now, you leave the DHCP server (when it's used) responsible for
>>> clearing state in the MUD controller. Please discuss what happens when
>>> those are distinct elements (as you have in the end of section 9.2) and
>>> the DHCP server reboots. Perhaps it would make sense for the DHCP server
>>> to hand the length of the lease it has granted to the MUD controller and
>>> let the MUD controller clean up on its own?
>>
>> See other response.
>>
>>> The document currently suggests that a piece of software inspect the
>>> WHOIS database to see if registration ownership of a domain has changed.
>>> Do you really mean software, or should this be advice to the
>>> administrator of the controller instead? 
>>
>> The controller.  The idea is to catch bad behavior and anomalies. 
>> And the bigger idea is to reduce the number of decisions that the
>> administrator must make, while providing relevant information with
>> which to make the decisions.
> I don't think this is a reasonable thing to do. It has the many of the
> same properties we complain about when someone suggest that code
> inspect an IANA registry.

This is different.  The registries are REALLY static information and do
not maintain any form of ownership.  Here, if there is an ownership
change, it's a good idea to spot it.  Note that such queries should be
infrequent.  They should only happen when a signer has changed, and when
DNS information has changed.

>>> At section 4, consider pointing out that you are not allowing 
>>> DHCP by default, and that devices that are expected to use DHCP
>>> need to have an explicit allow in their MUD file. 
>>
>> Hmm.  The issue here is that DHCP is an L2 protocol that isn't
>> forwarded.  Do you think it needs to be listed anyway?
> Hmm indeed. You're right. That said, the thing that triggered the thought
> was the ability of a MUD file to say whether or not something can talk to
> other things in the local network. Maybe some reinforcement in the
> discussion
> about what that rule would expand to would prevent someone from walling
> off the device more than you intended (it would be a creative mistake
> to do so,
> I agree)

I'd need a suggestion for that, but since it's a stretch I suggest we
let this one go for now.

Thanks again.

Eliot