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

Chuck Lever <chuck.lever@oracle.com> Mon, 12 November 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 309B8130E65 for <nfsv4@ietfa.amsl.com>; Mon, 12 Nov 2018 10:10:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.77
X-Spam-Level:
X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 ZVkqgm0gRWlC for <nfsv4@ietfa.amsl.com>; Mon, 12 Nov 2018 10:10:13 -0800 (PST)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 BB9CD126CC7 for <nfsv4@ietf.org>; Mon, 12 Nov 2018 10:10:13 -0800 (PST)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wACI3sBY145580; Mon, 12 Nov 2018 18:10:12 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=TjHM0u1Vd1QDzzq6BnJnFYF/Ix9W4PfKU9nWNboR5as=; b=DamzoFsRUvynnTNtA/i344ae808gyHoOSRUnhydWVvC5CIuWevdRJhFDCvDd63xzm1YY x499CvHvlqXldiSQ2NMmlT4WSOQGS8KUBgPG4Pp36XIQNBz5/7TZAmUX5meIOxZQO7tr 8fwYCJdOlseiZbHPhYG1oJ1yY0GIavWg4Fj/XJP+lqq9hNKvc73JNzAiV8Qh0DxjY5lc OACrw0axrkCy6iDcgsyx1eytdwZuvTjHcE44TPdxx/8SSYBATe1YSrrYWxWQYi5fRKYp 9M2RI/Ga1ycP3ptGFmio+C0/QEUtFvZkm7ozU/gy1t5NbfiRIHcu/tyOQq+NigwuhLW6 9w==
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2nnwg16kph-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 12 Nov 2018 18:10:12 +0000
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wACIABMn027004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 12 Nov 2018 18:10:12 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wACIABTL018180; Mon, 12 Nov 2018 18:10:11 GMT
Received: from [192.168.32.39] (/64.114.255.114) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Nov 2018 10:10:11 -0800
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: <20181112063937.GB99562@kduck.kaduk.org>
Date: Mon, 12 Nov 2018 10:10:09 -0800
Cc: NFSv4 <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A280D7E7-9D6F-4984-B588-022ADF5A0D0A@oracle.com>
References: <154160412218.26446.11676556173331817093@ietfa.amsl.com> <74E10D08-6181-49C8-B994-6554C72C4B7D@oracle.com> <BBC9F2E1-4E81-4FE4-99D0-A0B23F33AAD4@netapp.com> <D1E8642B-9A07-4812-82E0-982EDC6EF73E@oracle.com> <578769FE-6C12-4003-A579-7FB461D99A8A@netapp.com> <32BFC3DE-BF20-4A3B-88AC-FAF2C19F714D@oracle.com> <CCC8A8EA-7D8D-440F-B29C-1D3577FC104D@netapp.com> <CDC6A311-4076-405B-AE4C-26A0BC8CE685@oracle.com> <20181110113100.GW65098@kduck.kaduk.org> <B37DE303-A1B8-4817-B814-D9B7F8EDB954@oracle.com> <20181112063937.GB99562@kduck.kaduk.org>
To: Benjamin Kaduk <kaduk@MIT.EDU>
X-Mailer: Apple Mail (2.3445.9.1)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9075 signatures=668683
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-1811120159
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/pdrVAl5XcmFL9P2MeItVFIh2I8I>
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-03.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: Mon, 12 Nov 2018 18:10:16 -0000


> On Nov 11, 2018, at 10:39 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
> 
> On Sat, Nov 10, 2018 at 11:54:49AM -0500, Chuck Lever wrote:
>> 
>> 
>>> On Nov 10, 2018, at 6:31 AM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>>> 
>>> On Thu, Nov 08, 2018 at 01:23:24PM -0500, Chuck Lever wrote:
>>>> 
>>>> 
>>>>> On Nov 8, 2018, at 12:03 PM, Everhart, Craig <Craig.Everhart@netapp.com> wrote:
>>>>> 
>>>>> Hi Chuck, just one point.
>>>>> 
>>>>> On 11/8/18, 11:54 AM, "Chuck Lever" <chuck.lever@oracle.com> wrote:
>>>>> 
>>>>>> This means _any_ change
>>>>>> to the content between the time it is generated and the time it
>>>>>> is used can be detected.
>>>>>> 
>>>>>> And detected by only these special tools.
>>>>> 
>>>>>  No, the FPI is evaluated by the provenance assessor before each
>>>>>  access of the file.
>>>>> 
>>>>> Perhaps you could clarify this architecture.  The menagerie of tools that would be modified, this provenance assessor--what is the architecture of the system in which these tools exist?  Is the "provenance assessor" part of the presumed OS on the NFS client?
>>>> 
>>>> We're going in circles now. I've explained this before in e-mail
>>>> and in the document.
>>>> 
>>>> 
>>>>> Is it active when I read a file with the menagerie (e.g., "cp")?
>>>> 
>>>> Depending on policy, it can be.
>>>> 
>>>> 
>>>>> At backup time?
>>>> 
>>>> Depending on policy, it can be.
>>>> 
>>>> The primary point of FPI is to prevent the use of corrupted file
>>>> contents. Copying or backing up file content is not necessarily
>>>> considered "use", but an administrator might be paranoid or want
>>>> some notification if tampering has occurred long before a file
>>>> is used. It's also possible that a tool can be constructed to
>>>> scrub a file system to pre-emptively identify corrupted content.
>>>> 
>>>> Again, this document is not meant to be a full specification of
>>>> IMA and how it's used. A discussion of tooling is out of scope,
>>>> IMO.
>>>> 
>>> 
>>> I am not going to say that a discussion of tools needs to be in the
>>> document, but I think it's okay to have  some discussion on the list to get
>>> people onboard with the idea that one can use this to build a useful
>>> system.
>> 
>> There already is a Linux implementation of IMA for local file
>> systems. Part of this effort will be prototyping the protocol
>> elements described in this document, and then assessing whether
>> they can be a successful part of the existing Linux IMA eco-
>> system (ie, do we end up with a useful system when NFS is
>> included?).
>> 
>> So I agree that such evaluation is necessary, but I feel like
>> it will come a little later when there is real code to try out.
>> I don't intend to push this document through publication without
>> prototyping and assessment.
> 
> It sounds like we're on the same page, then, great.

I think so. The big picture questions I'm taking away are:

- Will this be a feasible and valuable addition to IMA?
- How will interoperability issues be resolved?
- Resolution of details about language required in the spec


> (Though I do agree with Craig that I'm not sure what would prevent
> prototyping even now.)

I intended to start prototyping a few months ago, but the
discussion on this mailing list has continued to prompt
modifications of the original protocol elements that I
proposed in -00.


>>> (There is precedent for wanting confidence that a useful system
>>> can be built, viz. my DISCUSS ballot position on
>>> draft-ietf-lisp-rfc6830bis.  The situation here seems much simpler than
>>> that one is, though.)
>> 
>> Fair enough, it wasn't clear to me whether Craig was asking for
>> an informal discussion here on the list or for something to be
>> introduced into the document. To clarify what I wrote above, I
>> believe that a detailed discussion of tooling is out of scope
>> for the document.
>> 
>> Even so, the second paragraph of Section 1.1 reads:
>> 
>>   File provenance information is generated and signed by a "provenance
>>   authority", and then associated with each file using special tools.
>> 
>> Does more need to be said here and/or in Section 5.2 ?
> 
> Nothing it sticking out at me at the moment as missing, though I only
> skimmed.  It may be worth considering phrasing involving "out of band", as
> that term is frequently used in IETF documents.
> 
> -Ben
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever