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

[Roman Danyliw <[e-mail]>]

Hi David and Chuck!

Thanks for your patience and my apologize for the delay.  More inline …

Regards,
Roman

On Tue, Aug 4, 2020 at 8:59 AM Chuck Lever <[e-mail]<mailto:[e-mail]>> wrote:
>> On Jul 7, 2020, at 11:15 AM, Chuck Lever <[e-mail]<mailto:[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]<mailto:[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.
[Roman] Make sense.  Thanks.
>>
>>> -- 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.

I leave this up to the working group/responsible AD to sort out.  My DISCUSS is on the fact this this behavior needs to be specified for TLS v1.3 not on how it gets documented.  My recommendation would be to remove the section – there is no IETF consensus reference for this behavior.  This binding can always be specified later.  If there is a desire to use ietf-tokbind-tls13 and there is work planned to publish it (i.e., pull it out of expired state and iterate to completion), this document could also wait in a MISREF state with the RFC Editorial until it is published.  I suspect there is also the option of re-calling consensus on the document for a downref to an unpublished document.  I’m flexible.

>>
>>> ** 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.
[Roman] Works for me.  Thank you.





> --
> Chuck Lever
>
>
>

--
Chuck Lever