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

Benjamin Kaduk <kaduk@mit.edu> Mon, 11 November 2019 18:11 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F402C1208C4 for <nfsv4@ietfa.amsl.com>; Mon, 11 Nov 2019 10:11:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQmLgvlqP9gv for <nfsv4@ietfa.amsl.com>; Mon, 11 Nov 2019 10:11:20 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7A94120924 for <nfsv4@ietf.org>; Mon, 11 Nov 2019 10:11:19 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xABIBElv019341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Nov 2019 13:11:16 -0500
Date: Mon, 11 Nov 2019 10:11:13 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: David Noveck <davenoveck@gmail.com>, NFSv4 <nfsv4@ietf.org>
Message-ID: <20191111181113.GB32847@kduck.mit.edu>
References: <CADaq8jc_gM0SWe9weRJYp7s7xjtN9kihbVnUiBN61hF2LUJjzQ@mail.gmail.com> <FD12C92F-BBF4-4174-B896-48738C02B78E@oracle.com> <CAFt6BanwC4uu=9SpZQdiGjFswzkC3cSWPzGia34qBT5W+uuMNw@mail.gmail.com> <5B51BB44-F39D-4EF6-9E1E-3EF958F90260@oracle.com> <20191031192409.GJ88302@kduck.mit.edu> <67D69A00-D231-4845-A840-F3D67D629554@oracle.com> <CAFt6BanShDjwD3SftuDUvChFq9zOU5h1UC2y=W+3bVm++jAEKA@mail.gmail.com> <479C7409-9DCF-4C11-84AB-2E3729D96B22@oracle.com> <CADaq8jfMXjewirgvyCgh3D+yXQSNEX3HbWMCnz=XYCKk5T=6iA@mail.gmail.com> <00F112E6-F869-4624-A68E-9C909AB3B653@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <00F112E6-F869-4624-A68E-9C909AB3B653@oracle.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/EAKO70GW4OFJMTPt4SGlvcSzsIo>
Subject: Re: [nfsv4] Comments on draft-ietf-nfsv4-integrity-measurement-07
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Nov 2019 18:11:24 -0000

On Fri, Nov 08, 2019 at 10:12:02AM -0500, Chuck Lever wrote:
> 
> 
> > On Nov 7, 2019, at 6:13 PM, David Noveck <davenoveck@gmail.com> wrote:
> > 
> > > Why isn't the SELinux label work a problem in this regard?  
> > 
> > I don't understand Spencer's position well  enough to know if he has
> > a problem with this, but given that this model has already been adopted
> > by the working group for arguably system-level attributes, it is hard for
> > me to believe such objections, if they were to exist, would be widely 
> > shared.  
> > 
> > Since adopting a parallel approach for the IMA metadata 
> > format is compatible with your plans for -08, perhaps you should 
> > adopt a similar approach (an IANA registry with a specification-required 
> > policy) for IMA.   I know that such things have been suggested in the past 
> > and seemed at the time like overkill, but, given that there are a number 
> > of existing formats, and likely there will be a more general format which 
> > has not been arrived at  right now, it might be best to take this step,
> > hoping that it will deal with the objections about the lack of a metadata 
> > format specification even though the Linux community is kind of slow
> > about producing  one.  I think you ould have to add a new fs-scope
> > attribute with the id, rather than stick with the local-policy approach,
> > but there would b no requirement tat the client check this.
> > 
> > BTW, specification-required and even RFC-required do not require a
> > normative specification.   With specification-required, the IETF does 
> > not have to be involved in writing the spec although a designated-expert 
> > would have to check that it clear enough to enable implementation.
> 
> It appears that draft-ietf-nfsv4-integrity-measurement can't move
> forward without some description of the IMA metadata format.

My name is not Magnus, but I'm not fully convinced of that yet.

> My preference would be that the Linux community is responsible for
> the process and document(s) that describe their own format. Failing
> that, a description can be added to integrity-measurement, as I
> recently proposed.
> 
> To make an IANA registry a sensible thing to do, at least one more
> independent integrity metadata format will have to be identified.

I'm sure I can find many examples of IANA registries that are created with
only one substantive initial entry; why would this one be any different?
The point is to have a clear extension point, not (necessarily) to require
someone to use it from the start.  (Though, perhaps, see also
draft-ietf-tls-grease...)

-Ben