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

[David Noveck <[e-mail]>]

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

>
>
> On Oct 22, 2022, at 9:46 AM, David Noveck <[e-mail]> wrote:
>
>
>
> On Fri, Oct 21, 2022, 11:24 AM Chuck Lever III <[e-mail]>
> wrote:
>
>>
>>
>> On Oct 13, 2022, at 4:57 PM,⁰ David Noveck <[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.


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

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?

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



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


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


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.

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



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


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

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

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.

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

But you clearly were aware of earlier 5661bis drafts since we discussed how
they dealt with various errata,

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

But in no way an abuse of process. The changes from -04 were mostly errata
fixes that we discussed in detail.  Zahed actually asked for this earlier
and the adoption call was delayed because Brian  was hard to get a hold
of.


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


>
> 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).  This is not an
issue of uncertain provenance.  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.

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



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


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

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?


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


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


>