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

[Chuck Lever <[e-mail]>]

Hi Roman-

This review process has been waiting on your response for a month.


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

--
Chuck Lever