Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-06.txt

From: [email-masked]
Date: Sun, 22 Sep 2019 16:11:07 -0700

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           : Integrity Measurement for Network File System version 4
        Author          : Charles Lever
	Filename        : draft-ietf-nfsv4-integrity-measurement-06.txt
	Pages           : 18
	Date            : 2019-09-22

Abstract:
   This document specifies an OPTIONAL extension to NFS version 4 minor
   version 2 that enables Linux Integrity Measurement Architecture
   metadata (IMA) to be conveyed between NFS version 4.2 servers and
   clients.  Integrity measurement authenticates the creator of a file's
   content and helps guarantee the content's integrity end-to-end 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-06
https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-integrity-measurement-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-integrity-measurement-06

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/

---

From: Chuck Lever <[email-masked]>
Date: Sun, 22 Sep 2019 16:15:41 -0700

> On Sep 22, 2019, at 4:11 PM, [email-masked] wrote:
> 
> 

Fresh revision incorporates comments from IETF 105 and Linux
Security Summit North America 2019.

It's probably ready for (it's first) WGLC. :-) It's OK if the
chair prefers to wait until we have more fully dealt with
outstanding RFC 5661 errata.

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Mon, 23 Sep 2019 11:23:21 -0400

> It's probably ready for (it's first) WGLC. :-)

I feel that the basic issue with section 4.3.2 has not been
satisfactorily resolved.    I'll send out a mail with the details
in the next few days.

On Sun, Sep 22, 2019 at 7:15 PM Chuck Lever <[email-masked]> wrote:

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

---

From: Chuck Lever <[email-masked]>
Date: Mon, 23 Sep 2019 09:28:50 -0700

Context: The guidance in that section falls into the realm of "compromise between the Linux community and the specification writer".

> On Sep 23, 2019, at 8:23 AM, David Noveck <[email-masked]> wrote:
> 

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Mon, 23 Sep 2019 13:19:24 -0400

> The guidance in that section falls into the realm of "compromise between
the Linux community and the > specification writer"

I gaathered that, but it should not be assumed that the woring group is
prepared for the same level of compromise, even though it should strive to
be as helpfu as it can.   Also, it appears that the Linux community cannot
make its own mind about how to address this issue so perhaps some
intra-community compromise is in order.  If that isn't forthcoming, our
only option might to approve this as an experimental/informational  RFC and
upgrade it when the Linux community gets its act together.

On Mon, Sep 23, 2019 at 12:28 PM Chuck Lever <[email-masked]> wrote:

> Context: The guidance in that section falls into the realm of "compromise
> between the Linux community and the specification writer".
>
>

---

From: Chuck Lever <[email-masked]>
Date: Mon, 23 Sep 2019 10:48:19 -0700

> On Sep 23, 2019, at 10:19 AM, David Noveck <[email-masked]> wrote:
> 
> > The guidance in that section falls into the realm of "compromise between the Linux community and the > specification writer"  
> 
> I gaathered that, but it should not be assumed that the woring group is prepared for the same level of compromise,

Help me understand exactly why the current section is lacking. I don't see
why the exact authorization mechanism must be specified in this document,
since:

a. it doesn't matter for interoperability
b. the mechanism used for updating IMA metadata on
   local files on Linux (the CAP_SYS_ADMIN capability)
   does not exist in NFS; moreover capabilities are
   not defined in a standard
c. authorization is done by policy in other arenas
   (for example, the IP-based access control that is
   implemented by most current NFS servers), thus it
   should be sufficient here too

> even though it should strive to be as helpfu as it can.   Also, it appears that the Linux community cannot make its own mind about how to address this issue so perhaps some intra-community compromise is in order.

See above. It's really not a simple matter of the community shrugging and
punting.

> If that isn't forthcoming, our only option might to approve this as an experimental/informational  RFC and upgrade it when the Linux community gets its act together.

That's a bit unfair. See above: there is a complete mismatch between how
it works on local file systems and what mechanisms are available with NFS.
IMO we are in a position to enable both "close enough" server implementations
and for server implementers to exercise some innovation.

Anticipating the IESG's reaction to this text is probably not going to be
possible or helpful. I'd rather hear their complaints from them. Let's focus
on the WG's concerns first.

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Mon, 23 Sep 2019 14:22:22 -0400

> Help me understand exactly why the current section is lacking.

i promised to send you a review and i will.

> I don't see why the exact authorization mechanism must be specified in
this document,

I'm not saying i need the ezact authentication mechanism, but the current
document
is light-years or megaparsecs) away from that.  this may not be the
intention but right
now the document essentially gives the server to accept or jects request
without constraint.

> a. it doesn't matter for interoperability

It does.   To be interoperable you have to interoperate, i.e issue a valid
request and
have the required operation performed.   That ability is compromised if the
server can reject it for any reason it chooses.

I don't understand the relevance of that.

Yes it exists and a document you are writing explains what is
wrong with that.   i don't want us to create a similar mess here
if we can avoid it.    In summary, it is clearly not sufficient
there, although it unfortunately exists.

> even though it should strive to be as helpfu as it can.   Also, it
appears that the Linux community cannot make its own mind about how to
address this issue so perhaps some intra-community compromise is in order.

punting.

I'm not sure what it is but i note there are at least four different
approahes specified in the document and that somenody would have to
compromise to reduce that number.

> If that isn't forthcoming, our only option might to approve this as an
experimental/informational  RFC and upgrade it when the Linux community
gets its act together.

> and for server implementers to exercise some innovation.

Maybe we are, but I don't see much effort in that direction in the current
document.

> possible or helpful. I'd rather hear their complaints from them.

Agrre.  If this gets through WGLC and IETF last call, then you can hear
their
complaints first-hand.

>Let's focus

As I said, I'll be sending my review comments pretty soon.

On Mon, Sep 23, 2019 at 1:48 PM Chuck Lever <[email-masked]> wrote:

> > > The guidance in that section falls into the realm of "compromise
> between the Linux community and the > specification writer"
> >
> prepared for the same level of compromise,
>
> > even though it should strive to be as helpfu as it can.   Also, it
> appears that the Linux community cannot make its own mind about how to
> address this issue so perhaps some intra-community compromise is in order.
>
> > If that isn't forthcoming, our only option might to approve this as an
> experimental/informational  RFC and upgrade it when the Linux community
> gets its act together.
>
> > Context: The guidance in that section falls into the realm of
> "compromise between the Linux community and the specification writer".
> >
> >