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

["Everhart, Craig" <[e-mail]>]

Hi Chuck.   Comments in-line.
		Craig

On 11/8/18, 10:44 AM, "Chuck Lever" <[e-mail]> wrote:
   
    Hi Craig-
    
    > On Nov 7, 2018, at 12:18 PM, Everhart, Craig <[e-mail]> wrote:
    >
    > Hi Chuck,
    >
    > Thanks for the update.
    >
    > At the end of the introduction (1), you add "Unlike traditional integrity management schemes, the hash is not replaced every time a file is copied.  Instead, the signed checksum is copied along with file content and presented whenever the content is about to be used."  You're alluding to a practice with which I'm not familiar, even when you're describing traditional schemes.  Copied for reading or for writing?  What would have replaced the hash every time the file is copied--a storage system?  (I want to understand this so that I can understand how the mechanism that you're proposing will replace and modify the existing mechanism.)
    
    The traditional scheme I'm thinking of is the mechanism that
    generates and writes a checksum during media block writes.
    When a file is copied, each newly allocated and written block
    gets a freshly generated checksum.
    
    This checksum is based on the data as presented to the storage
    media, so it cannot protect against unwanted changes due to
    software bugs or malicious acts during the file copy operation.

I thought that your "traditional" scheme was to refer to how "traditional provenance" schemes worked.  Referring to this internal, unexposed checksum inside a storage system as a "traditional integrity management" scheme seems to be a strained parallel.  Perhaps "Unlike an integrity management scheme based solely on file content as seen on the file storage device"?
    
    Unlike that scheme, FPI follows without change the file's data
    content. Or to put it another way, FPI is copied along with
    the file's content to its destination. 

By one of those special tools, again?  What copying mechanism will know about provenance?

    This means _any_ change
    to the content between the time it is generated and the time it
    is used can be detected.

And detected by only these special tools.
    
    
    > It sounds like a hash would have been replaced whenever a file was written, but this replacement copies the hash along with file content--presumably by some client-side tool?
    
    Yes, when file content is updated, the FPI has to be refreshed.
    This would be done using a tool, run on a client or on the
    server, that is capable of re-signing the hash.
    
    In it's simplest form, using FPI means that protected files
    become effectively immutable. That's exactly what we want for
    things like executables, which change infrequently.
    
    
    > Down in 1.1, you likely want to add "only" immediately before the function that it most closely modifies; "NFS acts as only a conduit ..."  rather than "NFS acts only as a conduit...".  (e.g.: I'd hope that NFS acts as more than a conduit!)
    >
    > In 4.2, can there be multiple FATTR4_FILE_PROVENANCE objects with different fpv_type values?
    
    Right now my opinion is that should be allowed.

The down-side is that they'd need to be enumerated, if such a system were to be backed up, for example.
    
    > How do I enumerate them?
    
    There isn't an explicit mechanism to do that because I don't
    believe that's going to be needed. The client will ask the
    server for the particular fpv_values that the client supports.

Right, as long as it's only the special tools that do the reading.
    
    
    > Clearly your description of the treatment of distinct fpv_type values would suggest that there would be multiple instances.  Are there other FATTR4_xxx attributes with multiple values?
    
    Security Labels, but only one label can be stored at a time.

And I'd suggest that the one-at-a-time semantics is important if there's no way of doing enumeration.
    
    
    > It's a little odd that fpv_type is not in the fattr4 namespace, but that it represents a sub-type.  How do I specify a fpv_type to GETATTR?
    
    struct file_prov4 {
            uint32_t                 fpv_type;
            opaque                   fpv_data<>;
    };

That's in the GETATTR reply, right--how the NFS server indicates an attribute to the NFS client.  How does an NFS client specify to the GETATTR sent from client to server that it is interested in a specific value of fpv_type and not others?  (Per my reading, GETATTR accepts only the current file handle as a parameter.)  In the security-label regime, as you say, you ask for the security attribute and get back the (only) one that is stored.  Apparently you envision a file system in which many types can be stored simultaneously.  As an NFS client, how do I indicate the fpv_type value of interest to the NFS server?
    
    I just copied the security label attribute. I'll have to go back
    and look at how that works and copy that language to Section 4.3.

I suspect that it works because there's only one kind of security label.
    
    > Again, how do I enumerate all the stored fpv_type values?
    > (It might be easier if there were only one possible FATTR4_FILE_PROVENANCE attribute, so that storing any fpv_type value would replace any other FATTR4_FILE_PROVENANCE attribute.
    
    Easier how?

Principally because you wouldn't have me asking how the existing stored fpv_type values are to be enumerated.
    
    > Alternatively, you could allow for FATTR4_FILE_PROVENANCE_xxx values, in which the "xxx" extension semantically replaces your suggested fpv_type value.)
    
    That means we'd have to extend NFSv4.2 every time we add a new
    fpv_value. If we use a subtype and an IANA registry, it becomes
    simple to add a new value -- it does not require any change to
    the NFSv4 protocol.
   
I agree.  It's a flaky idea, but it has the advantage of not requiring a new type enumeration.