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

Chuck Lever <chuck.lever@oracle.com> Fri, 08 November 2019 15:12 UTC

Return-Path: <chuck.lever@oracle.com>
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 7CD211200F8 for <nfsv4@ietfa.amsl.com>; Fri, 8 Nov 2019 07:12:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
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 Xtp9CmFHV6zi for <nfsv4@ietfa.amsl.com>; Fri, 8 Nov 2019 07:12:08 -0800 (PST)
Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 3446812006F for <nfsv4@ietf.org>; Fri, 8 Nov 2019 07:12:08 -0800 (PST)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xA8EriLb042613; Fri, 8 Nov 2019 15:12:06 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2019-08-05; bh=C5dpqwyXWPpuwPG4pGMpga7UjSbqx5Yv3nUUFRChLn4=; b=fkuOYzmWyPzisa+BuSXAIsbEwhQ8cVrgUVu8edeMOblhXHf4srhVo1LxcHYHUy0LMpdI 7gE9O/ZcCKNQS1Xr39RmGHE28+wP/saD5kbaWh8pEveJbeYNq4wlHveIE3ZKJJiSJet6 owS05glFAsdTjkKP24KnNN3S4BdcxKycDHtCWC4oluFzQC6yNnp8NL2JougUbxM/OD5h XeKC8dSlP8NI4J8HhqMRGZdkiiIxUMMXm0STraghWlJWUHHyshLJOPRKmLt5sdCYsxUE X7TI5uGwB2Ac/Rmeg/Auzb7QTEdRXoYLVySTDI0zN/HCdgnS8fqwSCsNsPJtcx0abnUD qA==
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2w41w15vdb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 08 Nov 2019 15:12:06 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xA8Es2N6096409; Fri, 8 Nov 2019 15:12:05 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 2w41wj1hk5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 08 Nov 2019 15:12:04 +0000
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xA8FC4RA008613; Fri, 8 Nov 2019 15:12:04 GMT
Received: from anon-dhcp-152.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Nov 2019 07:12:04 -0800
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <CADaq8jfMXjewirgvyCgh3D+yXQSNEX3HbWMCnz=XYCKk5T=6iA@mail.gmail.com>
Date: Fri, 08 Nov 2019 10:12:02 -0500
Cc: spencer shepler <spencer.shepler@gmail.com>, NFSv4 <nfsv4@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <00F112E6-F869-4624-A68E-9C909AB3B653@oracle.com>
References: <CAFt6BakApq=FJWs+r-jwxvTdXYs9yOg9KS47no93kdnp2gZ_+Q@mail.gmail.com> <9BEBDE7A-522A-4A6B-8132-D9C3A8A4922C@oracle.com> <CAFt6Ba=q=vSt+wtcHsi59gWnwFpuUaDqQue7f=GFSUvd25uV+g@mail.gmail.com> <BFDF314F-B913-4C4A-BAB4-C09FA840F4F6@oracle.com> <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>
To: David Noveck <davenoveck@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9434 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911080150
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9434 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911080150
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/1zl9muHz3KjJQCWdwZBI887MM24>
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: Fri, 08 Nov 2019 15:12:10 -0000


> 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 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 will see what can be done.

--
Chuck Lever