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

[Chuck Lever <[e-mail]>]

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


--
Chuck Lever