Re: [nfsv4] Security document - sense of the working group

[Thomas Haynes <[e-mail]>]

> On Jan 30, 2024, at 12:02 PM, David Noveck <[e-mail]> wrote:
> 
> 
> 
> On Tue, Jan 30, 2024 at 12:43 PM Thomas Haynes <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>>> On Jan 30, 2024, at 8:22 AM, Chris Inacio <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> All,
>>> 
>>> The chairs would like a sense of the working group with regards to the draft-dnoveck-nfsv4-security-07 (https://datatracker.ietf.org/doc/draft-dnoveck-nfsv4-security/) and adoption.  Please let us know if you think the working group collectively agrees to the body of work proposed in the draft.
>>> 
>>> The sense of the chairs is that the working group does not have consensus on the scope or set of items presented in the current individual draft.  If that is the case, we would like to know what topics/items in the draft that you do support and which ones you do not believe are ready or that the WG will not be able to reach consensus on.  If there are steps that you think the working group should take towards clarity on any of those topics, the chairs are interested in hearing those too.
>>> 
>>> Thanks,
>>> NFSv4 Chairs
>>> 
>>> ----
>>> Chris Inacio
>>> [e-mail] <mailto:[e-mail]>
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> nfsv4 mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>> 
>> 
>> For me, the largest issue is whether vendors are required to revamp their implementations
> 
> They are not required to do so.   If you feel I am wrong, please cite a specific instance where the existing -07 would require an existing implementation to be revamped. 
>  
>> when we effectively rewrite NFSv4.0, NFSv4.1, and NFSv4.2.
> 
> That is not what the document does.  If it did, the job would be easier.   For example, we need information on existing ACL implementations to avoid mandating incompatible changes but that work has started and willl need to be completed once the document adoption is completed.
>> 


The document leads off with this:

   The need to make major changes in the security approach for three
   Proposed Standards ([RFC7530] for NFSv4.0, [RFC8881] for NFSv4.1, and
   [RFC7862] for NFSv4.2) raises troubling issues.  These changes are
   necessary as explained in Section 1.1.  These troubling issues often
   concern compatibility and compliance issues as described in
   Section 1.3.

Which strongly implies my point.

I’ll grant you that:

Although it might,
   given the security issues with AUTH_SYS, make sense to say that it
   "MUST NOT" be used in that way, the working group is very reluctant
   to retroactively declare previously compliant behavior 

Also implies such changes are not mandatory, but I would argue that the abstract/Introduction should make this clear.


>> I would propose that instead of the security changes being “backported” to the earlier versions, 
> 
> What changes are you speaking of?  Please be specific.
>  
>> we make the security document apply to all future releases.
> 
> This leaves the problem of what to say about security in the needed rfc5661bis.   I don't see how we can do a bis that either ignores security entirely  or continues to ignore the security issues with using AUTH_SYS in the clear.


So help me, we already have had RFC 8881, which is the RFC 5661bis. Why do we need another?




> 
>> 
>> Perhaps to differentiate, we make it NFSv5. I.e., NFSv5 is secure NFS.
> 
> Aside from the charter issue nightmaare this would create,, making this an entirely new protocol,, would open things up tp major XDR changes which would be a consequence of a major version change.   We don't need to do that and I don't thing the wg s prepared to do that..
> 
> We screwed some things up in this area  and need to fix our mistakes but an approach which relies on an entirely new protocol,  would inevitably brand NFSv4 as a complete failure.  I don't think we need to do that.
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/nfsv4