Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-01.txt

Chuck Lever <chuck.lever@oracle.com> Thu, 27 September 2018 18:10 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 88EC6130EF7 for <nfsv4@ietfa.amsl.com>; Thu, 27 Sep 2018 11:10:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 yZTo5SOTk9Vb for <nfsv4@ietfa.amsl.com>; Thu, 27 Sep 2018 11:10:43 -0700 (PDT)
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 9FDD8130EF3 for <nfsv4@ietf.org>; Thu, 27 Sep 2018 11:10:43 -0700 (PDT)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w8RHx9bu146932; Thu, 27 Sep 2018 18:10:41 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-2018-07-02; bh=ygZAD/GdyoN7oqMhh9eiPefjqMUqLa8q7nPOWxzUTaM=; b=EaWCfz/Dx12hob2MBBQEso4NOV5EW41860DXRjFO8hRy/Npp4qlKB327sI/cRyk0z4mN uLWb4gTHToS/XSzCWE4MT/4wzlrqys9XKXGLhJbpFk3OIulsE0rJzbxAn7gbNbRJvEPp t3wWU4F14O1EQVC+nzvBfY/sjOAeMo551Mq0DS2bTr8lYY7g+CjICo8eyPUiaGuuOWgr 08jUW8B9qZmIqo56DmfLsW+42wJLJt7SbH7AlbwNxMBWpaGtGSFiWjNGPw91lmSMOrZJ 5f0+AnLN3q87xghmVfHM9LL6aUZkpy8gWeJAXf1NJAvQF6Dta2y5DBt1QI89q8zE4pXN 9Q==
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2mnvtv2hk0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Sep 2018 18:10:41 +0000
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w8RIAeA6013961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Sep 2018 18:10:40 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w8RIAel3004441; Thu, 27 Sep 2018 18:10:40 GMT
Received: from [10.71.9.255] (/8.25.222.2) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Sep 2018 11:10:40 -0700
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <E232912D-984D-441F-9B1E-59B6C6B367F9@netapp.com>
Date: Thu, 27 Sep 2018 11:10:39 -0700
Cc: Bruce Fields <bfields@fieldses.org>, NFSv4 <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F7774906-07F9-4ADF-AB8C-2B1D32AD3223@oracle.com>
References: <153780090601.28221.16958675117475194416@ietfa.amsl.com> <CADE569F-8584-42CF-A297-E60956D368A2@oracle.com> <CAKKJt-fmB5psmtbm9PJTnhkZkZLCBnCVZnr3fMsf++exN5XObQ@mail.gmail.com> <20180926202157.GA826@fieldses.org> <1F2E60B5-E09F-4B33-8301-99C5E5A0F310@oracle.com> <20180927011257.GC2715@fieldses.org> <8461C2B0-41B3-4983-86F3-78DC4B36D077@oracle.com> <E960590D-7284-4C08-83F2-C066F4713244@netapp.com> <B15A1832-FAB9-4A0B-AF4E-F2EB1D424C57@oracle.com> <E232912D-984D-441F-9B1E-59B6C6B367F9@netapp.com>
To: "Everhart, Craig" <Craig.Everhart@netapp.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9029 signatures=668707
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-1807170000 definitions=main-1809270167
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/WafY739ljckbngu6QW3dz-PGWJM>
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-01.txt
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: Thu, 27 Sep 2018 18:10:46 -0000

Hi Craig-

> On Sep 27, 2018, at 9:59 AM, Everhart, Craig <Craig.Everhart@netapp.com> wrote:
> 
> Just to say: when there was the "8-bit-transparent" scheme around, it LOST to the UTF encoding.  Without knowing what the local character scheme was, it made no sense to claim interoperability with some other unspecified character encoding scheme.
> 
> The analogy here is that you're either trying to reserve an "8-bit-clean" repository of opaque data, where a server doesn't know what it's storing and a separate client has no idea what it's seeing, or you're trying to reserve a particular slot for the sole use of some format that you don't describe.  In that second case, the analogy with file name data isn't so clear: NFS is built around having exactly one (component) file name, without a label explaining how to interpret that file name label.
> 
> But you're effectively asking for private use of the "file provenance" name space.  I hope there's never another community that also comes up with a "file provenance" description scheme.

We've already taken this route this with NFS security labels. There is
exactly one xattr that can store only _one_ of a MAC label, or SMACK,
or ...

Both cases you describe above are serviceable via the mechanism
I proposed. If there ever is a collision, then the assessment
applications involved can use an XML wrapper to label and store
both types of FPI in the same slot, or they can approach the WG
and request another fattr4 attribute.

Alternatively, an implementation may choose to have a security.ima
xattr for local consumers, and a separate xattr that stores FPI
consumed by remote users.


> 		Craig
> 
> 
> 
> On 9/27/18, 12:24 PM, "Chuck Lever" <chuck.lever@oracle.com> wrote:
> 
>> On Sep 27, 2018, at 9:09 AM, Everhart, Craig <Craig.Everhart@netapp.com> wrote:
>> 
>> This exact issue needs to be discussed in the draft--whether it makes sense for clients/servers that don't a-priori recognize the "file provenance" information to reject the communication, and how.  Should non-recognizing servers store the information blind?  Or should they reject such files?
> 
>    Good point. I can add language that fills that in. In fact
>    that will be a copy-and-paste from an earlier version of
>    this document.
> 
> 
>> Essentially, the draft seems to imply that there's a well-understood way that some community of file handlers has of describing file provenance.  Instead of explaining what that is, the author(s) of the draft simply want to standardize a way of describing data that is otherwise opaque.  The draft gives no information on how to construct an appropriate file-provenance blob of bits, to my reading, or to explain what a formatted blob of bits would mean.
>> 
>> Let's say that there are multiple communities that all are composed of people that understand some formatting scheme.  How should they interact?  How would I (a file server) take a blob from community A and present it in a way that community B would understand?  Or is this formatting scheme to remain opaque forever?
>> 
>> We had an analogous tussle many years ago with the "8-bit-transparent" file name stuff.  One community wanted NFS to simply save file names in their full 8-bit form, without interpretation.  That's fine as long as everybody who sees a given name knows how to interpret it.  (This was in the days before UTF-8 or its analogues; we had a lot of localized character sets that people wanted to use verbatim.)  Thank heavens that we no longer have that particular fight.  But this draft feels analogous: it apparently wants NFS to store and retrieve "provenance" blobs without altering them, saying that they have meaningful semantics, but without explaining what those semantics are.
> 
>    Yes, that's what we want to do. This is exactly the same
>    as storing opaque file data. NFS is conveying and storing
>    data on behalf of an application which is responsible for
>    interpreting that data.
> 
> 
>>              Craig Everhart
>> 
>> 
>> 
>> On 9/27/18, 11:32 AM, "nfsv4 on behalf of Chuck Lever" <nfsv4-bounces@ietf.org on behalf of chuck.lever@oracle.com> wrote:
>> 
>>   The consequences of not recognizing the file provenance information
>>   are not dire. In those cases, clients simply don't allow access to
>>   the file's content, and the implementations are free to report to
>>   the administrator that the FPI format is not recognized.
>> 
>>   Would it help to state that in the draft?
>> 
> 
>    --
>    Chuck Lever
> 
> 
> 
> 
> 

--
Chuck Lever