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

[Chuck Lever <[e-mail]>]

Hi Éric-

Thanks for your review and comments.


> On Jul 3, 2020, at 5:50 AM, Éric Vyncke via Datatracker <[e-mail]> wrote:
> 
> É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'.

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.


> -- Section 4.1 --
> 
> "(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].


> -- Section 6.3 --
> Just puzzled by "No comments from implementors" about Hammerspace while one
> 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