Subject: [nfsv4] Thinking about an RFC5661bis.

From: David Noveck <[email-masked]>
Date: Thu, 28 Feb 2019 09:37:28 -0500

A number of review comments regarding draft-ietf-nfsv4-mv1-msns-update have
raised the issue of a possible bis document for NFSv4.1.   These range all
the way from those assuming that mv1-msns-update is a stepping stone on the
way to the bis document, which I agree with, to those that are asking us to
explain why we haven't already done that.   I will have to respond to that
latter comment, but I'm hoping to delay that until after the telechat.

In any case, it seems that we have accumulated enough changes to and issues
with RFC5661 that we need to start thinking about producing a bis
document.  These include:

   - All the material in mv1-msns-update modiying Section 11 and other
   parts of RFC5661.
   - The need to replace Section 14 (Internationalization) of RFC5661 with
   something like Section 12 of RFC7530.
   - Revising Section 2.4 of RFC5661 so it no longer contradicts RFC8178.
   - Updating Section 12 of RFC5661 to be in line with RFC8434.
   - Reflecting all of the verified RFC5661 erratta.  There were seventeen
   last time I checked.  There may also be things discussed as possible
   erratta, that were considered to big for the erratta process, but could be
   done as part of a bis document.

If anyone knows of other material that should go into such a document, or
has concerns about the working group starting on this, now is a good time
to raise your issue on the list.

The joker in this particular pack is the Security Considerations section.
 While we have to address the Security Directorate's notorious, "collection
of random observations" comment, I think we need to do so in a way that is
compatible with the expected draft-nfsv4-rpc-tls (hint, hint), even though
we want to be able to publish without waiting for rpc-tls to become an
RFC.  While draft-cel-rpc-tls-02 states that use of AUTH_SYS is currently
"discouraged" and that is a fair summary, I don't think RF5661 ever does
that explicitly.   It may be that we will need to explicitly discourage use
of AUTH_SYS  in an rfc5661bis (without, I hope, going so far as "SHOULD
NOT").  I think we need to frame the discussion around the three big
security deficits present using AUTH_SYS in the clear (exposing your data
to prying eves, using  data that has traversed the newtwork without
integrity protection, acting on unauthenticated requests) and not on the
use of AUTH_SYS per se.  If we do this, we can publish and implement
rpc-tls without needng to further deal with the security considerations
section of the NFSv4.1 spec.

---

From: Tom Haynes <[email-masked]>
Date: Thu, 28 Feb 2019 09:06:31 -0800

While not volunteering, I do have a git repository for this work already started - last entry was 4-5 years ago. 

I believe it also had some of the errata applied.

And again, the reason why we never started is because it is a lot of work - both to edit and review.

Hadn’t we discussed breaking it down into more manageable chunks? Many smaller documents (like we did for versioning) and then one which stitched them together?

---

From: Chuck Lever <[email-masked]>
Date: Thu, 28 Feb 2019 12:09:42 -0500

> On Feb 28, 2019, at 9:37 AM, David Noveck <[email-masked]> wrote:
> 
> A number of review comments regarding draft-ietf-nfsv4-mv1-msns-update have raised the issue of a possible bis document for NFSv4.1.   These range all the way from those assuming that mv1-msns-update is a stepping stone on the way to the bis document, which I agree with, to those that are asking us to explain why we haven't already done that..   I will have to respond to that latter comment, but I'm hoping to delay that until after the telechat.
> 
> In any case, it seems that we have accumulated enough changes to and issues with RFC5661 that we need to start thinking about producing a bis document.  These include:
> 	• All the material in mv1-msns-update modiying Section 11 and other parts of RFC5661.
> 	• The need to replace Section 14 (Internationalization) of RFC5661 with something like Section 12 of RFC7530.
> 	• Revising Section 2.4 of RFC5661 so it no longer contradicts RFC8178.
> 	• Updating Section 12 of RFC5661 to be in line with RFC8434.
> 	• Reflecting all of the verified RFC5661 erratta.  There were seventeen last time I checked.  There may also be things discussed as possible erratta, that were considered to big for the erratta process, but could be done as part of a bis document.
> If anyone knows of other material that should go into such a document, or has concerns about the working group starting on this, now is a good time to raise your issue on the list.

I agree that a bis would be very helpful for potential
implementers, and there is enough backlog to warrant
the effort. Before proceeding we need to reach a
consensus that our current charter supports this work.

> The joker in this particular pack is the Security Considerations section.   While we have to address the Security Directorate's notorious, "collection of random observations" comment, I think we need to do so in a way that is compatible with the expected draft-nfsv4-rpc-tls (hint, hint), even though we want to be able to publish without waiting for rpc-tls to become an RFC.  While draft-cel-rpc-tls-02 states that use of AUTH_SYS is currently "discouraged" and that is a fair summary, I don't think RF5661 ever does that explicitly.   It may be that we will need to explicitly discourage use of AUTH_SYS  in an rfc5661bis (without, I hope, going so far as "SHOULD NOT").  I think we need to frame the discussion around the three big security deficits present using AUTH_SYS in the clear (exposing your data to prying eves, using  data that has traversed the newtwork without integrity protection, acting on unauthenticated requests) and not on the use of AUTH_SYS per se.  If we do this, we can publish and implement rpc-tls without needng to further deal with the security considerations section of the NFSv4.1 spec.
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Thu, 28 Feb 2019 15:50:44 -0500

> I believe it also had some of the errata applied.

This could be helpful if there is an .xml file that could be diffed against
the .xml for the existing RFC5661.

> And again, the reason why we never started is because it is a lot of work
- both to edit and review.

Everything we do is work, but I don't think it is as much work as you think
given the work already done in the documents published so far and soon to
be published.

> Hadn’t we discussed breaking it down into more manageable chunks?

We have have had such discussions, but we never started seriously going
down that road.  That's probably because that is also a lot of work.

> Many smaller documents (like we did for versioning)

Versioning was a special case common to all NFSv4 versions.

> and then one which stitched them together?

I don't hear anyone volunteering to do that either.

If you compare the work to update RFC5666 to reflect existing erratta and
the RFCs which update it with the work to convert NFSv4.1 to an entirely
new documentatIion philosoply, the latter is almost certain to be more
work.   Also, readers are used to the current philosophy and it would take
effort to manage the transition.

On Thu, Feb 28, 2019 at 12:06 PM Tom Haynes <[email-masked]> wrote:

> Hadn’t we discussed breaking it down into more manageable chunks? Many
> smaller documents (like we did for versioning) and then one which stitched
> them together?

---

From: Tom Haynes <[email-masked]>
Date: Thu, 28 Feb 2019 12:58:37 -0800

> On Feb 28, 2019, at 12:50 PM, David Noveck <[email-masked]> wrote:
> 
> This could be helpful if there is an .xml file that could be diffed against the .xml for the existing RFC5661.   

Yes, there is...

orbie:5661bis loghyr$ git log --oneline 
56b2b56 Merge branch 'master' of github.com:loghyr/5661bis
facd52c Typo
98e73e5 Update instructions for getting xml2rfc
a54892e another typo fix: client vs server
a1c884f typo fix: notify_device_type4
2cf1b26 Get testx working
b4a0b2c Aargh, make the hurting stop... Got to work with newer xml2rfc
758d013 Typos
b28e561 Merge branch 'master' of github.com:loghyr/5661bis
e2402b0 Update address
cee7f7a Fix up NFS4ERR_DQUOT's value
8d7292e Merge branch 'master' of github.com:loghyr/5661bis
0fc3ee5 LOCKT can expire
9f736f7 Apply Asmita's errata
798cac6 Andy proposed some clarity on name lookup security
4ff393c Merge branch 'master' of github.com:loghyr/5661bis
710d3e8 Fix spaces in Makefile
c5ec1ac Fix ipr
f5028a8 Pull out xml2rfc as this is not the source control for it.
e578199 Marc Eshel\'s Errata 3226
91b2d4e Make idnit friendly
9078e8e Fix up xml2rfc
ef1ced3 Fix some formatting
62774b0 ERRATA: layoutget serialization
e364335 Small typos
8741ca6 Applied David Black's errata
e797eca Fix vspace issue
a8d2b06 Fix up testx
e302743 Tighten up the LAYOUTCOMMIT errata
6faa82b Fix typo
bc9a378 Added Implications of LAYOUTCOMMIT on file layouts
8964638 Take care of the errata
68ad4d6 More documentation on the documentation
bdd32f5 Archived original rfc5661.txt and the first official copy of the bis
a963a32 Start tracking changes
740a42b Fix Makefile copy error
284f6b5 Fix Makefile copy error
0b27cec Wrong Makefile
824c2c6 Create project, based off of fresh pull of RFC 5661

You can grab a copy here:

git clone [email-masked]:loghyr/5661bis.git

Also, not sure that the XML for RFC5661 is available.

One of the things I have been doing is grabbing the last XML copy of a document before the editors are done. I.e., they make straight changes to the XML before publishing.

> Everything we do is work, but I don't think it is as much work as you think given the work already done in the documents published so far and soon to be published. 
> 

We said that exact same thing about RFC3530bis.

---

From: David Noveck <[email-masked]>
Date: Thu, 28 Feb 2019 16:15:59 -0500

>Before proceeding we need to reach a

Let's start with what the charter says:

To maintain NFS Version 4's utility and currency, the NFSv4 working
group is chartered to maintain the existing NFSv4.0, NFSv4.1, and
NFSv4.2 protocols and specifications of related ONC components, such as
those defining RPC, XDR, and RPCSECGSS.

It is true that bis documents are not mentioned explicitly but I would say
that if a group is charged with maintaining the specification for a
protocol, it is really stretching things to argue that production of bis
documents is somehow out of the scope of the group's charter.

Of course, if there is someone who believes that this would be outside the
group's charter, that issue can be raised on the mailing list.

With regard to the process of reaching a consensus *before  *proceding,
let's proceed as follows:  When there is a  proposal to adopt a
draft-nfsv4-rfc5661bis-00 as a working group document, this issue can be
discussed as part of the decission on working group adoption.   The time
allocated for the discussion should be long enough so that there i s
adequate time to resolves any doubts about the suitability of the group
doing this work, given its current carter.

On Thu, Feb 28, 2019 at 12:09 PM Chuck Lever <[email-masked]> wrote:

> > A number of review comments regarding draft-ietf-nfsv4-mv1-msns-update
> have raised the issue of a possible bis document for NFSv4.1.   These range
> all the way from those assuming that mv1-msns-update is a stepping stone on
> the way to the bis document, which I agree with, to those that are asking
> us to explain why we haven't already done that..   I will have to respond
> to that latter comment, but I'm hoping to delay that until after the
> telechat.
> >
> > In any case, it seems that we have accumulated enough changes to and
> issues with RFC5661 that we need to start thinking about producing a bis
> document.  These include:
> >       • The need to replace Section 14 (Internationalization) of RFC5661
> with something like Section 12 of RFC7530.
> >       • Reflecting all of the verified RFC5661 erratta.  There were
> seventeen last time I checked.  There may also be things discussed as
> possible erratta, that were considered to big for the erratta process, but
> could be done as part of a bis document.
> > If anyone knows of other material that should go into such a document,
> or has concerns about the working group starting on this, now is a good
> time to raise your issue on the list.
>
> > The joker in this particular pack is the Security Considerations
> section.   While we have to address the Security Directorate's notorious,
> "collection of random observations" comment, I think we need to do so in a
> way that is compatible with the expected draft-nfsv4-rpc-tls (hint, hint),
> even though we want to be able to publish without waiting for rpc-tls to
> become an RFC.  While draft-cel-rpc-tls-02 states that use of AUTH_SYS is
> currently "discouraged" and that is a fair summary, I don't think RF5661
> ever does that explicitly.   It may be that we will need to explicitly
> discourage use of AUTH_SYS  in an rfc5661bis (without, I hope, going so far
> as "SHOULD NOT").  I think we need to frame the discussion around the three
> big security deficits present using AUTH_SYS in the clear (exposing your
> data to prying eves, using  data that has traversed the newtwork without

---

From: David Noveck <[email-masked]>
Date: Thu, 28 Feb 2019 16:27:55 -0500

> git clone [email-masked]:loghyr/5661bis.git

great.  Thanks.

> Also, not sure that the XML for RFC5661 is available.

i have a file i got from the RFc editor which i was told ws the XML  for
RFc5661.   I've never found inaccuracies but I have never gone through the
veification process of producing the RFC and diffing against the published
rfc.

> One of the things I have been doing is grabbing the last XML copy of a
document before the editors are
> done. I.e., they make straight changes to the XML before publishing.

>> Everything we do is work, but I don't think it is as much work as you
think given the work already done in the documents published so far and
soon to be published.

> We said that exact same thing about RFC3530bis.

Good point.   Before starting on that, I could hear the phrase "dotting the
i's"' and not worry about Turkish.  However, despite the fact that we found
some troublesome issues that we had to address, i'm glad we did it and
don't regret we tackled the issues we found.   I don't think we'll find
comparable issues with RFC5661, but feel that if we do it is better to get
them addressed now and not let them fester.

ReplyReply allForward

On Thu, Feb 28, 2019 at 3:58 PM Tom Haynes <[email-masked]> wrote:

> > > While not volunteering, I do have a git repository for this work
> already started - last entry was 4-5 years ago.
> >
> > This could be helpful if there is an .xml file that could be diffed
> against the .xml for the existing RFC5661.
>
> Yes, there is...
>
> One of the things I have been doing is grabbing the last XML copy of a
> document before the editors are done. I.e., they make straight changes to
> the XML before publishing.
>
>
> >
> > Everything we do is work, but I don't think it is as much work as you
> think given the work already done in the documents published so far and
> soon to be published.
> >
>
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 28 Feb 2019 18:59:57 -0600

> latter comment, but I'm hoping to delay that until after the telechat.

Thanks for starting this thread.  Since I am reading already...

> with RFC5661 that we need to start thinking about producing a bis
[...]
> NOT").  I think we need to frame the discussion around the three big

It will be interesting to see what the text around that looks like --
starting from just the Internet threat model of RFC 3552 it's hard for me
to imagine that behavior like AUTH_SYS would be anything other than "SHOULD
NOT".  But please to not take this as trying to discourage you from trying,
and rather as a chance to educate the security folk.

> use of AUTH_SYS per se.  If we do this, we can publish and implement

Dividing things into risks and countermeasures is usually a good strategy,
rather than focusing specifically on mechanisms, yes...

> section of the NFSv4.1 spec.

...since once you start talking about *properties* of the protocol
components, it's easier to slot different backends into place, provided
that they provide the same (or better) properties.

-Ben