Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-02.txt

From: [email-masked]
Date: Thu, 25 Apr 2019 10:27:06 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network File System Version 4 WG of the IETF.

        Title           : Remote Procedure Call Encryption By Default
        Authors         : Trond Myklebust
                          Charles Lever
	Filename        : draft-ietf-nfsv4-rpc-tls-02.txt
	Pages           : 18
	Date            : 2019-04-25

Abstract:
   This document describes a mechanism that, through the use of
   opportunistic Transport Layer Security (TLS), enables encryption of
   in-transit Remote Procedure Call (RPC) transactions while
   interoperating with ONC RPC implementations that do not support this
   mechanism.  This document updates RFC 5531.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-nfsv4-rpc-tls-02
https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-rpc-tls-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-rpc-tls-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: David Noveck <[email-masked]>
Date: Thu, 25 Apr 2019 15:26:47 -0400

Thanks for getting this out.   As far as I can see, this gives Tigran what
he needs to implement the policies he thinks miht be needed although not in
he form he is asking for.   I'd like to know if he is satisfied with this.

With regard to clarification of the use of the term "opporunistic", I feel
what is in the abstract is clear and accurate.

However, I do have issues with the (new) last paragraph of the
introduction.   Of particular concern to me is the phrase, "until a more
thorough approach can be provided", which might be read as suggesting we
would have to go through a similar exercise later to define a (new) more
thorough approach. NFS has had a number of failed approaches to security
and we don't to have more than one in our future if we can avoid it, and I
believe we can.

I don't really think that an opportunistic approach to security (as opposed
to the use of "opprtunistic TLS") is truly part of the security approach
here. It apppears to me that it is an expedient device to deal with current
lack of rpc-tls suport. As a result, I don't thiink we will need a new
approach, but instead a new set of policies more appropriate to cases in
which rpc-tls support is more common. So I would suggest rewriting the
paragraph as follows:

The use of TLS as described in this document is compatible with policies
adopting an opportunistic security approach, as defined by [RFC7435], to
RPC-based protocols. As long as there is still a significant fleet of RPC
deployments that lack support for TLS, policies embodying an opportunistic
approach can ameliorate the challenges that prevent the broad use of
encryption with RPC-based protocols (including the most popular such
protocols, which are NFS versions). The use of other policies is provided
for, although the specfications for the specfic rpc protocols may make
recommendations or define requirements which constrain client and server
policy choice.

On Thu, Apr 25, 2019 at 1:27 PM <[email-masked]> wrote:

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>