Re: [nfsv4] AD review of draft-ietf-nfsv4-rfc5667bis-11

Chuck Lever <chuck.lever@oracle.com> Wed, 09 August 2017 17:44 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 2C7EE1243F3; Wed, 9 Aug 2017 10:44:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 25QPsqiYpajW; Wed, 9 Aug 2017 10:44:55 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 E102313245D; Wed, 9 Aug 2017 10:44:54 -0700 (PDT)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v79Hir8k029953 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Aug 2017 17:44:53 GMT
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 v79HiqxR011831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Aug 2017 17:44:53 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v79Hiq8U015236; Wed, 9 Aug 2017 17:44:52 GMT
Received: from anon-dhcp-171.1015granger.net (/68.46.169.226) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 Aug 2017 10:44:52 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <CADaq8jdQcHq4oNXgtJH5B4dVawtsgtFiWQFz5V_Hb=M7HD=2cQ@mail.gmail.com>
Date: Wed, 9 Aug 2017 13:44:50 -0400
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, "nfsv4-chairs@ietf.org" <nfsv4-chairs@ietf.org>, draft-ietf-nfsv4-rfc5667bis@ietf.org, NFSv4 <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <63DEE4DA-CAEB-4E95-B998-9533B64B344B@oracle.com>
References: <CAKKJt-fFFyxV=VhJxhe=3P283xZQG_yvdP6AHJkzU6iB=74JCw@mail.gmail.com> <C6965A7A-3A9F-466B-AEB7-73A8C96F3A9D@oracle.com> <CAKKJt-fbpBjz9=z8RqSGseKZxCY3e=rb6TsBZCEmNtPxKe0sdw@mail.gmail.com> <CAKKJt-foDqkhh_Q-pZT2Jqzfm8dCeBbtiRcarHJXtvMPykQFiw@mail.gmail.com> <3358F9D0-DEB8-4E86-835A-5070CD24FEAD@oracle.com> <CADaq8jdQcHq4oNXgtJH5B4dVawtsgtFiWQFz5V_Hb=M7HD=2cQ@mail.gmail.com>
To: David Noveck <davenoveck@gmail.com>
X-Mailer: Apple Mail (2.3124)
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/Zf5xzephRWCGfez71ErdlecJDF0>
Subject: Re: [nfsv4] AD review of draft-ietf-nfsv4-rfc5667bis-11
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 09 Aug 2017 17:44:57 -0000

> On Aug 9, 2017, at 6:53 AM, David Noveck <davenoveck@gmail.com> wrote:
> 
> I think this is OK.  I know that there is reason to worry about SECDIR but there is only so much you can usefully do, until they actually have something to look at.

"only so much you can ... do until [SECDIR] actually [has] something to look at"

Good point. I'll go with the edited text at the bottom of this e-mail.


> I imagine that SECDIR might be worried that direct placement could somehow open a hole whereby data might inadvertantly be transferred in the clear.
> 
> For example, if I ordered a "Large pizza with direct pepperoni placement" :), the pepperoni cannot be directly placed if privcy is in effect, but this sort of thing is aprropriately dealt with in RFC8166, as it should be.
> 
> On Tue, Aug 8, 2017 at 8:45 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
> 
> > On Aug 8, 2017, at 3:28 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> >
> > Hi, Chuck,
> >
> > On Mon, Aug 7, 2017 at 6:05 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> > Hi, Chuck,
> >
> > Thanks for the quick response. Getting back with an AD who hasn't slept since he sent his evaluation is ALWAYS appreciated.
> >
> > Responses inline, but Tl;Dr is "this all looks excellent".
> >
> > I see that you've submitted a -12, and I think it's ready for Last Call.
> >
> > You had mentioned wanting to think about the Security Considerations a bit more, so I thought a bit more, too. Here's what I'm wondering.
> >
> > The current text says this:
> >
> > 8.  Security Considerations
> >
> >
> >    RPC-over-RDMA version 1 supports all RPC security models, including
> >    RPCSEC_GSS security and transport-level security [RFC7861].  The
> >    choice of what Direct Data Placement mechanism to convey RPC argument
> >    and results does not affect this, since it changes only the method of
> >    data transfer.  Specifically, the requirements of [RFC8166] ensure
> >    that this choice does not introduce new vulnerabilities.
> >
> >    Because this document defines only the binding of the NFS protocols
> >    atop [RFC8166], all relevant security considerations are therefore to
> >    be described at that layer.
> >
> > What I think you're saying, is that the RPC security considerations have already been analyzed in RFC 7861, and the RDMA security considerations have already been analyzed in RFC 8166, so using RPC over RDMA shouldn't introduce new security considerations. Am I getting that right?
> 
> Yes.
> 
> 
> > Assuming so ... the sentence I was questioning, was
> >
> >    Specifically, the requirements of [RFC8166] ensure
> >    that this choice does not introduce new vulnerabilities.
> >
> >
> > Although I'm not a secdir reviewer (I don't even play one on the Internet), I'm reading that sentence as an invitation to go look at the requirements of [RFC8166] and see if that makes sense. Other reviewers might or might not accept that invitation, but I find myself wondering whether you need this sentence at all,
> 
> Yep, that's how I read your comment yesterday, and how I reread the
> section upon review.
> 
> I started by mentally removing that sentence, then I was less sure
> that the remaining text made sense.
> 
> 
> > since you've basically said, "we've analyzed the pizza crust, and we've analyzed the pizza ingredients, so we don't have new problems when we put the ingredients on the crust and make a pizza".
> 
> OK, if you read it that way, then I guess good communication is
> happening. That's pretty much what is intended.
> 
> 
> > Do you think the working group needs to think about this some more? I'm happy to hold off on Last Call, if the answer is "yes", of course.
> 
> Given recent scrutiny of the Security Considerations in our WG work
> products, it might be prudent for the WG to reconsider just this
> section for a few moments.
> 
> Let's start with this:
> 
>    RPC-over-RDMA version 1 supports all RPC security models, including
>    RPCSEC_GSS security and transport-level security [RFC7861].  The
>    choice of what Direct Data Placement mechanism to convey RPC argument
>    and results does not affect this, since it changes only the method of
>    data transfer.
> 
>    Because this document defines only the binding of the NFS protocols
>    atop [RFC8166], all relevant security considerations are therefore to
>    be described at that layer.
> 
> I suppose that could be OK. Any WG objections to going with this?
> 
> 
> --
> Chuck Lever
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
> 

--
Chuck Lever