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

David Noveck <davenoveck@gmail.com> Wed, 09 August 2017 10:53 UTC

Return-Path: <davenoveck@gmail.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 61569132113; Wed, 9 Aug 2017 03:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PYtKnTb3336F; Wed, 9 Aug 2017 03:53:46 -0700 (PDT)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 821E6132143; Wed, 9 Aug 2017 03:53:46 -0700 (PDT)
Received: by mail-io0-x234.google.com with SMTP id g71so23546587ioe.5; Wed, 09 Aug 2017 03:53:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DdNML32z0e+4sSrlfWWhex+7AEN/PDoZQJ1ix3yPiMc=; b=JIoBnyD3aUmUfSq3Xucw8/eLR0qQqXotjArx16dU/vGgbduVwLnWktRUq51GqljDsh UIbcrnb34h7q5WLAFqq1Ya+wWeQIqUuZfPcMWW62Hxy999F1V/ehPREeqyLxJN8aYn/v wQZzqWMTsuOGhTsqlp1+RmPKP/09FQXM/3t8IULzzydhXPL2SOrzYKAPej34DSCO+tzE JUzW2OWtZzjcp4ACrgokYX3WZLK/gyVJxbHAazhXGoPc/JufJNIgFgwgG7kw2YvOITxB f+6WcjW8u497arPR1JTJA2gOAp4ACQIqOeg6IxeNrVkmrfq73OJf1uCQHTjH+7k7KIDn tu2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DdNML32z0e+4sSrlfWWhex+7AEN/PDoZQJ1ix3yPiMc=; b=nWrSQpCfPGSOgghBiEaTIOlIML77vHiDVPe7dSbJsg1nXRdcG7w5HHtexxjUiPdyTW XK4zyqgaF3C9IhX3WHscflTEJW5xdbpNTgErBQrqflWL4lZ++kn0Hqx8oV8WFO/pQ8FN fFXXsg64To7ohKTKijhOcz/vcyXSLMmdqbzrqCOhvqHp/RqTF6wncpJYBDzHFE4eIvQ7 Xa5QE3frcbOVfk7QvItFFYEN9ordmSDs19s+nzZafy3n4EwiY3eKnbCn53myPQ6kt/wA EBn3D0J4V+tMLtv1PSyTGB1sSJ+6tvG6L/f4VrJXzQNdjGc35K40tjKTroHyfFvYaRoJ i91g==
X-Gm-Message-State: AIVw1104DuFMcX0widZ50aINV79hfYYeP/+oWWhKjNgdozeBw5XaLNFt NDXKqq9kV7KNX7JJOxrLK78OwLt8cA==
X-Received: by 10.107.137.15 with SMTP id l15mr5826333iod.13.1502276025631; Wed, 09 Aug 2017 03:53:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.142.72 with HTTP; Wed, 9 Aug 2017 03:53:44 -0700 (PDT)
In-Reply-To: <3358F9D0-DEB8-4E86-835A-5070CD24FEAD@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>
From: David Noveck <davenoveck@gmail.com>
Date: Wed, 9 Aug 2017 06:53:44 -0400
Message-ID: <CADaq8jdQcHq4oNXgtJH5B4dVawtsgtFiWQFz5V_Hb=M7HD=2cQ@mail.gmail.com>
To: Chuck Lever <chuck.lever@oracle.com>
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-Type: multipart/alternative; boundary="001a113ed3a6dcc9d705564fe4ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/go19H08YCFV9rEX5sQtrm7RnntI>
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 10:53:49 -0000

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.

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
>