IETF Logo Mail Archive

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

Benjamin Kaduk <kaduk@mit.edu> Mon, 22 April 2019 15:48 UTC

Return-Path: <kaduk@mit.edu>
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 C69BD120117 for <nfsv4@ietfa.amsl.com>; Mon, 22 Apr 2019 08:48:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 62t-fZC7KtUI for <nfsv4@ietfa.amsl.com>; Mon, 22 Apr 2019 08:48:19 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 A3F32120113 for <nfsv4@ietf.org>; Mon, 22 Apr 2019 08:48:19 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3MFmFbA024172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Apr 2019 11:48:17 -0400
Date: Mon, 22 Apr 2019 10:48:15 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: David Noveck <davenoveck@gmail.com>, NFSv4 <nfsv4@ietf.org>
Message-ID: <20190422154814.GH72232@kduck.mit.edu>
References: <155535049832.10773.1565621811584007627@ietfa.amsl.com> <CADaq8jcCB9g9v=h4iXu1f6=cAsU7wMdmfh31gCQKvEFw2eG=rA@mail.gmail.com> <804CB622-D696-4FAA-8040-993CB4029508@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <804CB622-D696-4FAA-8040-993CB4029508@oracle.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/kYbbTIwg5tg5YmedJ5QUf1X3DIo>
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: Mon, 22 Apr 2019 15:48:22 -0000

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.

-Ben

v2.23.0 | Report a Bug | By Email