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

[Chuck Lever <[e-mail]>]

To the WG:

> On Aug 21, 2020, at 3:45 PM, Roman Danyliw <[e-mail]> wrote:
> 
> >>> -- 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.

It seems to me that leaving this section in place introduces an
indeterminate delay before publication. At this point my preference
would be to remove all discussion of token binding, since it's not
clear when TLS v1.3 will properly support it.

Is there any objection to removal?


--
Chuck Lever