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
- [nfsv4] Comments on draft-ietf-nfsv4-integrity-me… spencer shepler
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… David Noveck
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Craig Everhart
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… spencer shepler
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… spencer shepler
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… David Noveck
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… David Noveck
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… spencer shepler
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Benjamin Kaduk
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… spencer shepler
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… David Noveck
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Benjamin Kaduk
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… David Noveck
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… David Noveck
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever