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

["Eric Vyncke (evyncke)" <[e-mail]>]

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 <[e-mail]>
Date: Friday, 3 July 2020 at 17:33
To: Eric Vyncke <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [nfsv4] Éric Vyncke's No Objection on draft-ietf-nfsv4-rpc-tls-08: (with COMMENT)

    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