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

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

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



On Sat, Oct 22, 2022, 1:03 PM Chuck Lever III <[e-mail]<mailto:[e-mail]>> wrote:


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.

Not entirely.  I was referring to its appearance in the title of the document.

Titles are not always precise. Also, don't judge a book by its cover.

And that still doesn't mean confidentiality is not the right terminology to use when referring to the security service that RPC-with-TLS provides to upper layer protocols, especially because RPC-with-TLS is not the only way to provide the level of security that we want for AUTH_SYS.


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.

And you published rfc9289 in order to provide it.

Using a private network is another completely valid

It only provides confidentiality to those outside the network.  Those inside the network are not provided confidentiality with regard to one another.

and long-recognized way to provide confidentiality,

It doesn't provide it against  insider threats..  If it did, rfc9289 would have been a waste of time.  The fact that some people  erroneously believed that it  was adequate to allow safe use of AUTH_SYS does not change that.

That's one reason why a private storage area network is not a ubiquitous solution. Another is that it doesn't work for open internet deployments. The point is, though, that it is adequate for some deployments where performance is a requirement and all of the clients and users are known and trusted (or the data is all R/O, or it is not sensitive).

For instance, there might be a deployment with only one user and one client on a closed network (which is in fact my own home deployment scenario). Why would you saddle such a deployment with the overhead of encrypted communication?

People will continue to deploy NFS on private networks using AUTH_SYS. It's better if the specification is up front about this rather than trying to ignore it.


and needs to be included in any discussion of the security issues of AUTH_SYS.

I disagree  strongly.

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

If they provided all of the needed security, then there would be no need for rfc9289.  I don't know what you mean by "much or all".  If it  is not all, what good is it?

RPC-with-TLS will not be deployed everywhere in every case. You are intentionally distracting from my point, which is there are multiple mechanisms (some not invented yet) by which appropriate confidentiality can be achieved. We can't reasonably nail ourselves to exactly one.


  *   Private storage area LANs provide confidentiality and obviate the need for client authentication.

No they don't.  See above.

Regarding "obviate the need for client authentication", think about how such a statement would be received by the security directorate. I could not present a document containing that statement  to the IESG and I really don't  understand why you make it.

I never proposed "obviate the need for client authentication" as text to be included in a specification, so this is a straw man that you invented.


  *   That's why the spec allows the use of AUTH_SYS in that kind of deployment.

Rfc5661 makes no mention of this iirc. I don't know why it says what it does but feel it is quite wrong about AUTH_SYS as was rfcs 3530/7530.

If you think rfc5661 is right about AUTH_SYS , then it is difficult to see how we could ever come to agreement.

I don't think RFC 5661 is right. I think that the proposed replacement is wrong too. Coloring my request as black and white is an unfortunate tactic to try to win an argument rather than come to an understanding.


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

If they can provide full confidentiality and not just what is provided by so-called private networks, then they should be included.  Protection against insider threats is necessary.

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

I don't  see filling  the document up with examples of things which are not adequate.

I'm not suggesting filling the document up with examples, that's your intentional mischaracterization of what I'm saying. Instead, I am showing that:


  *   The proper terminology to use is "confidentiality". That is what the rest of the community uses when they mean that a protocol needs to protect against snooping while data is in-transit.
  *   There are alternatives that provide varying degrees of security. Most or all of them are valid in some cases. What is needed is a security policy framework that helps implementers and administrators choose what is best for them and their users. The specifications can then explain how to implement each of those choices.


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

There don't seem to be any others.

Wireguard is clearly similar enough to TLS that it is a reasonable deployment choice, so again you are intentionally misconstruing my words.

People generally want to choose among a few good alternatives. RPC-with-TLS will not always be available or appropriate for every deployment. That is a reality that I believe the specification needs to reflect.

Let's look at another example. A putative RPC-over-QUIC transport, for example, uses the TLSv1.3 handshake for peer authentication and to negotiate session keys and ciphers. But it does not use the TLS record subprotocol -- it uses it's own record protocol to exchange encrypted payloads. The encryption in both QUIC and TLS are a security service provided at the transport layer, and both of those use a standard cipher. Like TLS, QUIC provides a transport-layer encryption mechanism, but I don't think it is accurate to call that "TLS encryption".

You treat TLS encryption as a generic term. It isn't. "TLS" means a session security protocol specified by RFC 8446 and its antecedents. RPC-with-TLS is a security mechanism that uses TLSv1.3 to protect upper layer protocols that run over RPC on UDP or TCP. Outside of the context of a discussion about what security mechanisms TLS can provide, TLS encryption doesn't have the precision of meaning that is appropriate to a security discussion in other protocol documents.

A generic term that describes what you might be after is "confidentiality of data in transit".

In addition, it doesn't make sense to say "TLS encryption" when what you mean is RPC-with-TLS, where in-flight encryption is mandatory-to-implement per RFC 9289. Using RPC-with-TLS just by itself means in-flight payload encryption is always in use.


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.

OK.

We must express our security requirements as policy statements, and not by mandating the use of specific mechanisms.

As long as the policy statements make sense.   Some of yours above don't, unfortunately.

They may not make sense to you, but that's because you are intentionally not bothering to think carefully about what I'm telling you, you are only thinking of ways to try to win your argument.


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.

My view is different.  pNFS is different because it includes support for many storage protocols, that have different security characteristics than those based on RPC.

That doesn't explain why the documents are organized this way.

NFS is the high-order bit here. Applications and users see an NFS mount on clients. The optics are that NFS is providing the security. The underlying protocols therefore have a set of requirements that arise from the needs of NFS (and native OS) security policies and mechanisms. The specific mechanisms provided by the DS storage protocols have to address and provide the same security policies that NFS provides, don't they?

I still don't believe anyone is served by separating the discussions like this.


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.

If it truly were awkward, then we could see about a change.



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.

Exactly so.   If it is known issue, it has to be addressed.  I don't want the abstract to say "this document describes the protocol except for some issues we chose to ignore".

RFC 8881 is existence proof of exactly the opposite. It was a narrowly-scoped update of RFC 5661 that quite intentionally addressed some issues and ignored others. I'm proposing the same kind of update here. Trying to address every last flaw is making perfection the enemy of good enough.


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.

I did not do so.

That statement itself dismisses what I observed, and goes exactly to my point. Your intention doesn't matter here, it's how your statement was received that is at issue.

I wanted to understand what you meant as I didn't see any tumult. Tumult is defined as a loud confused noise, especially one caused by a large mass of people.  In this case, only one person is involved and I see neither loudness or confusion in my work.   I cannot  figure out what you meant in using this word. Please explain what you meant.

Putting "tumult" in scare quotes is disrespectful.

I don't think so..

I know you don't, that's why I pointed it out. Some find this disrespectful. Please avoid using this tactic when engaged in discussions like this.


This is not the first time you've used this tactic.

If you continue as you have been, it probably won't be the last.

That's victim blaming, another tactic that we'll have to deal with.


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.

If you would identify those, it would help improve the document.  As it is, I'm not sure how to address your feelings of uneasiness.

This was never intended to be a formal review, but I did already identify a couple of cases in the error code changes. I haven't gotten to nfsv4-security where there are others, but I've already offered an opinion on WG adoption of that document. We can get to those as work progresses.


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.

Perhaps I'm misunderstanding.  What precisely are you asking for? For example, "a less unwieldy way to compare the bis document to the base document sounds to me like a big ask for the rfcdiff team.  I don't think years is an unreasonable time estimate.

I never said anything about changing rfcdiff. If something is unclear, just ask for clarification. Don't straw man it with the worst possible alternative.

I've already proposed a mechanism for the two larger documents to make this easier for everyone: Construct and make available base documents that can be used by rfcdiff that reduce the amount of clutter in the diff output.

  *   For rfc5661bis, construct a document that is exactly the original text of RFC 8881 with the sections extract that have been moved to other documents. That way we can see only the changes made to text that is staying in the main bis document.
  *   For nfsv4-security, construct a document with only the original RFC 8881 text that will be updated, in exactly the order in which nfsv4-security has those sections organized. That way we can see exactly how the text has changed in those sections.

Both of these are simple cut-and-paste jobs. These base documents can be re-organized whenever changes to the new documents require it.


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.

That is probably the intention but I feel the problems with rfc5661 would not have been any different if the process were different. I don't see how provenance information would have helped avoid us saying "AUTH_SYS is an OPTIONAL means of authentication" (emphasis added).

It might not prevent that kind of statement, but it can give us insight into why it says that, what was discussed to arrive at that statement, and any expert review comments or IESG input that might have requested changes to it.


This is not an issue of uncertain provenance.

This one might not be, but it's not the only text that's being modified by the bis updates.


We would be no better off knowing which of the co-editors wrote this text. In any case, the text probably came over from rfc3530 unmodified. The problem is that none of the editors looked at whether this characterization made sense. The same happened with internationalization and the provenance issues are discussed in rfc7530 and the new internationalization document.   Some people made in the IESG made a mistake.   I haven't een able to identify them and knowing who they were would not help things.

Not always a question of who. A record of decisions (or no decision) helps, if it exists, as you demonstrate here. Don't you want a toolchain that makes document archaeology easier?


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.

If you are proposing we use github, just say that.  If that is the sum of your process issues, then I think we can move forward.

Again, I'm expressing the idea that we need to do better. git with GitHub provides a set of services that would improve our process, IMO. I'm not forever attached to using GitHub, but that would be a good choice.


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.

For the security document, what I am asking for is laid out in the appendices.  For the other documents I just want a serious review. Is it unreasonable to expect that?

History shows that asking once is usually not adequate. I don't believe it's fair to expect continued working group attention to a personal draft that has already been allowed to expire twice in two years (if I'm reading the datatracker correctly). It's really unclear to others whether you are not getting what you want if you don't say so in a direct and friendly manner.

But this is a nit.


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.

Asking for major changes in diff tools is not unreasonable but unless we find someone willing to do the work, making it a must-have is definitely unreasonable

Can you pare down your list of requirements to something that will not involve major amounts of process work?

Use GitHub, if that's acceptable. Christoph uses a stand-alone public git server, which also works. Bruce has used git.linux-nfs.org<http://git.linux-nfs.org> in the past. There are other public git services if you prefer to avoid our Microsoft overlords.

But Martin Thompson has provided a lovely set of GitHub actions, which he actively supports, to automate the update of public editor's copies and the submission of new revisions. So going with GitHub seems like the best choice.


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.

I believe our agreement was that we would switch to github when documents were adopted as working group documents.  I am still open to that but I was expecting you to drive that process and provide help with interface issues.

That's possibly not a fair use of my time. You seem to want me to be your private help desk.

What's more, I don't use the browser for editing, I use vim and the git command line. Others might be able to give you some advice about how to use GitHub's browser interface. In fact, GitHub provides quite a bit of documentation on how to work in a browser-only environment. Or:

  *   Someone with Linux/Unix on Windows expertise can share how to get the git command line tools working there.
  *   Ask to have GitHub Desktop installed on your system (or in a guest on your system) and use that with a native editor of your choice.


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.

I am not sure what you are referring to but I'm getting awfully tired of being accused of things such as abuse of process, surreptitious behavior, a loud and confused  noisy document (?) and having an out-of-touch viewpoint based on your speculation/misunderstanding.

When you ask for document review and then fight with your reviewers, you're going to get pushback. I misread one date, but otherwise, the misunderstandings here seem to be that you overreact to my words. If something isn't clear to you, ask; don't inflate and then argue based on your own straw men.


--
Chuck Lever