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

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
>