Re: [secdir] [nfsv4] Secdir early review of draft-ietf-nfsv4-rpc-tls-03

Chuck Lever <chuck.lever@oracle.com> Wed, 23 October 2019 14:17 UTC

Return-Path: <chuck.lever@oracle.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B3C120255; Wed, 23 Oct 2019 07:17:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 cZwvpprHsA-3; Wed, 23 Oct 2019 07:17:10 -0700 (PDT)
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 0BB28120825; Wed, 23 Oct 2019 07:17:10 -0700 (PDT)
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 x9NE4SNm001134; Wed, 23 Oct 2019 14:17:07 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2019-08-05; bh=gcHNk9Wy8VB99rjG2+Ld26lTVlKXGu1tVaLTu5ckdRs=; b=B0gaSED8/DH3P2i8S9PjcXSq9gH1vsg2ssMyrPg0PzWpH1HCshUG3MfTdHLu3ddn8TBt feXktz6lQKq6LDuWwNFNkpLnwtNAwo5LdmnOOzeXmc27Za9lZbX2OuvlERGMTunn0Dfn 9dgNc8Xr9YvXe6d5Qdh5C7ILfCKelcgxH98fQT5ge+QlpzOjJUDwiaf/EFUBLn03lTDc ff315PrTXfYmjazKKG6n1fTyV/TDuLnuKLYxWqFokjfmM16Tn8+jlzj1TuY3u0sgGxUM ITattON/nSlhySGtNRMy8fjAmN3eA/f3qvSFFYQ9OvP03CXKWZgiouns6nCDBpdZf/RU nQ==
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 2vqu4qwfnq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Oct 2019 14:17:07 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9NEEZlW012348; Wed, 23 Oct 2019 14:17:06 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 2vt2hfdbyk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Oct 2019 14:17:05 +0000
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x9NEH5MI009941; Wed, 23 Oct 2019 14:17:05 GMT
Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 23 Oct 2019 07:17:04 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <CADaq8jfPjuMAm1r4zTG_30Qt7K8+Tp-qKPC01TGpK2-PRfDO0g@mail.gmail.com>
Date: Wed, 23 Oct 2019 10:17:03 -0400
Cc: Derrell Piper <ddp@electric-loft.org>, NFSv4 <nfsv4@ietf.org>, draft-ietf-nfsv4-rpc-tls.all@ietf.org, secdir@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <AD0D95A1-3933-4C62-B2A7-5DC3B6CCC9C5@oracle.com>
References: <157177407766.13058.11570408881931663610@ietfa.amsl.com> <5FBB7F0B-450A-417A-AD80-B1BB2BBDE1CC@oracle.com> <CADaq8jfPjuMAm1r4zTG_30Qt7K8+Tp-qKPC01TGpK2-PRfDO0g@mail.gmail.com>
To: David Noveck <davenoveck@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9419 signatures=668684
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910230143
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9419 signatures=668684
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-1908290000 definitions=main-1910230142
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/u0PtbX23N5lX-NJNZuDM-0pJQ1o>
Subject: Re: [secdir] [nfsv4] Secdir early review of draft-ietf-nfsv4-rpc-tls-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2019 14:17:12 -0000

> On Oct 23, 2019, at 6:24 AM, David Noveck <davenoveck@gmail.com>; wrote:
> 
> >> This is going to have to be much more detailed to convince me that it
> >> does either of these things for any implementation other than DESY or
> >> Hammerspace, and without other reference implemenatation in the BSDs or
> >> a least some flavors of Linux, you can't say this broadly interoperable
> >> either.
> 
> The document doesn't say that and there is no reason for it to do so.  The document's
> job is to defne a means by which better security could be achieved, when implementations
> are available.   If one waits for implementations to be done before approviing the
> specification, one is going to be waiting a long time, and NFS security will remain
> in its current unsatisfactory state indefinitely.
> 
> > We host two NFS interoperability events a year and can easily
> > demonstrate that we have achieved reasonable interop, if that
> > is required by the IESG.
> 
> I don't believe it is required for a Proposed Standard.   As I understand
> it, no actual implementations are required although the working group 
> has decided that prototyping of extensions is desirable.   Going
> beyond that point and requiring full implementations of protocols that
> have not been approved would be a mistake.
>  
> >> Distributed file systems are never easy, hence DCE/AFS, so
> >> granted it's not an easy problem, but this is not ready to advance on
> >> Standards Track, unless merely being interoperable with legacy code is
> >> all we aspire to, and I sincerely hope it's not.
> 
> I think it should be clear that Chuck's and Trond's aspirations go beyond this.
> If they didn't, there would have been no need to work on this document.
> The situation is similar for those who have worked on implementations.
> 
> If interoperation with legacy code is all one aspires to, one could implement
> the security specfified in rfcs 7530 and 5661.   These people and the working
> group clearly want something better.
> 
> That being said, the ability to work with legacy implementations is, in practical
> terms, a requirement of this enterprise.   There is no point in defining a secure 
> protocol island that cannot communicate with the implementations that exist today.
> 
> > > Perhaps this needle can be threaded and with appropriate configuration
> > > by enterprising people, TLS can be configured with DNSSEC and GSS-API in
> > > RPC and NFS and it will do something reasonable and secure, 
> 
> If I understand this correctly, Derrel is saying that, with the appropriate configuration
> which he mentions, you would have someting "reasonanble and secure"  :-)
> 
> That makes it hard for me to undertstand the negative tone of this review.   In any case,
> I think his specific suggestions should be followed up on to get the document ready for
> WGLC.

Agreed. The entire review has been filed as an issue against the document.

https://github.com/chucklever/i-d-rpc-tls/issues/3

I will work with Trond to address the specific issues Derrell has called out.


> > like to see at least some more comments from implementation experience
> > before I could recommend this advance.  
> 
> I think this is the wrong approach.   In my experience, it is very hard to get people to
> invest resources in implementing something that is not at least a Proposed Standand,
> and potentially open to  radical change before publication.  From a return-on-investment
> perspective, it doesn't make sense to invest in anytihing beyond limited prototyping.
> 
> The fact that so much expeimental implementation has already been done in this area
> illustrates the perceived urgency of the situation with regard to NFS security.   That
> work will continue in any case and implemtation experience will be available but I
> feel it would be a mistake to hold this document up waiting for it.   I think it would be
> best if the document is clarified and improved, go through WGLC, and be considered
> for adoption as a Proposed Standard.   That is a better way of getting resources
> allocated to the job of improving NFS security.
> 
> Of course, if anyone has an appoach to improving NFS security, that is better than
> that in rpc-tls, the working group would intestested in earing about it.

I also welcome hearing new ideas in this area.


--
Chuck Lever