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

[David Noveck <[e-mail]>]

On Thu, Oct 8, 2020, 5:50 PM Benjamin Kaduk <[e-mail]> wrote:

> On Tue, Sep 01, 2020 at 11:26:21AM -0400, Chuck Lever wrote:
> >
> >
> > > On Jul 8, 2020, at 2:56 AM, Benjamin Kaduk via Datatracker <
> [e-mail]> wrote:
> > >
> > > Benjamin Kaduk has entered the following ballot position for
> > > draft-ietf-nfsv4-rpc-tls-08: Discuss
> > >
> > > When responding, please keep the subject line intact and reply to all
> > > email addresses included in the To and CC lines. (Feel free to cut this
> > > introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/
> > >
> > >
> > >
> > > ----------------------------------------------------------------------
> > > DISCUSS:
> > > ----------------------------------------------------------------------
> > >
> > > (8) Can we clarify the status of DNSSEC (or DANE) requirements?
> Section 1
> > > assumes that support for DNSSEC is already available in an RPC
> > > implementation, but Section 7.1.1 says that "Clients [sic]
> implementors can
> > > choose from" a list of things including DANE TLSA records.  Why would
> we
> > > require DNSSEC support but not using the records if they're present?
> >
> > OK, I'm parsing this comment more closely now.
> >
> > The statement in Section 1 you refer to above is:
> >
> >    The protocol specification in the current document assumes that
> >    support for RPC, TLS, PKI, GSS-API, and DNSSEC is already available
> >    in an RPC implementation where TLS support is to be added.
> >
> > I hadn't counted this as a "requirement" since a BCP14 keyword is
> > not used, and because it appears in the Introduction as background
> > material.
> >
> > Section 7.1.1 currently says this:
> >                                                               Clients
> >    implementers can choose from the following to mitigate STRIPTLS
> >    attacks:
> >
> >    *  A TLSA record [RFC6698] can alert clients that TLS is expected to
> >       work, and provide a binding of hostname to X.509 identity.  If TLS
> >       cannot be negotiated or authentication fails, the client
> >       disconnects and reports the problem.
> >
> >    *  Client security policy can require that a TLS session is
> >       established on every connection.  If an attacker spoofs the
> >       handshake, the client disconnects and reports the problem.  If
> >       TLSA records are not available, this approach is strongly
> >       encouraged.
> >
> > Here, it is assumed that the RPC-over-TLS implementation has DNSSEC
> > support. What is not assumed is that the peer always operates in
> > an environment where the DNS administrator has configured TLSA
> > records.
> >
> > I'm open to suggestions on how to structure this section more clearly.
>
> My main point (or question?) here is whether (or when)


I think we may have to add (or where).

we require
> RPC-over-TLS clients to perform TLSA queries when attempting STARTTLS.  The
> current text in 7.1.1 comes across (at least to me) as a statement of fact:
> if you want to protect against downgrade, TLSA records do that (when they
> exist).  There is no requirement or suggestion to actually check for the
> TLSA record and obtain that protection.


Yes.

Now, making additional DNS queries
> is not always great for performance, and if the client is running in an
> opportunistic mode it may not care about the lack of downgrade protection,
>

As I understand it, whether one is running in opportunistic mode is
currently left as a matter for "local policy". I think it is implied that
that policy could be constrained in ULP-specific documents.

so it's not a foregone conclusion that we should be putting in text like
> "clients MUST check for the existence of a TLSA record for the target
> server before initiating an RPC-over-TLS connection",


I agree.

but I do think we
> should consider the question of what (if any) level of requirement is
> appropriate and under what conditions.


The alternative is to leave this matter to the ULP's.

(The flip side of this question is
> that if we don't have any case where we require the use of the DNSSEC
> support, we may not need to state that we assume it to be present.)
>

But the document that did add that use case would have to do so.



> Thanks,
>
> Ben
>