Subject: [nfsv4] Éric Vyncke's No Objection on draft-ietf-nfsv4-rpc-tls-08: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Fri, 03 Jul 2020 02:50:14 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-nfsv4-rpc-tls-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

Please find below a couple on non-blocking COMMENTs.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
As section 4.2 specifies the use of at least server-side authenticated TLS
session, I wonder why the abstract contains 'opportunistic encryption'.

-- Section 4.1 --

"(D)TLS-protected RPC" while DTLS was never expanded before... or did I miss it
?

-- Section 6.3 --
Just puzzled by "No comments from implementors" about Hammerspace while one
author is affiliated with Hammerspace.

---

From: Chuck Lever <[email-masked]>
Date: Fri, 3 Jul 2020 11:32:55 -0400

Hi Éric-

Thanks for your review and comments.

> On Jul 3, 2020, at 5:50 AM, Éric Vyncke via Datatracker <[email-masked]> wrote:
> 

Clients that support TLS can be deployed in environments with servers that
do not. The client has to detect a server's TLS support before TLS can be
used.

Opportunism here means that the RPC protocol still works if the server does
not support TLS. The choice of whether to proceed with operation is
determined by security policy.

> "(D)TLS-protected RPC" while DTLS was never expanded before... or did I miss it

That's recently-added text. Sorry for the oversight. To address it, I
propose changing the Introduction as follows:

OLD:

   The alternative described in the current document is to employ a
   transport layer security mechanism that can protect the
   confidentiality of each RPC connection transparently to RPC and
   upper-layer protocols.  The Transport Layer Security protocol
   [RFC8446] (TLS) is a well-established Internet building block that
   protects many standard Internet protocols such as the Hypertext
   Transport Protocol (HTTP) [RFC2818].

NEW:

   The alternative described in the current document is to employ a
   transport layer security mechanism that can protect the
   confidentiality of each RPC connection transparently to RPC and
   upper-layer protocols.  The Transport Layer Security [RFC8446] (TLS)
   and Datagram Transport Layer Security [I-D.ietf-tls-dtls13] (DTLS)
   protocols are a well-established Internet building blocks that
   protect many standard Internet protocols such as the Hypertext
   Transport Protocol (HTTP) [RFC2818].

> author is affiliated with Hammerspace.

Hammerspace is covered in Section 6.2.

Trond invented the probing mechanism specified in Section 4.1, but as far
as I know has not proffered any direct feedback resulting from
implementation experience. If that's incorrect, I invite him to correct me.

However, I see that Section 6.3 should be updated:

When this section was written many months ago, we optimistically assumed
the Linux prototype would be further along by now.

A Linux in-kernel prototype is underway, but implementation delays have
resulted from the challenges of handling a TLS handshake in a kernel
environment. Those issues stem from the architecture of TLS and the
kernel, not from the design of the RPC-over-TLS protocol.

--
Chuck Lever

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 3 Jul 2020 15:52:32 +0000

Chuck

Thank you for your prompt and detailed reply. Your suggested texts and explanations are perfect for me

Regards

-éric

-----Original Message-----
From: Chuck Lever <[email-masked]>
Date: Friday, 3 July 2020 at 17:33
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [nfsv4] Éric Vyncke's No Objection on draft-ietf-nfsv4-rpc-tls-08: (with COMMENT)

    Hi Éric-

    OLD:

    NEW:

    --
    Chuck Lever