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