Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls

[David Noveck <[e-mail]>]

> However, more context (like a security strategy statement) could be
> helpful. Dave was working on a document like that, but I don't know
> what state is is currently in. I don't see it in the personal drafts
> section of the nfsv4 document datatracker.

Due the press of other work, I now expect to submit an informational I-D
in May rather than in April.  As we will discuss on 4/22, this document
is intended for internal working group use and I don't expect it to be
published
as RFC

> IMO we are on a path towards requiring NFS with TLS.

I agree, but I think pc-tls needs to convey that the working group
shares  that opinion and intends to travw\erse that path, even
though, as you say, we are not in a position to impose
implementation requirements right now.

> This document is but the initial step.

s/but the/a crititical/

On Sun, Apr 5, 2020 at 1:58 PM Chuck Lever <[e-mail]> wrote:

> Going back to Magnus' original concern:
>
> > On Apr 1, 2020, at 4:27 AM, Magnus Westerlund <
> [e-mail]> wrote:
> >
> > 13. Requirement on implementation
> >
> > Should this document actually update any or all of the versions of NFS 4
> to mandate implementation support?
>
> IMO the proper place to make fresh requirements on NFSv4 implementations is
> in NFSv4-specific documents. I would rather not focus this document any
> more
> on NFS than it already is. And we have a plan to author and publish one or
> more NFSv4-specific documents regarding NFS-on-TLS (which will be covered
> to some extent during our interim meeting).
>
> So, I vote that this document should not update any NFSv4 standards-track
> documents.
>
>
> > From the WG's perspective doesn't it make sense to start demand
> implementation support. The mechanism is clearly opportunistic in its
> establishment, however the goal here needs to be to get support in as many
> places is as possible.
>
> Agreed, but practically speaking, the WG is not in control of
> implementations.
>
> With the rpc-tls proposal IMO we are trying to walk a very fine line
> between limiting protocol changes for existing implementations and
> meeting a critical security need. The opportunistic behavior of this
> mechanism is a key part of this proposal. And the document describes
> clearly ways that implementations can make the force the use of TLS.
>
> In other words, I'm hoping rpc-tls provides an easy step forward
> towards "support in as many places as possible".
>
>
> > Thus, sending a clearer signal that NFS 4.x servers and client are
> expected to support this should be sent. If not can you clarify what the
> concerns are? Because we are going to get this question again in the IESG
> evaluation.
>
> We've placed early versions of this document in front of members of the
> IETF's Security Directorate. They immediately recognized that an
> opportunistic tactic such as the one we propose in rpc-tls is a well-
> understand and practical way to improve security of legacy protocols
> such as NFS. I don't expect that they will object to the opportunistic
> nature of the proposal.
>
> However, more context (like a security strategy statement) could be
> helpful. Dave was working on a document like that, but I don't know
> what state is is currently in. I don't see it in the personal drafts
> section of the nfsv4 document datatracker.
>
> Alternately we could introduce some security-related text to the
> WG's charter that outlines NFSv4 security strategy.
>
>
> > To me the reasonable plan towards always used transport security
> (something I expect the full updates, for example of NFS v4.1 to require)
> is to require implementation but not usage now. Then next step to require
> its usage.
>
> That seems like jumping ahead of the gun. We have to get the new
> mechanism out there first. Then a subsequent NFS-on-RPC-on-TLS I-D can
> address the specifics of how NFSv4 will operate on TLS-protected
> transports. As recent nfsv4@ threads show, there are crucial NFS-
> specific details that need to be resolved before a requirement that
> is practical for NFS implementations can be made.
>
> IMO we are on a path towards requiring NFS with TLS. This document
> is but the initial step.
>
>
> --
> Chuck Lever
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>