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

> On Nov 11, 2019, at 2:43 PM, David Noveck <[email protected]> wrote:
> 
> 
> 
> On Fri, Nov 8, 2019, 10:12 AM Chuck Lever <[email protected]> wrote:
> 
> 
>> > On Nov 7, 2019, at 6:13 PM, David Noveck <[email protected]> wrote:
>> > 
>> 
>> It appears that draft-ietf-nfsv4-integrity-measurement can't move
>> forward without some description of the IMA metadata format.
> 
> It is my understanding that you already plan to do that in -08.

That is what I proposed last week. Now I'm thinking the description
could be a separate document. Certainly a description could be
published separately by the IETF (eg., nfsv4, rats or teep) or it
could come from some other SSO (such as TCG).


>> My preference would be that the Linux community is responsible for
>> the process and document(s) that describe their own format.
> 
> That's very sensible but that doesn't mean it's going to happen.

As a card-carrying member of the Linux community, I can attempt to
get it done myself. Two issues:

 - Who will be responsible for maintaining the publication as new
Linux IMA formats are introduced. IMA is currently an active effort,
and I anticipate some integration with fs-verity will require a new
IMA metadata format.

- How long will it take to ensure the format is not encumbered by
patent or software license. I have contacts at the Linux Foundation
that I hope can help address this issue. I will also discuss this
with any copyright holders.


>> Failing
>> that, a description can be added to integrity-measurement, as I
>> recently proposed.
> 
> Understood.
> 
> 
>> To make an IANA registry a sensible thing to do, at least one more
>> independent integrity metadata format will have to be identified.
> 
> I think one has already been identified.  To make this scheme work, there will need to have a common metadata format implemented.
> 
> Once it is implemented, it will need to be specified, leaving you with following tasks:
> 	• Identifying a victim to provide it.
> 	• Figuring out when/where it will be provided.
> The virtue of the IANA registry is that it gives you the ability to defer these tasks.

Deferral would be nice, as that would enable integrity-measurement
to move forward sooner (assuming Spencer's objection is lifted).
But it might be unnecessary if I can get a document put together
and signed-off by others in the Linux community in the next few
months.

We did try an IANA registry before, and I'm willing to consider
that again to help move this along. The e-mail conversation a few
months ago rat-holed on whether or not there would be an actual
need for multiple metadata formats, as I recall. We can put aside
the question of over-engineering and decide simply that the document
will start with a registry containing one format discriminator.

There is also the question of whether the format discriminator field
not only marks the internal format, but also allows the storage and
retrieval of metadata stored in other xattrs (unlike the discriminator
for NFSv4 security labels, which applies only to one xattr).

IMA, for example, already uses two xattrs, security.ima and
security.evm, that can co-exist on the same file. It would be slick
to add support for security.evm simply by adding another entry into
the IANA registry.

Before I go too much further, however, I would like to hear from
Spencer if he believes these changes would adequately address his
concerns.


--
Chuck Lever



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