Re: [nfsv4] Adoption call for draft-dnoveck-rfc5661bis

[Chuck Lever III <[e-mail]>]

On Oct 22, 2022, at 9:46 AM, David Noveck <[e-mail]<mailto:[e-mail]>> wrote:



On Fri, Oct 21, 2022, 11:24 AM Chuck Lever III <[e-mail]<mailto:[e-mail]>> wrote:


On Oct 13, 2022, at 4:57 PM,⁰ David Noveck <[e-mail]<mailto:[e-mail]>> wrote:

This is an adoption call for draft-dnoveck-nfsv4 which is intended to be a standards-track describing nfsv4.1, obsoleting rfc8881.

As it says in the abstract,

-----

This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC7530) and protocol extensions made subsequently.  The later minor version has no dependencies on NFS version 4 minor version 0, and was , until recently, documented as a completely separate protocol.

This document is part of a set of documents which collectively obsolete RFC 8881.  In addition to many corrections and clarification, it will rely on NFSv4-wide documents to substantially revise the treatment of protocol extension, internationalization, and security, superseding the description of those aspects of the protocol appearing in RFCs 5661 and 8881.

-----

The chairs would like to determine whether there is interest in adopting this document by the nfsv4 working group. The adoption call will run for two weeks and end on 10/26/2022 (UTC time). Please send any objections or expressions of support for adoption to the wg mailing list.

As stated previously, since I am editor of this document, I will not be involved in making a judgment as to the existence of consensus.  It is expected that Brian will be doing this with Zahed available as a backup if circumstances do not allow Brian to do this job.

I've examined rfc5661bis in order to address the question of whether it is ready for WG adoption.

Both the document and the diff are huge (for any reasonable definitions of "huge").

Sections 1.2 and 1.3 should be relocated to the Appendix to keep such material together and to help reduce churn in the document's chapter and section numbering (resulting in cleaner diffs now as work progresses, and once these sections are removed before publication).

OK.  I can do that.


Throughout:

  *   The terms "TLS-based encryption" and "transport-level encryption" need to be replaced with "transport-layer confidentiality". Let's adopt the terminology used by the rest of the community.

I don't  agree.  After all, rfc9289, uses "encryption" and not "confidentiality".

That usage of the term "encryption" distinguishes between specific mechanisms that TLS provides: encryption and peer authentication.


I presume this is because encryption is clearer and is in fact how  confidentiality is provided.

It's because these are specific mechanisms provided by TLS. Confidentiality is the security policy we want. Encryption is one way to provide it. Using a private network is another completely valid and long-recognized way to provide confidentiality, and needs to be included in any discussion of the security issues of AUTH_SYS.


  *   RPCSEC GSS already provides client peer authentication.

Does it?  As I understood things, it provided client principal authentication.  If it did, there would be no need for the special ops defined in v4.1 to provide state protection.

  *   The use of TLS peer authentication is not novel.

It is now.


  *   The principles introduced and used in this discussion need to be generic, because surely RPC-with-TLS will not be the final word in transport-layer security.

Do you have any specifics on what you'd like to see?  I agree with being compatible with future development but we cannot be so generic that implementors are not clear what to do.

Even existing capabilities can provide much or all of the security we want for AUTH_SYS.

  *   Private storage area LANs provide confidentiality and obviate the need for client authentication. That's why the spec allows the use of AUTH_SYS in that kind of deployment.
  *   VPNs (such as provided by openvpn, wireguard, and ssh tunneling, all features currently available in general purpose OSes) can provide both confidentiality and peer authentication on open networks today.
  *   IPsec provides confidentiality, at least, and might be used as an example where the endpoint authentication it provides is indeed not adequate for our purpose.

You see that encryption is only but one means to a security policy, and that policy is confidentiality of communication?

It's been pointed out to me that TLS is unlikely to be the only mechanism by which transport-layer security is provided, in exactly the same way that Kerberos is not the only mechanism that can be employed via GSS-API. A protocol specification can make statements about how to use RPC-with-TLS or Kerberos, but it can't assume these are the only mechanisms that might be available. We must express our security requirements as policy statements, and not by mandating the use of specific mechanisms.


Security will also be described in a separate document applying to
all minor versions.  The handling is different because there is a
wider range of security-relevant features within v4.1, despite the
fact that the fundamental approach is the same for all minor
versions.  As a result, for some features, the security document
will have the lead role while, for others, the v4.1 specification
will be the main source of information about the feature, although
the basic security functionality will be as defined by the
NFSv4-wide security document.

I question whether separation of the security discussion in this way is truly beneficial to readers. Scattering the discussion like this will make it easy to miss important information.

We have to trade off document hugeness and decided, with good reason, to divide things this way.

My quibble is with "for some features... the security document will have the lead role... for others, the 4.1 sepcification will be the main source". I don't recall a specific discussion about dividing security in half, putting some in this document, and putting some in another. I view that organization in particular as not beneficial to readers.


I don't think it makes sense to shift things now

Why not? We should be easily able to decide that existing document organization is awkward and that it needs to be reworked.

The WG is going to be stuck with this organization once it is finalized and published. Let's try to get it right rather than resist fixing problems because that might delay things a bit.


The section defining the GSS service principal (common to all minor versions of NFSv4) should be moved to the security document.

Will look at addressing.

Section 6 is problematic. I suspect the intention was Section 6 through 6.3 are meant to be part of Section 5, and Section 6.3.1 "Put Filehandle Operations" is supposed to start a new chapter. Sections 6 through 6.3 belong in the security document, IMO, not in RFC 5661bis.

Will look at addressing.


Section 16.9 "Security Considerations for pNFS" belongs in the nfsv4-wide security document. The only minor version this section does not apply to is NFSv4.0. The caveat about the discussion covering non-RPC storage protocols is not pertinent, IMO; general security considerations should be the same for all layout types.

The general principles/requirements are the same.  However, the implementation considerations and potential threats are definitely different.

Likewise, Section 17.12 "Security Considerations for the File Layout Type".

Will look at that.


Section 19.1.11.3.  "NFS4ERR_BAD_HIGH_SLOT (Error Code 10077)" First sentence was changed to a sentence fragment that does not match the form/style of other error descriptions.
Section 19.1.16.4.  "NFS4ERR_RESOURCE (Error Code 10018)" What is the need for re-adding the RESOURCE status code?

Will fix that up.

Section 22.29.  "Operation 33: SECINFO - Obtain Available Security" I don't agree with moving the mechanical description of this operation along with its arguments and results to the nfsv4-security document. This appears to be the only operation that has been changed in this way even though there are other security-related operations in common amongst all NFSv4 minor versions.

OK


Section 1.2.2 says:

This shift is necessary because the description of SECINFO needs
to be revised to allow negotiation of security-related transport
characteristics in addition to auth-flavors, associated mechanisms
and RPCSEC_GSS services.

No one has yet agreed to address negotiation this way; in fact, there have been active objections to it.

I'm not sure about that.  The last I heard from you I'd that the response was "tepid".  Am prepared to respond to working group consensus on this, as judged by Brian.


Further, it says:

Significant work has been done to provide rpc-tls-based state
protection which can be taken advantage even by clients who have
not implemented SP4_MACH_CRED or SP4_SSV or who are using
AUTH_SYS.

The Section 5.5.3 has been revised to allow, when SP4_NONE is
used, to allow client host authentication to be used for state
protection.

Although this work might not introduce new protocol elements, the implications of getting this feature wrong are significant.

So are those of getting it right.  Am prepared to move this issue to a separate document if the wg wants.

I strongly urge that this change be postponed to a future document so that prototypes can be created and adequately tested.

Noted.


The document editor has attempted to address every known problem in this update. However there are so many issues to be dealt with that the resulting tumult of document changes are difficult to assess individually.

Nevertheless, they have to be addressed individually since it makes sense to address them collectively.

Regardless of any worries about "tumult", you and other members of the working group need to discuss these issues, if we are to make progress

Please don't dismiss the words that I used. Putting "tumult" in scare quotes is disrespectful. This is not the first time you've used this tactic.

I ask only for better visibility of proposed replacement text for each individual issue. The reason I'm asking is there seem to be multiple places where unnecessary or unrationalized textual changes have been made.


This has led to a seemingly limitless increase in the scope of changes in the bis with no opportunities for WG oversight until now.
The first revision of rfc5661bis was submitted only a week

Not true.  -00 was submitted 12/2020 and there has been ample opportunity for review and discussion.

Fair enough, I was looking at the date on rfc5662bis.

However, rfc5661bis-05 is dated in late September. Still a challenge, though less of one.


or and a request for adoption followed after just a few days without any time for WG contributors to review and absorb this update. This in my opinion is an abuse of process.

Your opinion is clearly misguided.  Please review the facts.


In particular, we need mechanisms to attribute provenance to each text change (eg, who requested the change and why, who wrote the replacement), a way to set off text changes (change bars or a commit log), and a less unwieldy way to compare the bis document to its base document; rfcdiff by itself is easily confused by changes in sections generated automatically, and is wholly unable to deal with document splits.

I don't agree that we need all this new mechanism.  What is needed is discussion of the consensus issues listed in Appendix B.  If people are unwilling to do that without major process work than rfc5661bis is going to be delayed for a number of years.

You have no way to know that.


Technical details aside, when this work is finally adopted, there needs to be much greater transparency.

It would be desirable  but it is not necessary and so should not delay the work.

I disagree: it is absolutely necessary.

This is supposed to be an open and public process. I don't feel we should rush through it just for convenience, so I have no sympathy for arguments about delay. We'll end up with a new set of unreviewed issues in the final document, just as was with RFC 5661. My suggestions are intended to help avoid that all too real hazard.

What I'm proposing is that we adopt process for these documents that aims to prevent the loss of context, history, and provenance in the ways that these were lost with RFC 5661. The mechanisms that implement such process are already in common use.


I am philosophically in favor of updating NFSv4 specifications and systematically addressing their known flaws.

Perhaps so but this philosophically commitment needs to be complemented but concrete help to move the document forward.

As the editor of what is so far a personal draft, you are responsible for asking clearly for what you need. It would be inappropriate for any of us to step in and walk on your plans, and we can't read your mind. Your expectations seem out of line with how personal drafts are normally handled.


> However, because of the short time frame during which this document has been actually available for review.

Not so.  See above.

> the lack of tools to accurately assess the documents in question, and the amount of work remaining (both in terms of adding unfinished material and editing out unnecessary, controversial, or deferrable changes), I am not enthusiastic about WG adoption at this time.

That's putting it mildly

A sarcastic response in this forum is not necessary or appropriate.

What I did was state my concerns without explicitly objecting to adoption. Again, I didn't object. Eventually the document will be ready for adoption, and it might even be adopted soon, despite my personal trepidations.


I would prefer to see more progress on this document as a personal draft while the WG attempts to address process transparency issues. I do not believe there is any impediment to progress in the absence of WG adoption.

The only impediments are ones you propose.

You view them as impediments. I view them as the same process that I have used for my documents for several years, and I consider it to be a native part of open document composition. This process is a natural part of document workflow, adopted from the workflow used by other WGs who have tackled clusters of documents and mounds of text and errata. It is workflow that is used by most open source developers.

Therefore I don't view my request as either unprecedented or unreasonable or unworkable.


I hope the working group will help improve this document without extensive, potentially unrealizable, process modifications.

I take issue with your unfounded characterization of proposed process modifications as extensive and potentially unrealizable. I haven't proposed anything that has not been proven in actual use by other WGs, or that is not typically used by other standards bodies, or that I haven't suggested in the past, you agreed to use, and then surreptitiously dropped because you couldn't figure out the web interface.

Not to put too fine a point on it, but the rest of us already do things this way. It is your viewpoint that is strangely out of touch.


--
Chuck Lever