Re: Comments on draft-ietf-nfsv4-integrity-measurement-07

Apologies for top posting but I would like to address one portion of this
thread only.

I have poached one particular comment.... the below is quoted from Chuck's
last response on this thread.
--
> I think I lack the background to understand why Spencer doesn't believe
> this is an appropriate use of the NFS protocol, but I don't think that
this
> is the right thread to educate me.

I'm also interested in learning more about this. The same argument has been
made in the past about extending NFS in general, and I guess I had assumed
that this had been resolved with the publication of RFCs 8178 and 8276.

--

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.

Spencer


On Thu, Oct 31, 2019 at 12:54 PM Chuck Lever <[email protected]> wrote:

>
>
> > On Oct 31, 2019, at 3:24 PM, Benjamin Kaduk <[email protected]> wrote:
> >
> > A few points/questions inline:
> >
> > On Tue, Oct 29, 2019 at 11:33:18AM -0400, Chuck Lever wrote:
> >>
> >>> On Oct 29, 2019, at 2:15 AM, spencer shepler <
> [email protected]> wrote:
> >>>>
> >>>> On Mon, Oct 28, 2019 at 1:05 PM Chuck Lever <[email protected]>
> wrote:
> >>>>
> >>>>> On Oct 28, 2019, at 3:28 PM, David Noveck <[email protected]>
> wrote:
> >>>>>
> >>>>
> >>>> In my earlier reply, I proposed breaking this process into two steps:
> >>>>
> >>>> 1. Specify how NFS is to transport IMA metadata in an IETF publication
> >>>> 2. Specify the Linux IMA metadata format itself in some other venue
> >>>>
> >>>> So then:
> >>>>
> >>>> 1. would be a Normative extension to the NFS protocol
> >
> > I'm probably missing something obvious, but why does it have to be a
> > normative extension to the NFS protocol?  Is there some IANA registry
> with
> > a Standards Action registration policy?
> > IETF WGs can publish informational documents, is where I'm going with
> this.
>
> I'm proposing that:
>
> The transport piece would be Normative, as NFS protocol extensions
> typically are.
>
> The metadata format would be Informative, just as you suggest.
>
> Not clear to me how making the transport piece Informative would
> allay concerns about the metadata format.
>
> Btw, I've added Spencer's review along with some thoughts about how
> to address his comments in an issue:
>
> https://github.com/chucklever/i-d-integrity-measurement/issues/7
>
>
> >>>> 2. might be published by the nfsv4 as an Informative description of
> the
> >>>> metadata format, in lieu of getting this published somewhere else.
> Think
> >>>> of it as an illustrative example rather than a hard specification.
> >>>>
> >>>> It still doesn't feel like it's the job of an inter-networking
> standards
> >>>> body to maintain this metadata data format specification, however.
> >>>>
> >>>> Does it make sense to publish either a separate Informative document
> or
> >>>> have an Appendix to this document that provides an Informative example
> >>>> that gives a specific format for Linux IMA metadata?
> >>>>
> >>> Chuck,
> >>>
> >>> Given this last set of responses, you seem to be saying that the only
> implementation of this capability will be with Linux and that you would be
> surprised to find any other implementations that would need to implement
> the support for this feature.
> >>
> >> That's not at all what I'm saying.
> >>
> >> There is currently no published standard definition of the IMA metadata
> format.
> >> I've made it clear from the very beginning that one does not yet exist,
> and
> >> have asked repeatedly whether this will be a problem. For the past 18
> months,
> >> I've gotten the answer "no, it shouldn't be, because NFS
> implementations won't
> >> be required to interpret the metadata format."
> >>
> >> Thus I'm asking for a protocol extension so that NFS can transport, and
> NFS
> >> servers can store, a particular piece of opaque metadata. This is a
> narrow
> >> scope. All I want to do is store and retrieve this metadata via NFS.
> >>
> >> I've been asked to provide the format of the metadata. But at this
> time, no-one,
> >> except for Linux, has stated a plan to actually use it. Thus, this
> sounds like
> >> a piece of this puzzle that can be deferred until it is actually needed
> (or
> >> until someone decides the Linux IMA format is awesome and publishes it).
> >>
> >> I'm also not claiming the metadata format should /never/ be published;
> merely
> >> that we don't need this format definition to create a mechanism for
> storing it.
> >>
> >> - Interpretation of the metadata can be left to the future because
> there is
> >>   a clean dividing line between moving the data and parsing it. This
> allows
> >>   the protocol piece of this work to move forward quickly while we
> wrestle
> >>   with the standards issues around the metadata format.
> >>
> >> - I don't believe the IETF is the right place to publish the metadata
> format.
> >>   The IETF does networking, not data storage and not Trusted Computing.
> If
> >>   we have to publish anything, it should be Informative only. Or maybe
> we
> >>   can approach another standards setting organization where it would be
> more
> >>   appropriate. I'm open to hear arguments either way about this.
> >
> > I'm not arguing that the IETF should take on and publish the Linux IMA
> > format (for one, we don't seem to have many people willing to put energy
> > into doing so), but I will note that the IETF has recently chartered a WG
> > for remote attestation procedures and does have people thinking about
> > endpoint security and endpoint assessment (e.g., the SACM WG).
>
> That's interesting! I'll investigate.
>
>
> >> It seems to me that the only thing that is missing from the current
> document
> >> is a clear statement that this document, by itself, will not enable the
> >> implementation of an IMA appraiser on the NFS server or client. The
> document
> >> does not prevent or forbid future publication that would enable such an
> >> implementation.
> >>
> >>
> >>> So, this is then clearly opening the door for the NFS protocol to be
> used for implementation specific features and to the point that all that is
> needed is an opaque attribute and possibly some error codes to go along
> with it to achieve a side band protocol for that specific implementation.
> And if anyone is interested in the feature, a pointer to some "open source"
> is sufficient.
> >>>
> >>> Well, I don't believe that is an appropriate use of the NFS protocol
> as defined within the IETF.  I apologize if I have the characterization
> incorrect and would be happy to hear otherwise.
> >
> > I think I lack the background to understand why Spencer doesn't believe
> > this is an appropriate use of the NFS protocol, but I don't think that
> this
> > is the right thread to educate me.
>
> I'm also interested in learning more about this. The same argument has been
> made in the past about extending NFS in general, and I guess I had assumed
> that this had been resolved with the publication of RFCs 8178 and 8276.
>
>
> --
> Chuck Lever
>
>
>
>

_______________________________________________
nfsv4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4