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

Chuck Lever <chuck.lever@oracle.com> Mon, 23 September 2019 17:48 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 E88981200F4 for <nfsv4@ietfa.amsl.com>; Mon, 23 Sep 2019 10:48:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 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] 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 cNBBqfEd3oW5 for <nfsv4@ietfa.amsl.com>; Mon, 23 Sep 2019 10:48:23 -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 EAA9F12004D for <nfsv4@ietf.org>; Mon, 23 Sep 2019 10:48:22 -0700 (PDT)
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 x8NHdIX4089989; Mon, 23 Sep 2019 17:48:21 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=FWw+lwmQtElYinwgvV7ruP1y/K52RfMHfEX/iwWMOyY=; b=h2s/4fjTDw1qzW9+5c2wtwW+k4dVs2ZR+POnFotBAY5IAUbGZDyBnLOW2RW98I+YuKke WBXj9IiSeKKJBWOL/AT8Qr4S4R/mC8RBsLDMt2wURlQm6gM3HLmIRbVkQ5IMa0p/EebL fqdFOq9XO8zgiHMMkFFe0AcXO2ro2/Uvjgi7Rp7gZlfJfFRgiqVtLZXyIooj0gbTo7Jm tKNHIatURJ5y/4e6kT5nSup3OCQWNa5bZv82HTkyB58N1052I4B+fM71XT7ww5yzVv6U tL3gxcgybNOFNf8sWLZl2vNdpPaGy4qrrFJLAH9htiykCN2rfswGcPOilyT7HywkvsbU kg==
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2v5cgqrfp4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Sep 2019 17:48:21 +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 x8NHd4fg116665; Mon, 23 Sep 2019 17:48:20 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 2v6yvnayq5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Sep 2019 17:48:20 +0000
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x8NHmKM4014858; Mon, 23 Sep 2019 17:48:20 GMT
Received: from [10.3.1.157] (/8.25.222.2) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Sep 2019 10:48:20 -0700
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: <CADaq8jfBCoJ=dx5uGGJZhdH7x3Ca3HWEPsi19KVPJW9dKok4Yw@mail.gmail.com>
Date: Mon, 23 Sep 2019 10:48:19 -0700
Cc: NFSv4 <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A24D851A-8210-4CEB-A6B9-960347EE420E@oracle.com>
References: <156919386717.1348.4052993311401417839@ietfa.amsl.com> <9BFB101A-F1E8-45C8-A85E-74DB434CE658@oracle.com> <CADaq8jdS+MUgV6kQ7hGH8vh47Akejc4N0djHerU5VFKGRW6oSw@mail.gmail.com> <A455DB96-4C40-491C-A0EB-A602FE64766F@oracle.com> <CADaq8jfBCoJ=dx5uGGJZhdH7x3Ca3HWEPsi19KVPJW9dKok4Yw@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=9389 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-1908290000 definitions=main-1909230157
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9389 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-1908290000 definitions=main-1909230157
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/ZIwxrcf7tVspzltS_I6y3hVZtek>
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-06.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, 23 Sep 2019 17:48:26 -0000


> On Sep 23, 2019, at 10:19 AM, David Noveck <davenoveck@gmail.com> wrote:
> 
> > The guidance in that section falls into the realm of "compromise between the Linux community and the > specification writer"  
> 
> I gaathered that, but it should not be assumed that the woring group is prepared for the same level of compromise,

Help me understand exactly why the current section is lacking. I don't see
why the exact authorization mechanism must be specified in this document,
since:

a. it doesn't matter for interoperability
b. the mechanism used for updating IMA metadata on
   local files on Linux (the CAP_SYS_ADMIN capability)
   does not exist in NFS; moreover capabilities are
   not defined in a standard
c. authorization is done by policy in other arenas
   (for example, the IP-based access control that is
   implemented by most current NFS servers), thus it
   should be sufficient here too


> even though it should strive to be as helpfu as it can.   Also, it appears that the Linux community cannot make its own mind about how to address this issue so perhaps some intra-community compromise is in order.

See above. It's really not a simple matter of the community shrugging and
punting.


> If that isn't forthcoming, our only option might to approve this as an experimental/informational  RFC and upgrade it when the Linux community gets its act together.

That's a bit unfair. See above: there is a complete mismatch between how
it works on local file systems and what mechanisms are available with NFS.
IMO we are in a position to enable both "close enough" server implementations
and for server implementers to exercise some innovation.

Anticipating the IESG's reaction to this text is probably not going to be
possible or helpful. I'd rather hear their complaints from them. Let's focus
on the WG's concerns first.


> On Mon, Sep 23, 2019 at 12:28 PM Chuck Lever <chuck.lever@oracle.com> wrote:
> Context: The guidance in that section falls into the realm of "compromise between the Linux community and the specification writer".
> 
> 
> > On Sep 23, 2019, at 8:23 AM, David Noveck <davenoveck@gmail.com> wrote:
> > 
> > > It's probably ready for (it's first) WGLC. :-) 
> > 
> > I feel that the basic issue with section 4.3.2 has not been 
> > satisfactorily resolved.    I'll send out a mail with the details 
> > in the next few days.
> > 
> > 
> > 
> > On Sun, Sep 22, 2019 at 7:15 PM Chuck Lever <chuck.lever@oracle.com> wrote:
> > 
> > 
> > > On Sep 22, 2019, at 4:11 PM, internet-drafts@ietf.org wrote:
> > > 
> > > 
> > > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > > This draft is a work item of the Network File System Version 4 WG of the IETF.
> > > 
> > >        Title           : Integrity Measurement for Network File System version 4
> > >        Author          : Charles Lever
> > >       Filename        : draft-ietf-nfsv4-integrity-measurement-06.txt
> > >       Pages           : 18
> > >       Date            : 2019-09-22
> > > 
> > > Abstract:
> > >   This document specifies an OPTIONAL extension to NFS version 4 minor
> > >   version 2 that enables Linux Integrity Measurement Architecture
> > >   metadata (IMA) to be conveyed between NFS version 4.2 servers and
> > >   clients.  Integrity measurement authenticates the creator of a file's
> > >   content and helps guarantee the content's integrity end-to-end from
> > >   creation to use.
> > > 
> > > 
> > > The IETF datatracker status page for this draft is:
> > > https://datatracker.ietf.org/doc/draft-ietf-nfsv4-integrity-measurement/
> > > 
> > > There are also htmlized versions available at:
> > > https://tools.ietf.org/html/draft-ietf-nfsv4-integrity-measurement-06
> > > https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-integrity-measurement-06
> > > 
> > > A diff from the previous version is available at:
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-integrity-measurement-06
> > > 
> > > 
> > > Please note that it may take a couple of minutes from the time of submission
> > > until the htmlized version and diff are available at tools.ietf.org.
> > > 
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > 
> > Fresh revision incorporates comments from IETF 105 and Linux
> > Security Summit North America 2019.
> > 
> > It's probably ready for (it's first) WGLC. :-) It's OK if the
> > chair prefers to wait until we have more fully dealt with
> > outstanding RFC 5661 errata.
> > 
> > 
> > --
> > Chuck Lever
> > 
> > 
> > 
> > _______________________________________________
> > nfsv4 mailing list
> > nfsv4@ietf.org
> > https://www.ietf.org/mailman/listinfo/nfsv4
> 
> --
> Chuck Lever
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever