Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)

[Chuck Lever <[e-mail]>]

Hi Roman-

Thanks for your review and comments. If I may, I'd like to handle
the DISCUSS first, and then respond to the COMMENTs in a separate
reply.


> On Jul 6, 2020, at 11:24 PM, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-nfsv4-rpc-tls-08: Discuss
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> ** Despite Section 5.0 stating that only TLS v1.3+ can be used, there are two
> references to TLS v1.2 mechanisms:

Good catch!


> -- Section 5.0. Per “Implementations MUST support certificate-based mutual
> authentication.  Support for TLS-PSK mutual authentication [RFC4279] is
> OPTIONAL”.  Shouldn’t Section 2.2.2 or 4.2.11 of RFC8446 be used instead?

In fact Section 5.2.3 already cites RFC8446 Section 2.2. I propose changing
Section 5.0 as follows:

OLD:

   *  Implementations MUST support certificate-based mutual
      authentication.  Support for TLS-PSK mutual authentication
      [RFC4279] is OPTIONAL.  See Section 4.2 for further details.

NEW:

   *  Implementations MUST support certificate-based mutual
      authentication.  Support for PSK mutual authentication is
      OPTIONAL; see Section 5.2.3 for further details.


> -- Section 5.2.4.  The token binding mechanism suggested here, RFC8471, only
> applies to TLS v1.2.  The expired draft-ietf-tokbind-tls13 provides the TLS
> v1.3 mechanism.

Potential replacement:

OLD:

5.2.4.  Token Binding

   This mechanism is OPTIONAL to implement.  In this mode, a token
   uniquely identifies the RPC peer.

   Versions of TLS after TLS 1.2 contain a token binding mechanism that
   is more secure than using certificates.  This mechanism is detailed
   in [RFC8471].

NEW:

5.2.4.  Token Binding

   This mechanism is OPTIONAL to implement.  In this mode, a token
   uniquely identifies the RPC peer.  The TLSv1.3 token binding
   mechanism is detailed in [I-D.ietf-tokbind-tls13].


Another option would be to remove this section.


> ** Section 7.4.  Per “When using AUTH_NULL or AUTH_SYS, both peers are required
> to have DNS TLSA records and certificate material …”, what is “certificate
> materials”?  Can this guidance please be clarified (and perhaps related to the
> options specified in Section 5.2).

Potential replacement:

OLD:

   *  When using AUTH_NULL or AUTH_SYS, both peers are required to have
      DNS TLSA records and certificate material, and a policy that
      requires mutual peer authentication and rejection of a connection
      when host authentication fails.

NEW:

   *  When using AUTH_NULL or AUTH_SYS, both peers are required to have
      DNS TLSA records, keys with which to perform mutual peer
      authentication using one of the methods described in Section 5.2,
      and a security policy that requires mutual peer authentication and
      rejection of a connection when host authentication fails.


--
Chuck Lever