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

[David Noveck <[e-mail]>]

On August 4th, Chuck Lever wrote:
> This review process has been waiting on your response for a month

Actually it was only 27 days then, since the messages that Chuck was
waiting for response to were only sent 7/7-8. Now that it has been a full
month, I think it is appropriate to look at where we are and how to  best
proceed on this review.

Considerable progress has been made on this document since IESG
Consideration began on 6/22. I'd like to thank everybody who participated
in moving this document toward being ready for RFC editing and subsequent
publication.   Clearly, we need to incorporate the many suggestions that
have been made in a new document revision.   However, I am afraid that, if
we continue as we have been,, we are facing an essentially unbounded delay
in moving this work forward.

Has anybody receiving this been in contact with Roman over the last month?
 I'm afraid he might be sick, in  which case we all wish him a speedy
recovery.   We haven't seen any out-of-the-office mail so he probably isn't
on vacation. I'd appreciate any info people have that bears on the question
of when we might expect a  response.  In any case, given the history so
far, it doesn't seem very likely that we will see a quick resolution of
this.

Chuck has, for understandable reasons, been reluctant to start on the
remaining DISCUSS (which is Ben K.'s, I believe) untIl we see closure
on the current one.   However, given the ongoing delay in receiving Roman's
response, I think it would be best if we moved on without waiting for a
response from Roman himself.   It would be helpful if the IESG as a whole
could look at Chuck's response to Roman's DISCUSS and COMMENTs and point
out any problems.   This would be especially important in the case of those
who supported Roman's DISCUSS (Ben K. at least). This might allow Chuck an
opportunity to deal with any issues/gaps that people see and allow him to
move on to deal with the final DISCUSS holding this up.

This will provide some additional time for Roman to get into contact,
without holding up the process waiting.   If he is able to get into
contact, he can make his own judgement about the adequacy of Chuck's
response.  Then, if the delay continues indefinitely, the IESG could
consider necessary administrative steps to allow the document to go forward
in the absence of Roman's participation.

On Tue, Aug 4, 2020 at 8:59 AM Chuck Lever <[e-mail]> wrote:

> 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
>
>
>
>