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

[David Noveck <[e-mail]>]

On Tue, Jan 30, 2024 at 12:43 PM Thomas Haynes <[e-mail]> wrote:

>
>
> On Jan 30, 2024, at 8:22 AM, Chris Inacio <[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]
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [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.

>
> 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.


> 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]
> https://www.ietf.org/mailman/listinfo/nfsv4
>