Subject: Re: [nfsv4] Thinking about an RFC5661bis.

From: David Noveck <[email-masked]>
Date: Fri, 1 Mar 2019 07:17:09 -0500

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

> It will be interesting to see what the text around that looks like --
> starting from just the Internet threat model of RFC 3552

I think I'll have to look at that document intensely.  Thanks for pointing
me to it.

> it's hard for me
> to imagine that behavior like AUTH_SYS would be anything other than
"SHOULD
> NOT".

You're right it does seem hard to imagine.  However, in this case
imagination
is not required.  You just have to look at what happened:

   - On 9/19/2008, this working group requested publication of
   draft-ietf-nfsv4-minorversion1-26.txt which presented use of AUTH_SYS as
   optional/allowed.
   - On 12/19/2008, the IESG approved publication of
   draft-ietf-nfsv4minorversion1-29.txt as a Proposed Standard, even though
   that document still  presented use of AUTH_SYS as optional/allowed.
   - On 1/14/2010, RFC5661 was published as a Proposed Standard with the
   treatment of AUTH_SYS intact.
   - Since then, implementations have been developed and deployed which
   used AUTH_SYS, including many deployments in environments in which use of
   AUTH_SYS could reasonably be felt to be imprudent, leading to a troubling
   security situation for NFSv4.1.

People may well have different views as to how to assign the
responsibility/blame for this situation and there is no real point in
trying to  do so.  Clearly, the authors, the other members of the working
group, and the IESG all had some role.

The descision not to say "SHOULD NOT" with regard to NFSv4.1 has already
been made and I don't see how it can be changed even one thinks that the
working roup was wrong to write RFC5661 that way or that the IESG was wrong
to approve publication.   A Security Considerations section can still draw
attention to the problems that use of AUTH_SYS can give rise to, and the
steps necessary to mitigate them, where possible.

> But please to not take this as trying to discourage you from trying,
> and rather as a chance to educate the security folk.

I'm not sure what education I can provide.   I'm sure people will want to
know how this happened but all I can provide are guesses.   I think I can
learn stuff about security from the exercise.

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

> Dividing things into risks and countermeasures is usually a good strategy,

Good point.

> rather than focusing specifically on mechanisms, yes...

We have had a number of situations in which some particular mechanism was
felt to be salvific, but turned out not to be so :-(

>> rpc-tls without needng to further deal with the security considerations
>> 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.

True.  The conclusion I draw is that rpc-tls will have to be fairly far
along
in its development when the bis document is considered, even if it doesn't
have to be published first.    If it seems that equal (or better) security
is clearly
on the horizon, I think the security people will be OK with a treatment
that
does not stigmtize AUTH_SYS per se, but instead draws attention to the
exposure of data in transit, the lack of integrity protection, and the
execution
of unautheticated requests.

Given the need for rpc-tls to be fairly far along, the delays that Tom is
worried
about do not seem to be all that troubling, since there is really no rush
to get
5661bis out, even if we think it is needed/desirable.

On Thu, Feb 28, 2019 at 8:00 PM Benjamin Kaduk <[email-masked]> wrote:

> On Thu, Feb 28, 2019 at 09:37:28AM -0500, David Noveck 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.
>
> Thanks for starting this thread.  Since I am reading already...
>
> > 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 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
>
> 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.
>
> > 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
>
> Dividing things into risks and countermeasures is usually a good strategy,
> rather than focusing specifically on mechanisms, yes...
>
> > rpc-tls without needng to further deal with the security considerations
> > 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
>

---

From: Chuck Lever <[email-masked]>
Date: Fri, 1 Mar 2019 10:53:13 -0500

> On Feb 28, 2019, at 4:15 PM, David Noveck <[email-masked]> wrote:
> 
> >Before proceeding we need to reach a
> > consensus that our current charter supports this work.  
> 
> 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.

Right, I'm simply raising the question explicitly to invite that conversation sooner rather than too late.

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

Your suggested timing seems sensible to me.

> On Thu, Feb 28, 2019 at 12:09 PM Chuck Lever <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On Feb 28, 2019, at 9:37 AM, David Noveck <[email-masked] <mailto:[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] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>
> 
> --
> Chuck Lever
> 
> 
> 

--
Chuck Lever

---

From: [email-masked] (J. Bruce Fields)
Date: Fri, 1 Mar 2019 13:17:52 -0500

On Thu, Feb 28, 2019 at 09:37:28AM -0500, David Noveck 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
> In any case, it seems that we have accumulated enough changes to and issues
>    - 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
 
I believe there were also just a ton of smaller typos and stuff.  If we
do this, then somebody should also go through Tom's 3530bis git repo:

	https://github.com/loghyr/3530bis

and check that everything applicable there also makes it to 5661bis.

--b.

---

From: David Noveck <[email-masked]>
Date: Fri, 1 Mar 2019 15:15:38 -0500

> and check that everything applicable there also makes it to 5661bis.

The simplest way to do this is to start the bis document based on the
work that has already been done, as long as Tom is Ok with it being
used in that way.  We would still have to check the existing erratta list
for
things that did not make it into Tom's repo.

---

From: Tom Haynes <[email-masked]>
Date: Fri, 1 Mar 2019 13:42:44 -0800

> On Mar 1, 2019, at 12:15 PM, David Noveck <[email-masked]> wrote:
> 
> >    https://github.com/loghyr/3530bis <https://github.com/loghyr/3530bis>
> 
> used in that way.  We would still have to check the existing erratta list for

Yes, the current bis document belongs to the WG and not me.

I started this document when I was doing RFC3530bis as a means to fix
issues I found in RFC5661 (and had to also resolve in RFC3530bis).
As I applied errata from either RFC3530 or RFC5661, I also applied
it to RFC5661bis.

I think I had also just gone through the effort to convert from the
format used for the files to the setup I used to track the chapters.

And when I determined never to do such a large BIS again, I probably
abandoned making changes to the git repo. In any event, I found
having the RFC5661bis to be useful for reference.

So feel free to base the changes off of it!

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 1 Mar 2019 16:04:53 -0600

> I think I'll have to look at that document intensely.  Thanks for pointing

You're quite welcome!  I am so familiar with it that I end up assuming
everyone else knows about it, which is of course not the case...

> steps necessary to mitigate them, where possible.

Well, we did publish some new IETF-consensus document in the intervening
ten (ish) years that could be taken to shift the balance on what behaviors
we do and do not tolerate in standards-track documents, things like BCP 188
("Pervasive Monitoring is an Attack") and BCP 195 ("Recommendations for
Secure use of TLS and DTLS").  So it's not really clear to me that we must
be strict slaves to precedent (but we do need to acknowledge existing
deployments in some fashion, of course).

> of unautheticated requests.

Speaking just for myself, documents that accurately describe the current
properties and have a path to better properties are generally tolerable,
and I am pragmatic enough to not hold things up for ideological purity.

> 5661bis out, even if we think it is needed/desirable.

That said, I'm not sure whether I want to hope that I am or am not still
on the IESG when the purported bis document shows up there :)

-Ben