Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-01.txt

[Chuck Lever <[e-mail]>]

> On Sep 27, 2018, at 2:55 AM, David Noveck <[e-mail]> wrote:
> 
> > Why would it not be sufficient to implement client support? 
> 
> I think it is sufficient.
> 
> > Or, what do you believe might be missing in the draft?  
> 
> Not sure what Bruce had in mind but I think the problem is something that is in the draft that shouldn't be, rather than something missing.
> 
> >> How do you propose that an implementation would make the information
> >> self-describing?
> 
> > That is out of scope for this draft.  
> 
> If so, then so is "MUST (emphasis added) be self-describing".

I don't agree.

MUST means that we are stating a requirement for correct
interoperability. A self-describing FPI payload is a requirement
for interoperation. Implementers, as always, are free to ignore
this requirement.


> > But typically if an integrity service wanted to do this
> 
> If it were really a "MUST", then what an integrity service wants to do should be irrelevant.

I'm open to suggested replacement texts.


> On Wed, Sep 26, 2018 at 4:27 PM Chuck Lever <[e-mail]> wrote:
> 
> 
> > On Sep 26, 2018, at 1:21 PM, [e-mail] wrote:
> > 
> > On Mon, Sep 24, 2018 at 10:45:29AM -0500, Spencer Dawkins at IETF wrote:
> >> Hi, Chuck,
> >> On Mon, Sep 24, 2018 at 10:06 AM Chuck Lever <[e-mail]> wrote:
> >> 
> >>> 
> >>> 
> >>>> On Sep 24, 2018, at 7:55 AM, [e-mail] wrote:
> >>>> 
> >>>> 
> >>>> A New Internet-Draft is available from the on-line Internet-Drafts
> >>> directories.
> >>>> This draft is a work item of the Network File System Version 4 WG of the
> >>> IETF.
> >>>> 
> >>>>       Title           : File Content Provenance for Network File System
> >>> version 4
> >>>>       Author          : Charles Lever
> >>>>      Filename        : draft-ietf-nfsv4-integrity-measurement-01.txt
> >>>>      Pages           : 9
> >>>>      Date            : 2018-09-24
> >>>> 
> >>>> Abstract:
> >>>>  This document specifies an OPTIONAL extension to NFS version 4 minor
> >>>>  version 2 that enables file provenance information to be conveyed
> >>>>  between NFS version 4.2 servers and clients.  File provenance
> >>>>  information authenticates the creator of a file's content and helps
> >>>>  guarantee the content's integrity from creation to use.
> >>>> 
> >>>> 
> >>>> The IETF datatracker status page for this draft is:
> >>>> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-integrity-measurement/
> >>>> 
> >>>> There are also htmlized versions available at:
> >>>> https://tools.ietf.org/html/draft-ietf-nfsv4-integrity-measurement-01
> >>>> 
> >>> https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-integrity-measurement-01
> >>>> 
> >>>> A diff from the previous version is available at:
> >>>> 
> >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-integrity-measurement-01
> >>>> 
> >>>> 
> >>>> Please note that it may take a couple of minutes from the time of
> >>> submission
> >>>> until the htmlized version and diff are available at tools.ietf.org.
> >>>> 
> >>>> Internet-Drafts are also available by anonymous FTP at:
> >>>> ftp://ftp.ietf.org/internet-drafts/
> >>> 
> >>> As a result of the discussion at IETF 102 and recent follow-ups
> >>> on this mailing list, I've made substantial changes to this
> >>> document.
> >>> 
> >>> - References to and discussion of Linux IMA have been replaced
> >>> throughout the document, with the exception of a single citation
> >>> as an informative example in the Introduction. IMA metadata is
> >>> now referred to generically using the term "file provenance
> >>> information".
> >>> 
> >>> - Integrity checking of file attributes is no longer an included
> >>> feature. There were some issues that made attribute integrity
> >>> not straightforward for NFS, especially without an existing
> >>> IMA/EVM standard even for local file systems. Attribute
> >>> integrity can still be addressed at a later time.
> >>> 
> >>> - The Introduction now makes a problem statement and discusses
> >>> use cases instead of explaining the mechanism of file integrity
> >>> checking. The new Introduction addresses the most common
> >>> questions I've received during previous review.
> >>> 
> >>> Spencer D. and other reviewers:
> >>> - Have previously stated interoperability concerns been addressed?
> >>> - Have normative citation requirements been sufficiently met?
> >>> 
> >> 
> >> Recognizing that I haven't done an AD Evaluation of this draft, but looking
> >> at the responses to my previous questions, I think dropping down to one
> >> explicit mention of IMA pointing to the best available reference is about
> >> right.
> > 
> >       "A keyed hash authenticates the identity of the last modifier of
> >       a file's content and serves as a strong check of the content's
> >       integrity.  For the purposes of this document, we will refer to
> >       this as file provenance information.  The Linux Integrity
> >       Measurement Architecture (IMA) is an example of a mechanism for
> >       assessing file content provenance [IMA-WP]."
> > 
> > I think it's also true that this draft is sufficient to allow a client
> > to support IMA?  That also seems worth mentioning.
> 
> I'm confused by your remark. I'm describing a transport
> protocol between a NFS client and server. Why would it
> not be sufficient to implement client support? Or, what
> do you believe might be missing in the draft?
> 
> 
> >       "To ensure interoperability among accessors of this information
> >       when it is stored on NFS version 4.2 servers, this information
> >       MUST be self- describing."
> > 
> > How do you propose that an implementation would make the information
> > self-describing?
> 
> That is out of scope for this draft.
> 
> But typically if an integrity service wanted to do this, it
> could use XML or JSON to describe the information, for example.
> 
> An HMAC has a particular structure (RFC 2104) that should be
> easy to recognize.
> 
> 
> > --b.
> > 
> >> 
> >> Thanks for making that change. It will be helpful during Last Call and IESG
> >> Evaluation.
> >> 
> >> Spencer (D)
> >> 
> >> 
> >>> 
> >>> I know time is precious, but even a cursory review of this new
> >>> revision would be helpful. It's wafer-thin!
> >>> 
> >>> --
> >>> Chuck Lever
> >>> 
> >>> 
> >>> 
> >>> 
> > 
> >> _______________________________________________
> >> nfsv4 mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/nfsv4
> 
> --
> Chuck Lever
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever