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

Benjamin Kaduk <kaduk@mit.edu> Mon, 12 November 2018 06:39 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 B220E12D4EB for <nfsv4@ietfa.amsl.com>; Sun, 11 Nov 2018 22:39:52 -0800 (PST)
X-Quarantine-ID: <M7BaCy2-7a46>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 M7BaCy2-7a46 for <nfsv4@ietfa.amsl.com>; Sun, 11 Nov 2018 22:39:51 -0800 (PST)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 AD1B4128CF3 for <nfsv4@ietf.org>; Sun, 11 Nov 2018 22:39:50 -0800 (PST)
X-AuditID: 12074422-c4dff70000000ff0-9f-5be920328c13
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id C9.D1.04080.33029EB5; Mon, 12 Nov 2018 01:39:48 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.14.7/8.9.2) with ESMTP id wAC6dg1w014845; Mon, 12 Nov 2018 01:39:44 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) �by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wAC6dc1I028045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Nov 2018 01:39:40 -0500
Date: Mon, 12 Nov 2018 00:39:37 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: "Everhart, Craig" <Craig.Everhart@netapp.com>, NFSv4 <nfsv4@ietf.org>
Message-ID: <20181112063937.GB99562@kduck.kaduk.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <B37DE303-A1B8-4817-B814-D9B7F8EDB954@oracle.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT0TVReBlt8PmuksX/u8+ZLE6cns5k Mfv9I1YHZo8lS34yecz49IXN4+PTWywBzFFcNimpOZllqUX6dglcGdP6HjAVnJWrWPbyGGsD 403xLkZODgkBE4l9ZzuZuhi5OIQE1jBJ7FpwkwXC2cgocXvaG6jMXSaJqw3HmUFaWARUJVr2 72QHsdkEVCQaui+DxUUENCR2T98BZjMLeErsPdHKBGILC/hJXNn2hrWLkYODF2jdvzmWEDP7 WSRWLrjICFLDKyAocXLmExaIXnWJP/MuMYPUMwtISyz/xwERlpdo3jobbDyngJ3E4T8TwMaL CihL7O07xD6BUXAWkkmzkEyahTBpFpJJCxhZVjHKpuRW6eYmZuYUpybrFicn5uWlFuma6uVm luilppRuYgSHuovSDsaJ/7wOMQpwMCrx8GqUvogWYk0sK67MPcQoycGkJMr7/tyzaCG+pPyU yozE4oz4otKc1OJDjBIczEoivHw8L6OFeFMSK6tSi/JhUtIcLErivH9EHkcLCaQnlqRmp6YW pBbBZGU4OJQkeB/IATUKFqWmp1akZeaUIKSZODhBhvMADVeQBxleXJCYW5yZDpE/xagoJc77 SxYoIQCSyCjNg+sFpSKJ7P01rxjFgV4R5v0OsoIHmMbgul8BDWYCGlzy8jnI4JJEhJRUA6PN tBNO9+afd+zL0y50Z2PKOTlZfD7Ln4OGvO0+f+/nsWur6e/YvIPzXE1YSt2Wwwf+536Mmvno uIlsaMmjjbv+X2C1aW07Oc2SO6rDxUAnceIMdvYJNQrzNLRC/ma/9r9+2ayp8EhbJqPxW7m/ Qc3+6hz6LO0bA09MzzsacCHC54jip9DTjkosxRmJhlrMRcWJADfmqF8gAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/tCkeojcGTs5sHK1f7aX8maBUXLM>
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 06:39:53 -0000

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.

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

> 
> > (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