Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt

Chuck Lever <chuck.lever@oracle.com> Wed, 24 April 2019 14:56 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 3DB8D1201C2 for <nfsv4@ietfa.amsl.com>; Wed, 24 Apr 2019 07:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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, 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 25su5Fj5P-zJ for <nfsv4@ietfa.amsl.com>; Wed, 24 Apr 2019 07:55:58 -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 1695E1201A8 for <nfsv4@ietf.org>; Wed, 24 Apr 2019 07:55:58 -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 x3OEsQR1109697; Wed, 24 Apr 2019 14:55:56 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-2018-07-02; bh=vTm6nAl5jAdzFOsQX52BKT2EJMFKgjjjM2GbCVrKtbM=; b=4X2Cwe/feJj6osA5OEep6AIA9j3PrZMJdL/IP1MiAjWR5Sy7v0z+RFeGHAbZsylGCtU5 RCrlhQTRK40zdYZG7pjTWEXAMMOXowZd5RUsTU5Hz7vaEKOmQTijJ8T2EHiJ5chsYfEU Z7nrX4wLQDzq0CvE2CYsPKntvv+z4aQTvLTxnhCJQWqrn03zNlvn92Ea+oSGA022iJ6P C510LdlTiJ+wtYtUC29h0mTPK5Hc+tor1Hft9AQ1MJf7TiwFlnBfkenYv5wyTrvLOyb5 fv2tq/dt0v45ItKoIpht+aXayumZkh4LmPyunx27kP09zia93UunnG5ck14imE3pTMGH eA==
Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 2ryv2qav0x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Apr 2019 14:55:56 +0000
Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x3OEsjpI056887; Wed, 24 Apr 2019 14:55:56 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 2s0dwevxv9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Apr 2019 14:55:55 +0000
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x3OEtsMJ010977; Wed, 24 Apr 2019 14:55:54 GMT
Received: from anon-dhcp-171.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Apr 2019 07:55:54 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <CADaq8jciwJanPJ09p95c5WR3QsBcmH6Z6Px4QbkG9_NTfUoJEA@mail.gmail.com>
Date: Wed, 24 Apr 2019 10:55:50 -0400
Cc: Benjamin Kaduk <kaduk@mit.edu>, NFSv4 <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <66F78DBB-5D22-4FC2-A3C3-E69DBF87E4DB@oracle.com>
References: <155535049832.10773.1565621811584007627@ietfa.amsl.com> <CADaq8jcCB9g9v=h4iXu1f6=cAsU7wMdmfh31gCQKvEFw2eG=rA@mail.gmail.com> <804CB622-D696-4FAA-8040-993CB4029508@oracle.com> <20190422154814.GH72232@kduck.mit.edu> <2664782D-629E-4AA7-991D-76BAC465686D@oracle.com> <CADaq8jciwJanPJ09p95c5WR3QsBcmH6Z6Px4QbkG9_NTfUoJEA@mail.gmail.com>
To: David Noveck <davenoveck@gmail.com>
X-Mailer: Apple Mail (2.3445.104.8)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9236 signatures=668685
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-1810050000 definitions=main-1904240116
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9236 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-1904240116
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/lLQJZsCrPjz3UN5b1XmWaBG2WiI>
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt
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: Wed, 24 Apr 2019 14:56:00 -0000


> On Apr 24, 2019, at 10:48 AM, David Noveck <davenoveck@gmail.com> wrote:
> 
> >> The summary of the reasoning for the use of this term is basically that it
> >> does not provide protection in the face of an *active* attacker (that can
> >> force downgrade to the previous/insecure technology), but does protect
> >> against passive observation.
> 
> > Indeed, this looks directly on point.
> 
> It does but having read this document and considering Ben's statement
> that "it :does not provide protection in the face of an 'active' attacker, I'm
> wondering if the 'opportunistic" nature of this approach should be mentioned
> quite as prominently as it is in -01.
> 
> For example, Tigran is basically asking for a description of how this mechanism
> would be used non-opprtunistically and it seems clear to me that eventually
> there will be a need such deployments.   If and when this mechanism is widely
> deployed the failure to establish an encrypted connection is more likely to be
> due to an active attacker rather than a non-rpc-tls-supporting server.
> 
> It is not clear to me why, in that event the client should behave passively in the 
> face of an active attack.   As i understand it, an eventual Security Consideraations
> is going to have to consider all possible attacks and we want to avoid a situation
> in which an accurate Security Consideration would need to say, in essence, "omigod,  
> it's hopeless". :-(

The opportunistic approach is meant to be a step up, not
a full solution. We are bridging a gap here, and I think
we all expect/hope to have deeper solutions in the future.

For instance, we could define an RPC on QUIC transport
type that requires host authentication and encryption from
the get-go.


The current rpc-tls document now RECOMMENDS that an RPC
client's security policy insists on the use of TLS (ie,
that they will immediately close a connection to a server
that does not support TLS). That is a reasonable way to
address active attackers while there is still a large fleet
of RPC implementations without TLS support.

We could also strongly RECOMMEND the use of authentication.


> On Wed, Apr 24, 2019 at 9:53 AM Chuck Lever <chuck.lever@oracle.com> wrote:
> 
> 
> > On Apr 22, 2019, at 11:48 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> > 
> > On Tue, Apr 16, 2019 at 01:11:54PM -0400, Chuck Lever wrote:
> >> 
> >>> On Apr 16, 2019, at 1:09 PM, David Noveck <davenoveck@gmail.com> wrote:
> >>> 
> >>> I'm confused by the addition of the word "opportunistically" in the abstract.   This document defines an important way of providing security to RPC-based protocols such as NFSv4, so as to deal with the very real security problemms that these protocols have.    While these facilities can only be used when both client and the server provides support, I don't think that fact alone make the use of these facilties "opportunistic".    What exactlty is this word intended to imply?
> >> 
> >> "Opportunistic" is a term of art. See:
> >> 
> >> https://en.wikipedia.org/wiki/Opportunistic_TLS
> > 
> > RFC 7435 is also a good reference for this topic (and one that has IETF
> > consensus, FWIW).
> > 
> > The summary of the reasoning for the use of this term is basically that it
> > does not provide protection in the face of an *active* attacker (that can
> > force downgrade to the previous/insecure technology), but does protect
> > against passive observation.
> 
> Indeed, this looks directly on point.
> 
> --
> Chuck Lever
> 
> 
> 

--
Chuck Lever