Spencer Shepler's review of draft-ietf-nfsv4-integrity-measurement-07 about i-d-integrity-measurement

[chucklever]

Some fall-out from resulting conversation:

• Better title would be "Transport and Storage of Linux Integrity Metadata"
• Should state explicitly that the IM architecture does not trust data storage, therefore measurement and appraisal is handled separately from filesystems.
• Document should note that the proposed protocol extension does not enable the construction of an appraisal module; only the transport and storage of the metadata as an opaque blob.
• Despite the narrow focus of this document, there is still some desire to see a specific definition of the metadata format. I proposed adding an Appendix that provides an Informative description of the main formats used today, in lieu of a more complete and standard definition provided in some other venue.

[chucklever]

Spencer's follow-up:

I agree that RFC 8178 provides the ability to add features, particularly attributes, to the protocol and I agree with the utility of 8178 and that is appropriate.

I also agree with the utility of RFC 8276 but I disagree with the interpreted precedent of the RFC per Chuck's comment.

To quote from RFC 8276:

"Xattr keys and values MUST NOT be interpreted
by the NFS clients and servers, as such behavior would lead to
non-interoperable implementations. If there were a need to specify
one or more attributes that servers need to act upon, the appropriate
semantics would be specified by adding a new attribute for the
purpose as provided for by [RFC5661] and [RFC8178]."

I read the proposed integrity measurement capability as providing a "system-level" interpretation.

The decision to allow for the execution of application binaries is a "system" level activity or in other words, a feature that explicitly requires the client to interpret the semantics of the protocol extension. Because of the client's need to interpret the capability, the definition should be defined in a way that it can be implemented in an open fashion and hopefully, but not required, defined in a way that it is "upgradeable".

To the point of "open", I don't believe the availability of open source sufficient in this instance. Yes, a clean-room approach to implementation can be executed but even with that action, a patent claim can still be made. Therefore, without the protocol definition being captured in a way that clearly allows the reader to have a sense that IETF's policies for disclosure have followed, I don't believe it should be allowed as an extension of the NFS protocol.

So, I am left with my objection to this work moving forward.

If this proposal would to be accepted, it sets a precedent that a individual could define a similar extension for their favorite XYZ product in such a way that interoperable implementations could be not implemented. In least this could lead to a proliferation of OS, vendor specific feature creep and at worse, non IP infringing implementations would be impossible to implement.

[chucklever]

Dave's response:

Why isn't the SELinux label work a problem in this regard?

I don't understand Spencer's position well enough to know if he has
a problem with this, but given that this model has already been adopted
by the working group for arguably system-level attributes, it is hard for
me to believe such objections, if they were to exist, would be widely
shared.

Since adopting a parallel approach for the IMA metadata
format is compatible with your plans for -08, perhaps you should
adopt a similar approach (an IANA registry with a specification-required
policy) for IMA. I know that such things have been suggested in the past
and seemed at the time like overkill, but, given that there are a number
of existing formats, and likely there will be a more general format which
has not been arrived at right now, it might be best to take this step,
hoping that it will deal with the objections about the lack of a metadata
format specification even though the Linux community is kind of slow
about producing one. I think you ould have to add a new fs-scope
attribute with the id, rather than stick with the local-policy approach,
but there would b no requirement tat the client check this.

BTW, specification-required and even RFC-required do not require a
normative specification. With specification-required, the IETF does
not have to be involved in writing the spec although a designated-expert
would have to check that it clear enough to enable implementation.

[chucklever]

My conclusion?

It appears that draft-ietf-nfsv4-integrity-measurement can't move forward without some description of the IMA metadata format.

My preference would be that the Linux community is responsible for the process and document(s) that describe their own format. Failing that, a description can be added to integrity-measurement, as I recently proposed.

To make an IANA registry a sensible thing to do, at least one more independent integrity metadata format will have to be identified.

I will see what can be done.