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

[Benjamin Kaduk <[e-mail]>]

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) 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.  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,
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", but I do think we
should consider the question of what (if any) level of requirement is
appropriate and under what conditions.  (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.)

Thanks,

Ben