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

From: [email-masked]
Date: Mon, 03 Feb 2020 07:41:50 -0800

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           : Towards Remote Procedure Call Encryption By Default
        Authors         : Trond Myklebust
                          Charles Lever
	Filename        : draft-ietf-nfsv4-rpc-tls-06.txt
	Pages           : 21
	Date            : 2020-02-03

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-06
https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-rpc-tls-06

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

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: Chuck Lever <[email-masked]>
Date: Mon, 3 Feb 2020 10:44:11 -0500

> On Feb 3, 2020, at 10:41 AM, [email-masked] wrote:
> 
> 

I heard no objection to the changes proposed last week.
This revision addresses recent comments from Rick Macklem.

--
Chuck Lever

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Sat, 15 Feb 2020 13:47:27 +0100 (CET)

Hi Chuck,

Yesterday we were fixing in our (not nfs related) code a TLS bug. 
The issue was that we were redirecting clients to another endpoint
by an IP address. As a result, the client side server certificate
validation was failing, as subject alternative name didn't match
endpoint client was connecting to - subject and and alternative
name were dns names.

This situation is very similar to what we will ger with pNFS, where
data servers are offered as combination of netad and uaddr. Though
there is no direct connection between your spec and pNFS over TLS,
you probably should have a paragraph describing TLS and certificate
handling when server address presented as netid+uaddr.

Regards,
   Tigran.

----- Original Message -----
> From: "Chuck Lever" <[email-masked]>
> To: "NFSv4" <[email-masked]>
> Sent: Monday, February 3, 2020 4:44:11 PM
> Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-06.txt

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

---

From: Chuck Lever <[email-masked]>
Date: Sat, 15 Feb 2020 11:02:43 -0500

Hi Tigran-

Opened https://github.com/chucklever/i-d-rpc-tls/issues/8 to track
this.

> On Feb 15, 2020, at 7:47 AM, Mkrtchyan, Tigran <[email-masked]> wrote:
> 
> Hi Chuck,
> 
> data servers are offered as combination of netid and uaddr.

I'm thinking fs_locations too, but agreed.

> Though

I was wondering if this should be in a later NFS-related document,
but both netid and uaddr are RPC-layer data types.

Would you propose some text to get us started? Describe how you
addressed the bug, for example. What do you think are the
interoperability concerns?

--
Chuck Lever

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Mon, 17 Feb 2020 17:55:20 +0100 (CET)

Hi Chuck,

I will try provide some text to address this issue.

Thanks,
   Tigran.

----- Original Message -----
> To: "Tigran Mkrtchyan" <[email-masked]>
> Cc: "NFSv4" <[email-masked]>
> Sent: Saturday, February 15, 2020 5:02:43 PM