Subject: Re: [nfsv4] Review of draft-ietf-nfsv4-integrity-measurment-01

From: David Noveck <[email-masked]>
Date: Mon, 1 Oct 2018 05:41:47 -0400

> "Agreement on the interpretation of the contents of this opaque blob is
out
> of scope for this specification" is always hard to feel good about
writing,
> though the IETF has done it in the past and will do it again.

As I reader, what I care about in this situation is an indication of where
the description
of the contents is to be found, and in this case Chuck has provided that.

> FWIW, RFC 2104 is listed on https://datatracker.ietf.org/doc/downref/ so
> there would be no issue with having a normative dependency from a
> standards-track document.

This brought me to RFC 3967 (BCP 97), which is very interesting.  Thanks.

BTW, the Security Considerations section of that document is priceless.

On Sun, Sep 30, 2018 at 11:28 PM Benjamin Kaduk <[email-masked]> wrote:

> On Sun, Sep 30, 2018 at 12:21:12PM -0400, Chuck Lever wrote:
> >
> >
> > > On Sep 28, 2018, at 8:58 PM, David Noveck <[email-masked]>
> wrote:
> > >
> > > > > The things that we are waiting for are:
> > > > >       • A definition of the fornat of the provenance information.
> > >
> > > > I don't expect the draft to ever provide a format for the provenance
> > > > information.
> > >
> > > I now understand that, but that doesn't mean that people are not
> waiting
> > > for it.  Without  a definition of the format somwhere, implementations
> > > cannot be written and if implementations cannot be written, there is
> no
> > > point in doing this.
> > >
> > > > This information is _opaque_ to NFS,
> > >
> > > As I understand it, it is opaque to the server, but for there to a be
> client implementations
> > > there needs to be code written to create the provenance information
> and verify it and
> > > that ccode cannot be written without the format being known.
> >
> > It is opaque to the NFS client implementation as well. There is
> > a security module on each system where FPI is used that reads
> > the FPI and determines whether to prevent access to the file's
> > content. It is entirely independent of the file system in which
> > the FPI and file content is stored.
>
> "Agreement on the interpretation of the contents of this opaque blob is out
> of scope for this specification" is always hard to feel good about writing,
> though the IETF has done it in the past and will do it again.
>
> >
> > > > and at least in IMA's case,
> > >
> > > As I understand things the chances of there being any other case is
> quite low, and I
> > > believe that that is your feeling as well.
> >
> > > > there is no published normative specification that defines it.
> > >
> > > Perhaps not, but one would hope that there is definition of the format
> somewhere.   If there isn't, how
> > > could implementations be developed and interoperate?
> > >
> > > > There is no practical way to specify the format in this document.
> > >
> > > What makes it impractical?
> >
> > IMA has no specification. It has a web site and a white paper and
> > an implementation in Linux. I cite the web site as an Informative
> > reference and use IMA as an example. As far as I can tell, that's
> > the best that can be done.
> >
> > The IMA web site and white paper state that IMA uses an HMAC.
> > HMAC is defined by RFC 2104, but that's an Informative document.
> > I cite that RFC as an Informative reference as well.
>
> FWIW, RFC 2104 is listed on https://datatracker.ietf.org/doc/downref/ so
> there would be no issue with having a normative dependency from a
> standards-track document.  (Not that this really helps for the case of IMA,
> of course.)
>
> -Ben
>

---

From: [email-masked] (J. Bruce Fields)
Date: Mon, 1 Oct 2018 10:47:52 -0400

On Sun, Sep 30, 2018 at 12:21:12PM -0400, Chuck Lever wrote:
> IMA has no specification.

We can write one if we have to, right?

It's implemented in open source code, and already in use.  So it should
be stable, and IP issues seem unlikely.

But maybe I'm OK with it being left out of this draft.  There seems to
be a clean separation between this layer for transporting the
information.  I don't know.

--b.

---

From: Chuck Lever <[email-masked]>
Date: Mon, 1 Oct 2018 11:12:59 -0400

> On Oct 1, 2018, at 10:47 AM, [email-masked] wrote:
> 

A clean layer separation is what I feel saves us here. This feeling will
be confirmed or dashed to the rocks when it is prototyped.

--
Chuck Lever