Re: [nfsv4] New Version Notification for draft-dnoveck-nfsv4-security-07.txt

[Thomas Haynes <[e-mail]>]

Resending...

> On Nov 16, 2023, at 11:05 AM, Thomas Haynes <[e-mail]> wrote:
> 
> I will be on a plane for the first meeting.
> 
> Please use a spell checker.
> 
> 1) Section 1.1.1.
> *  The attributess owner, owner-group, and mode needed to be made
> ^^ spelling
> 
> 2) 1.1.2.
>       ovecomplicate the specification, and create difficult
> ^^ spelling
> 
> 2.1) 
> 
> The attributess owner, owner-group, and mode needed to be made
>       REQUIRED since clients need this information and not supporting
>       these attributes would create troublesome interoperabiity issues.
> a) This almost sounds normative, with “need” being “MUST”.
> 
> b) But more importantly, why do the clients require these attributes and what troublesome interoperability issues will arise?
> 
> c) “interoperabiity” is misspelled.
> 
> I’m not going to call out any remaining spelling errors, please use a spell checker.
> 
> 3) Then:
> 
>       the acl-related attributes either.  To continue in this way would
> Vs
> 
>    *  The handling of ACLs is not described in the detail normally
> a) Is ACL to be capitalized or not?
> 
> b) And the first use should expand the acronym.
> 
> 4) 
> 
> Because of
>       the broad license granted by previous specifications to allow
>       server implementations to choose how to behave, clients are forced
>       to accept a broad range of server behaviors, with no way of
>       reliably determining server behavior actually implemented.
> a) I understand why you use “license", but my first thought was confusion because I didn’t think the IETF granted use licenses.
> 
> b) “broad” is repeated. I got the point the first time you used it.
> 
> 5) Is this one or two sentences? The first seems to end prematurely.
> 
> The remaining issue caused by this approach, of providing a way
>       for clients to determine the authorization-related effects of
>       setting.  ACLs or other security-related attributes, cannot be
>       addressed in this way.
> 
> 
> 6) In section 1, features are introduced without any reference to where they appear in one of the prior documents. I understand that this is difficult due to there being 3 versions to support, but we can decide to simply reference RFC7530.
> 
> 
> Section 1.2.
> 
> For such pending issues, the following annotations will be used:
> 
>    *  A paragraph headed "[Author Aside]:", provides the author's
>       comments about possible changes and will probably not appear in an
>       eventual RFC.
> 7) In the section tags, you can add removeInRFC=“false” or removeInRFC=“true”. You might be able to add this to other tags,
> 
> Section 1.3.
> 
> 8) A lot of repetition in this section.
> 
> Perhaps the way to deal with compliance is to state that the changes made in this document they should be addressed in prior versions, but are required for the next version of NFSv4.
> 
> I.e., one specific concern would be to say that AUTH_SYS is not supported in NFSv4.3 and beyond.
> 
> Whether we require Kerberos or RPC-with-TLS is something we can determine when we get to NFS4.3.
> 
> Appendix A:
> 
> 9) 
> 
>    Another such change was in the treatment of AUTH_SYS, previously
>    described, inaccurately, as an "OPTIONAL means of authentication"
>    with the unfortunate use of the RFC2119 keyword obscuring the
>    negative consequences of the typical use of AUTH_SYS (in the clear,
>    without client-peer authentication) for security by enabling the
>    execution of unauthenticated requests.
> I think you are rewriting history here. The negative consequences were known at the time and accepted as a means to allow NFSv4 to be deployed in data centers “without” external connections.
> 
> I.e., it was a means to replace NFSv3 without adding the overhead of Kerberos.
> 
> 10) Appendix A seems to repeat large chunks of Section 1. Is this either going to be combined or is the Appendix going to be removed in the future?
> 
> I am fine with Appendix A and B being used to track consensus as the document matures, but I don’t believe they are needed in the final document.
> 
> 11) Going back to point 8 above, my motivation for consolidating the Security over the 3 versions was not to rewrite but to consolidate. I am of the firm belief that rewriting requires a new version of the protocol.
> 
> 
>> On Nov 16, 2023, at 8:28 AM, David Noveck <[e-mail]> wrote:
>> 
>> As I promised at IETF118, I have submitted the next draft of the security document.  I know lots of people were unable to attend, because the meeting was at 4AM Pacific among other reasons.  The slides I presented are available in the datatracker.  Let me know   if you have any questions.
>> 
>> I will be presenting regarding this document at the 11/21 interim.  The slides will be available soon.  I'd like to start discussing adoption of this document pretty soon so it would be helpful if people became more familiar with it.  The diff with -07 is straightforward, but given limited familiarity with that document it might not be all that helpful and an rfcdiff with rfc8881 will be both voluminous and useless.
>> 
>> Given that most people will not have a chance to read the full document, I am suggesting people familiarize themselves with Section 1  (about ten pages) and follow up with appendices A and B to help jumpstart our discussion of issues for which consensus needs to be ascertained.
>> 
>> The other focus of discussion at the 11/21 meeting will be the internationalization document but there will not ne a new document for the the 11/21 or 12/5v meetings.  I'm hoping for 12/19.  It might be helfl for people to look at the slides for this since there is a discussionfor the working group to make.
>> 
>> ---------- Forwarded message ---------
>> From: <[e-mail] <mailto:[e-mail]>>
>> Date: Tue, Nov 14, 2023 at 11:04 AM
>> Subject: New Version Notification for draft-dnoveck-nfsv4-security-07.txt
>> To: David Noveck <[e-mail] <mailto:[e-mail]>>
>> 
>> 
>> A new version of Internet-Draft draft-dnoveck-nfsv4-security-07.txt has been
>> successfully submitted by David Noveck and posted to the
>> IETF repository.
>> 
>> Name:     draft-dnoveck-nfsv4-security
>> Revision: 07
>> Title:    Security for the NFSv4 Protocols
>> Date:     2023-11-14
>> Group:    Individual Submission
>> Pages:    172
>> URL:      https://www.ietf.org/archive/id/draft-dnoveck-nfsv4-security-07.txt
>> Status:   https://datatracker.ietf.org/doc/draft-dnoveck-nfsv4-security/
>> HTML:     https://www.ietf.org/archive/id/draft-dnoveck-nfsv4-security-07.html
>> HTMLized: https://datatracker.ietf.org/doc/html/draft-dnoveck-nfsv4-security
>> Diff:     https://author-tools.ietf.org/iddiff?url2=draft-dnoveck-nfsv4-security-07
>> 
>> Abstract:
>> 
>>    This document describes the core security features of the NFSv4
>>    family of protocols, applying to all minor versions.  The discussion
>>    includes the use of security features provided by RPC on a per-
>>    connection basis.
>> 
>>    The current version of the document is intended, in large part, to
>>    result in working group discussion regarding existing NFSv4 security
>>    issues and to provide a framework for addressing these issues and
>>    obtaining working group consensus regarding necessary changes.
>> 
>>    When the resulting document is eventually published as an RFC, it
>>    will supersede the description of security appearing in existing
>>    minor version specification documents such as RFC 7530 and RFC 8881.
>> 
>> 
>> 
>> The IETF Secretariat
>> 
>> 
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nfsv4
>