[nfsv4] Stephen Farrell's No Objection on draft-ietf-nfsv4-minorversion2-40: (with COMMENT)

"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Thu, 21 January 2016 14:15 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: nfsv4@ietf.org
Delivered-To: nfsv4@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9AC1A8835; Thu, 21 Jan 2016 06:15:30 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160121141530.8170.25186.idtracker@ietfa.amsl.com>
Date: Thu, 21 Jan 2016 06:15:30 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/nfsv4/P9lE0OTAYTSkVJ1ViXsEQEDPoFo>
Cc: draft-ietf-nfsv4-minorversion2@ietf.org, nfsv4@ietf.org, nfsv4-chairs@ietf.org
Subject: [nfsv4] Stephen Farrell's No Objection on draft-ietf-nfsv4-minorversion2-40: (with COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Jan 2016 14:15:30 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-nfsv4-minorversion2-40: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-minorversion2/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------



- 1.3.2: I'm just curious, feel free to ignore. Does anyone
maintain those posix specs these days? (e.g.
[posix_fadvise]).

- 1.4: "a new arm" isn't clear to this reader, maybe
consider re-phrasing if this isn't a common NFS term (if it
is, that's fine)

- 4.10: thanks for providing all that!

- 4.10: possibly dumb question: does this (or NFSv4) support
what a user would perceive as an encrypting file system
where the keys are held-by/derived from something on the
user's machine? If so, and if the two servers involved use
keys known at the user's machine and not by the NFS
infrastructure then I'm not sure how this can work. IOW, if
there's a decryption and then a re-encryption required in a
server-server copy and if that needs any keying material
from the client then could that ever work? Note that I'm not
talking about securing the file during the server-server
copy but de-crypting before sending and then re-encrypting
before storing.

- 9.6: Is it considered a requirement that e.g. a user
cleared to secret cannot tell if there is anything stored
that is of higher classification? If so, did anyone go
through all NFS interfaces to check if e.g. disk or
directory usage information could give away the fact that
there is stuff stored that's not visible to this user?  I'm
not arguing that this definitely needs to be done
exhaustively, but maybe consider adding a caveat emptor
sentence somewhere saying that even with MAC, it could be
that NFS allows for some minor meta-data leakage such as the
above.