IETF Logo Mail Archive

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

Chuck Lever <chuck.lever@oracle.com> Wed, 24 April 2019 13: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 67336120167 for <nfsv4@ietfa.amsl.com>; Wed, 24 Apr 2019 06:53:37 -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 9brvciopLCJU for <nfsv4@ietfa.amsl.com>; Wed, 24 Apr 2019 06:53:35 -0700 (PDT)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 E53E2120020 for <nfsv4@ietf.org>; Wed, 24 Apr 2019 06:53:34 -0700 (PDT)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x3ODd9Jk020572; Wed, 24 Apr 2019 13:53:32 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=Q+8+Vy0/+xzlqolpAYWNNZl4GmAVHRHwq29HjxCyjn8=; b=hmywdhGlp2cn6jb0Kme3s3BCPPqXxYXz/PIsV95CzpSSXaEoNqvpFZ50Fb8y9DFzYoCh 6Oxuz8Zcc/X38/1nLm9d3hxa9+RJ8JCN6nd6n1QaafimIOQ1BrMl6y+cg55r8mDRzXeJ GFvRvm9Qdzl1jQ7wgPSvhH7WOQeVPtRbB+yhpOFrLKDzKriTf4hwWMufI7WuHmVAM9gG 8GI8Z7kowYkp13Xbt72ItZn1KnEEp3NE70zWQ6GmBEYOJwfkk5LT1i/m7owPMzshLSGV rxdJP3sncNPOu5LGUYFp4+I3o2bYOqmVPx0+v6jFGLRGIOx2SmNoFBbCBwDzdthUyPI9 oQ==
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 2rytut2h7u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Apr 2019 13:53:31 +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 x3ODoSvU147299; Wed, 24 Apr 2019 13:51:31 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3020.oracle.com with ESMTP id 2s0fv3k3hw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Apr 2019 13:51:31 +0000
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x3ODpT4l028898; Wed, 24 Apr 2019 13:51:29 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 06:51:29 -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: <20190422154814.GH72232@kduck.mit.edu>
Date: Wed, 24 Apr 2019 09:51:25 -0400
Cc: David Noveck <davenoveck@gmail.com>, NFSv4 <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2664782D-629E-4AA7-991D-76BAC465686D@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>
To: Benjamin Kaduk <kaduk@mit.edu>
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=755 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904240109
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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=776 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904240109
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/-LH4ec95B2XYuUS9MP8UDXSWFRs>
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 13:53:38 -0000


> 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

v2.23.0 | Report a Bug | By Email