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

Chuck Lever <> Wed, 24 April 2019 20:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E7F41203F5 for <>; Wed, 24 Apr 2019 13:48:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1WoYoOD7Nwk3 for <>; Wed, 24 Apr 2019 13:48:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8FEF1120092 for <>; Wed, 24 Apr 2019 13:48:25 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x3OKdXIi006662; Wed, 24 Apr 2019 20:48:23 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=ltzC49socTHnjBC5w3gzb18OKLRXd7cgdjc/Z9GFmGs=; b=ixaApycfNtXa4SR7bHqgHCZGaR0AQGTyWm8a2SjeB89UlzgAO70rCju7lJZl1AkMZmsh LimUXV8RRHqslnSJEyz7LCRg6eaMgN+1sMq65j3X5bF0kjih/c2QzuFs/AMN1znXNYee 0xtgEfiIPHzns6KVtFq8wcQWYjy/8zVogPZ0pm1uHIuwwNvL4U9EZPgYhcwAA/CZxSGl MFbIjmKj2CdX8/MPKFVJ3wRROSvA/+9nOQMBGHVliK88gG8qH7KZkGOeZZtUrX+kAffr Gr4uy9IU6tTRJm55un3CkXmdHLmKUXc3AU5XzJnnRm2xe4Sy5Fd5sfpEmtkPDqmlpqwF 4w==
Received: from ( []) by with ESMTP id 2ryv2qcp2n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Apr 2019 20:48:23 +0000
Received: from pps.filterd ( []) by ( with SMTP id x3OKmA4x166911; Wed, 24 Apr 2019 20:48:23 GMT
Received: from ( []) by with ESMTP id 2ryrhsv02p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Apr 2019 20:48:23 +0000
Received: from ( []) by (8.14.4/8.13.8) with ESMTP id x3OKmMcQ009021; Wed, 24 Apr 2019 20:48:22 GMT
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Apr 2019 13:48:22 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Chuck Lever <>
In-Reply-To: <>
Date: Wed, 24 Apr 2019 16:48:21 -0400
Cc: NFSv4 <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: David Noveck <>
X-Mailer: Apple Mail (2.3445.104.8)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9237 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-1904240146
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9237 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-1904240145
Archived-At: <>
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Apr 2019 20:48:28 -0000

> On Apr 24, 2019, at 3:41 PM, David Noveck <> wrote:
> > The opportunistic approach is meant to be a step up, not
> > a full solution. 
> OK, but the question at hand is whether rpc-tls (or the RFC that results
> from it) is to be limited to the opportunistic approach.   I'm arguing that
> it should not, and much of what you say below seems to indicate
> that you agree.
> However, other things you say lead me to a contrary conclusion, so it 
> would be best if we got a clear answer on this point.
> > We are bridging a gap here, and I think
> > we all expect/hope to have deeper solutions in the future.
> To get those, I think we need do more than expect/hope for them.   I think
> we need to plan for them.   One way to do that is to allow rpc-tls to be
> used either opprtunistically or non-oportunistically. rather than
> restructing it to opprtuunistic use and expect something else to 
> provide support for the non-opportunistic case.
> > For instance, we could define an RPC on QUIC transport
> > type that requires host authentication and encryption from
> > the get-go.
> I've heard some rumblings about QUIC and would like to see an RPC
> transport type defined.   However, we haven't yet seen even a 
> fragmentary individual submission on this topic.   Yes, we could
> do this in the future, but it is unwise to count on it any time soon/

I don't believe I'm counting on anything, just using
QUIC as an illustration that we are trying to look

> > 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). 
> If it does, then it is not opportunistic and there is a conflict with 
> the abstract which says "opportunistically".
> I've been unable to see where it says that.  I've searched the document  for "RECOMMEND".  Also:
> It does  say the following which seems to contradict it:
> The mechanism described in this document interoperates fully with RPC implementations that do not support TLS.  The use of TLS is
> automatically disabled in these cases.
> Tigran is looking for a discussion of this case and can't find it, so, in any case, it is not just me who isn't able to see this.

Sorry, I'm talking about the current Editor's Copy
of this document, which is here:

XML is available here:

> > That is a reasonable way to
> > address active attackers while there is still a large fleet
> > of RPC implementations without TLS support.
> I don't see that you can RECOMMEND that unconditionally,
> especially in an RPC-generic document.   When there are 
> a large set   of RPC implementations without TLS support,
> is precisely when the alternative (i.e. opportunistic) approach
> has its greatest value.

I want to have an opportunistic approach for today that
does not get in the way of something we might define later
that has stronger semantics. To me that looks also like
what you are driving at?

> > We could also strongly RECOMMEND the use of authentication.
> I don't think we should do that in the context of an RPC-generic 
> document.  Each protocol might reasonbly have its own needs and
> policies.

I should have been more clear. I meant "strongly RECOMMEND
the use of a policy that enforces the use of mutual peer
authentication." That is the strongest security we can get
from the mechanisms available within the form of TLS we are
working with here. It feels appropriate to state in an
RPC-generic document, and it does not seem contrary to the
stated goals of opportunistic security as defined in RFC 7435.

See the text in the Security Considerations section, where
the RECOMMENDATION is stated. I'm open to suggestions.

> The decision to proceed with an rpc-generic document was intended to
> accellerate development of rpc-tls.  That's worked so far but I think that to 
> maintain progress we have to avoid the temptation to put protocol-
> specific material (most likely for NFSv4) into what should be an rpc-
> generic document.   That would essentially undo the decision to make
> this an rpc-generic document.
> I've thought about something like this for v4-oriented document but
> I think that there the need/requirement for authentication of the client 
> is best tied to use of AUTH_SYS.    If you are using RPCSEC GSS and
> have an encrypted channel, you would have adequate NFSv4 security, even 
> in an internet environment. :-). At that point, client authentication, which
> might be work to add to the work already done to implement RPCSEC GSS,
> is better seen as OPTIONAL.

Trond is also thinking about an NFSv4-specific document that
could help fill in some of the gray areas and flesh out the
side-discussions that have arisen in this thread.

Chuck Lever