Re: [secdir] [nfsv4] Secdir early review of draft-ietf-nfsv4-rpc-tls-03

[Chuck Lever <[e-mail]>]

> On Oct 23, 2019, at 6:24 AM, David Noveck <[e-mail]> wrote:
> 
> >> This is going to have to be much more detailed to convince me that it
> >> does either of these things for any implementation other than DESY or
> >> Hammerspace, and without other reference implemenatation in the BSDs or
> >> a least some flavors of Linux, you can't say this broadly interoperable
> >> either.
> 
> The document doesn't say that and there is no reason for it to do so.  The document's
> job is to defne a means by which better security could be achieved, when implementations
> are available.   If one waits for implementations to be done before approviing the
> specification, one is going to be waiting a long time, and NFS security will remain
> in its current unsatisfactory state indefinitely.
> 
> > We host two NFS interoperability events a year and can easily
> > demonstrate that we have achieved reasonable interop, if that
> > is required by the IESG.
> 
> I don't believe it is required for a Proposed Standard.   As I understand
> it, no actual implementations are required although the working group 
> has decided that prototyping of extensions is desirable.   Going
> beyond that point and requiring full implementations of protocols that
> have not been approved would be a mistake.
>  
> >> Distributed file systems are never easy, hence DCE/AFS, so
> >> granted it's not an easy problem, but this is not ready to advance on
> >> Standards Track, unless merely being interoperable with legacy code is
> >> all we aspire to, and I sincerely hope it's not.
> 
> I think it should be clear that Chuck's and Trond's aspirations go beyond this.
> If they didn't, there would have been no need to work on this document.
> The situation is similar for those who have worked on implementations.
> 
> If interoperation with legacy code is all one aspires to, one could implement
> the security specfified in rfcs 7530 and 5661.   These people and the working
> group clearly want something better.
> 
> That being said, the ability to work with legacy implementations is, in practical
> terms, a requirement of this enterprise.   There is no point in defining a secure 
> protocol island that cannot communicate with the implementations that exist today.
> 
> > > Perhaps this needle can be threaded and with appropriate configuration
> > > by enterprising people, TLS can be configured with DNSSEC and GSS-API in
> > > RPC and NFS and it will do something reasonable and secure, 
> 
> If I understand this correctly, Derrel is saying that, with the appropriate configuration
> which he mentions, you would have someting "reasonanble and secure"  :-)
> 
> That makes it hard for me to undertstand the negative tone of this review.   In any case,
> I think his specific suggestions should be followed up on to get the document ready for
> WGLC.

Agreed. The entire review has been filed as an issue against the document.

https://github.com/chucklever/i-d-rpc-tls/issues/3

I will work with Trond to address the specific issues Derrell has called out.


> > like to see at least some more comments from implementation experience
> > before I could recommend this advance.  
> 
> I think this is the wrong approach.   In my experience, it is very hard to get people to
> invest resources in implementing something that is not at least a Proposed Standand,
> and potentially open to  radical change before publication.  From a return-on-investment
> perspective, it doesn't make sense to invest in anytihing beyond limited prototyping.
> 
> The fact that so much expeimental implementation has already been done in this area
> illustrates the perceived urgency of the situation with regard to NFS security.   That
> work will continue in any case and implemtation experience will be available but I
> feel it would be a mistake to hold this document up waiting for it.   I think it would be
> best if the document is clarified and improved, go through WGLC, and be considered
> for adoption as a Proposed Standard.   That is a better way of getting resources
> allocated to the job of improving NFS security.
> 
> Of course, if anyone has an appoach to improving NFS security, that is better than
> that in rpc-tls, the working group would intestested in earing about it.

I also welcome hearing new ideas in this area.


--
Chuck Lever