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

[Magnus Westerlund <[e-mail]>]

Hi Chuck,

So this document is clearly an opportunistic mechanism. And I am not trying to
push things beyond this in this document. However, I need to understand the
answers to certain questions that are likely to arise in the IETF last call and
IESG evaluation. 

Thanks for clarifying that due to layering, it would be a bad idea for this
document to demand anything from NFS implementation. The NFS specificaiton
extension/updates will have to make such requirement. I am fine with conveying
that message to anyone raising this as an issue. 

Even on the RPC level, I do think the document can become clearer in that this
document's solution is strongly recommended to be implemented to improve
security. It is good that the document do dicsuss how policies can be
established to move this mechanism beyond just opportunistic. Hinting on the
likelihood that you will soon be required to support it. 

Thus, can one in introduce any RECOMMENDED/SHOULD writings on implementation of
this mechanism for RPC implementors? 

Second are there aspect of the non-normative text that can be improved? 

Cheers

Magnus




On Sun, 2020-04-05 at 13:58 -0400, Chuck Lever 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
> 
> 
> 
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------