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

[Chuck Lever <[e-mail]>]

Hi Roman-

I haven't heard any response on these items. Is there something more
you need from me?


> On Jul 7, 2020, at 11:15 AM, Chuck Lever <[e-mail]> wrote:
> 
> 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