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>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/Zf5xzephRWCGfez71ErdlecJDF0>
Subject: Re: [nfsv4] AD review of draft-ietf-nfsv4-rfc5667bis-11
Precedence: list


> On Aug 9, 2017, at 6:53 AM, David Noveck <davenoveck@gmail.com> wrote:
>=20
> 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.
>=20
> 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.
>=20
> On Tue, Aug 8, 2017 at 8:45 PM, Chuck Lever <chuck.lever@oracle.com> =
wrote:
>=20
> > 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?
>=20
> Yes.
>=20
>=20
> > 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,
>=20
> Yep, that's how I read your comment yesterday, and how I reread the
> section upon review.
>=20
> I started by mentally removing that sentence, then I was less sure
> that the remaining text made sense.
>=20
>=20
> > 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".
>=20
> OK, if you read it that way, then I guess good communication is
> happening. That's pretty much what is intended.
>=20
>=20
> > 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.
>=20
> 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.
>=20
> Let's start with this:
>=20
>    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.
>=20
>    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.
>=20
> I suppose that could be OK. Any WG objections to going with this?
>=20
>=20
> --
> Chuck Lever
>=20
>=20
>=20
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>=20

--
Chuck Lever