Re: [nfsv4] Thinking about an RFC5661bis.

Chuck Lever <chuck.lever@oracle.com> Fri, 01 March 2019 15:53 UTC

Return-Path: <chuck.lever@oracle.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CD4127287 for <nfsv4@ietfa.amsl.com>; Fri, 1 Mar 2019 07:53:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNEvXX2-jEe0 for <nfsv4@ietfa.amsl.com>; Fri, 1 Mar 2019 07:53:20 -0800 (PST)
Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FE21124C04 for <nfsv4@ietf.org>; Fri, 1 Mar 2019 07:53:19 -0800 (PST)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x21FnIUd158595; Fri, 1 Mar 2019 15:53:17 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2018-07-02; bh=7NM6+4iw8pz2WghPl3qsrmaisDcqoanb4/T+uYsJhu4=; b=vcBTEFtJkBw8fPA3nLqnb9PFYDCJ4If5dzkBdcgL5O6yTyJMGVHZ3mm69z6r7pR5UFuW Z2BPtZcSOJN9eSuElEuvKzSekKce76PYCh/SoJdU3umlCmyTt2V1Biqb5aGiWU84IDwn +O8TphkzMlLxWXGt3qj/HApCZNV5ipMWk011tnCiUKrnhepkk4Qq7Ofc+bfKxhG/G2Ri O2mQZAJUfhzGACXgPS7owYdFXqOPbAHb9+Rp48DfIpRkFLSJdazM1WKW/t4Ik7VGBC/F oNwIIyTtYCd82q/DXQW6eBdINqH3jjd6Blqhfu9qdaAQ3n23x+PEw/2TLx81r3O1IEG2 Sw==
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2qtxts80y1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 01 Mar 2019 15:53:17 +0000
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x21FrGdb001550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 1 Mar 2019 15:53:16 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x21FrFB2020974; Fri, 1 Mar 2019 15:53:15 GMT
Received: from anon-dhcp-171.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Mar 2019 07:53:15 -0800
From: Chuck Lever <chuck.lever@oracle.com>
Message-Id: <70609508-A732-4729-AE35-18DBC65CA9D0@oracle.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_073620CB-DDCB-4430-8C8E-FC6874A02C3E"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Fri, 01 Mar 2019 10:53:13 -0500
In-Reply-To: <CADaq8jf0WKXDcE6NbFnymnVRXpmR1a7pZ6THSfzoG7hE2qq+vg@mail.gmail.com>
Cc: NFSv4 <nfsv4@ietf.org>
To: David Noveck <davenoveck@gmail.com>
References: <CADaq8je5pzF7m+4oVCNfSeeBDQ98kBwAdCN_o1hBrfDob=SBaA@mail.gmail.com> <A37CB4B9-F445-4A9A-9347-DA4976F053E9@oracle.com> <CADaq8jf0WKXDcE6NbFnymnVRXpmR1a7pZ6THSfzoG7hE2qq+vg@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9181 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903010111
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/kj_pDgURsbP-qxwLWNngKZA2isg>
Subject: Re: [nfsv4] Thinking about an RFC5661bis.
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2019 15:53:24 -0000

> On Feb 28, 2019, at 4:15 PM, David Noveck <davenoveck@gmail.com> 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 <chuck.lever@oracle.com <mailto:chuck.lever@oracle.com>> wrote:
> 
> 
> > On Feb 28, 2019, at 9:37 AM, David Noveck <davenoveck@gmail.com <mailto:davenoveck@gmail.com>> 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
> > nfsv4@ietf.org <mailto:nfsv4@ietf.org>
> > https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>
> 
> --
> Chuck Lever
> 
> 
> 

--
Chuck Lever