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

Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 08 July 2020 06:56 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: nfsv4@ietf.org
Delivered-To: nfsv4@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBC03A09A6; Tue, 7 Jul 2020 23:56:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-nfsv4-rpc-tls@ietf.org, nfsv4-chairs@ietf.org, nfsv4@ietf.org, David Noveck <davenoveck@gmail.com>, davenoveck@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.7.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <159419140773.2153.2711644434582054796@ietfa.amsl.com>
Date: Tue, 07 Jul 2020 23:56:48 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/IL5I5cem1p8KiCcDQw3Nd5ruhRE>
Subject: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jul 2020 06:56:48 -0000

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

I support Roman's Discuss points.

Sorry to provide so many new substantive points here -- I was only able to
follow the email discussions in the WG (and not completely, even) but not to
actually read the document earlier.  It hopefully goes without saying, but
the goal is to make sure we get it right, since it's going to be an important
pillar for the future of things; I'm happy to see that this is advancing.

(1) I don't think that the claim in Section 4.2 that "[b]oth RPC and TLS have
peer and user authentication" is correct, at least given my understanding of
those terms.  Using this document's definition of RPC "peer authentication"
as analogous to TLS server authentication, the functionality that TLS calls
"mutual authentication" is more analogous to RPC client authentication,
though it is sometimes repurposed for use for user authentication, with
concommittant bad user experience.  This analogy does not seem critical to
the mechanisms of this document, so I believe we should remove or modify it.

(2) The mention of using RPCSEC_GSS with GSS channel bindings to TLS is
quite underspecified.  Unfortunately, this is largely the fault of other
specifications, but we have to deal with the fallout.  On first glance (but
subject to further clarification/change), it seems like we should:

- Say what channel binding type (from the registry that RFC 5929 registered
  stuff in) is to be used -- just citing 5929 doesn't help, since it
  mentions three different ones (none of which are really right for TLS 1.3,
  see below)

- provide a mechanism for the peers to determine whether GSS channel binding
  to TLS is to be used.  (As discussed in
  draft-ietf-kitten-channel-bound-flag, the current state of things GSS is
  that if one party supplies channel bindings but the other doesn't, the
  security context negotiation fails, which is usually not the best for
  usability.)  Since this is a greenfield GSS-API application, the simplest
  thing by far is to just say "always provide the channel bindings when
  using RPCSEC_GSS over TLS".  It's even the more secure option, too :)

- give more detail about what value to provide as the 'chan_binding' input
  to the GSS security context negotiation.  We currently reference RFC 5929,
  that defines three different channel-binding values, but none of them are
  really usable for TLS 1.3 (as discussed in
  draft-ietf-kitten-tls-channel-bindings-for-tls13).  Most likely this will
  mean using the tls-exporter value from that document.

(3) Please check this reference in Section 5.1.1:

   Reverse-direction operation occurs only on connected transports such
   as TCP (see Section 2 of [RFC8166]).  [...]

It seems likely that RFC 8167 was intended...

(4) I don't think it's particularly safe to suggest that non-protected RPCs
should be exchanged on the same 5-tuple that just terminated a DTLS
association, since neither DTLS nor UDP provide in-order delivery, so there
is ambiguity as to whether a datagram should be interpreted as DTLS
protected or not.  This is particularly problematic in the face of the three
different DTLS record headers (DTLSPlaintext, DTLSCiphertext(full), and
DTLSCiphertext(minimal)) with something like 10 or 11 different possible
values for the first byte that might be in flight, with limited "magic
number" verification fields available.  I think I need some input from the
TSV ADs about what the options are, though -- while a cooling-off period
might be fine if an ephemeral port is in use, it seems problematic for cases
where fixed port numbers are used for both source and destination.

(5) Section 5.2.1 requires that:

   *  Implementations SHOULD indicate their trusted Certification
      Authorities (CAs).

Indicate to whom?

(6) The usage of RFC 6125 procedures in Section 5.2.1 seems counter to its
intent.  Specifically, we seem to be saying "the peer gave me a cert, let me
look through it to see if it has something I like", but RFC 6125's intended
procedure is "I know a list of names that I expect to see at least one of in
the cert; these rules tell me whether the cert is valid for any such name".
It's not entirely clear that it's appropriate for this document to specify
how the client has to order its list of names by type (per Section 6.1 of
RFC 6125's "The client constructs a list of acceptable reference
identifiers"), which the bit about "The following precedence applies" seems
to be doing.  To the extent that we give a recommendation to use DNS-ID
instead of CN-ID, and ipAddress SAN instead of CN-ID, that's already covered
by RFC 6125; it would be okay for us to say "use DNS-ID or iPAddress SAN",
though.  (Roman's comment about "why not a normative MUST" for putting IP
addresses in the iPAddress SAN is related, and if we don't have a compelling
reason to allow the flexibility, we should limit to the specific
DNS-ID/iPAddress options without allowing CN-ID.)

(6.1) Note additionally that if wildcard certificates are to be used, RFC
6125 requires the application protocol specification to give details on how
they are to be used.

(6.2) RFC 6125's procedures are (facially, at least) only valid for TLS
server authentication.  We also want to authenticate TLS clients, so we
should say whether we expect the same procedures to be used, or what
procedures should be used (even just as how it differs from the RFC 6125
ones).  Of particular note is that, since the server is not initiating the
network connection, it is unlikely to have a preconceived notion of what
client identity to expect, and is likely limited to attempting to extract
something from the certificate.  In this scenario a precedence list (as I
complained about being inconsistent with RFC 6125 above) would be
appropriate.

(7) Section 5.2.1 uses the phrase "renegotiate the TLS session".
Renegotiation is not defined or allowed for TLS 1.3; generally one would
need to either remember the presented certificate and re-run the validation
process on it or shutdown the TLS connection and make a new one, though in
theory one could try to define a mechanism using post-handshake
authentication.  (I don't recommend the latter, though; it's not widely
implemented/used.)

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

(9) I agree with Roman('s comment) that Sections 5.2.2 and 5.2.4 should give
a minimum amount of information to be exposed to the administrator for
implementing the trust mode.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm surprised that we don't make a normative reference to BCP 195's
"Recommendations for Secure Use of Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS)" (we have only an informative
reference from the security considerations).

Abstract

I can't quite put my finger on it, but something about "enables encryption
of in-transit Remote Procedure Call (RPC) transactions" rubs me the wrong
way.  I think I want to change what the "in transit" binds to, since what we
are doing is encrypting RPC messages while they are in transit, as opposed
to applying protection to just the subset of messages that are "in transit".

Section 1

                                                                    It
   strongly recommended that newly defined Internet protocols should
   make a genuine effort to mitigate monitoring attacks.  Typically this
   mitigation is done by encrypting data in transit.

I suggest s/is done by/includes/, since in some cases padding or other
side-channel-resistance mechanisms are also used.

   *  Parts of each RPC header remain in clear-text, constituting a
      significant security exposure.

"Security" is kind of a catch-all term; it would be good to be more precise,
here, perhaps as "constituting a needless loss of metadata confidentiality".

   Moreover, the use of AUTH_SYS remains common despite the adverse
   effects that acceptance of UIDs and GIDs from unauthenticated clients
   brings with it.  Continued use is in part because:

   *  Per-client deployment and administrative costs are not scalable.

This writing could be tidied up; it currently can be read as saying that the
deployment/administrative costs are of AUTH_SYS, but really the costs belong
to the only currently defined alternative to AUTH_SYS.  Perhaps, "Per-client
deployment and administrative costs for the only defined alternative to
AUTH_SYS are expensive at scale".

   *  Host identity management and user identity management must be
      enforced in the same security realm.  In certain environments,
      different authorities might be responsible for provisioning client
      systems versus provisioning new users.

I think this is only true from a certain point of view.  They have to be
related, and (assuming Kerberos since non-Kerberos RPCSEC_GSS isn't really a
thing) a cross-realm relationship would have to exist in at least one
direction when client system and user provisioning are managed by separate
kerberos realms, but the authorities in question do not need to be exactly
the same.

   The alternative described in the current document is to employ a
   transport layer security mechanism that can protect the
   confidentiality of each RPC connection transparently to RPC and
   upper-layer protocols.  The Transport Layer Security protocol

side note: I'd consider an editorial rewording to something like:

% In light of the difficulties and issues with both the mechanisms currently
% defined for RPC protection and/or authentication, and the continued
% inability to make significant progress in mitigating those concerns, this
% document takes a new approach by defining a third mechanism to complement
% the existing ones.  The confidentiality of each RPC connection can be
% protected transparently to the RPC and upper-layer protocols by use of a
% transport-layer security mechanism.  The Transport Layer Security protocol

   Encryption By Default:  Transport encryption can be enabled without
      additional administrative tasks such as identifying client systems
      to a trust authority, generating additional keying material, or
      provisioning a secure network tunnel.

To clarify Roman's comment, it seems worth specifying that this is without
additional *per-client* keying material.  Generating per-server keying
material is clearly a minimum requirement.

   The current document specifies the implementation of RPC on an
   encrypted transport in a manner that is transparent to upper-layer
   protocols based on RPC.  The imposition of encryption at the
   transport layer protects any upper-layer protocol that employs RPC,
   without alteration of that protocol.

nit: this paragraph, especially the first sentence, feels pretty redundant
with the paragraph that I proposed a rewording of.

   that do not support TLS.  However, specifications for RPC-based
   upper-layer protocols should choose to require even stricter policies
   that guarantee encryption and host authentication is used for all RPC
   transactions.  [...]

We could probably cite 7258 again to strengthen this argument.  I though
7435 (opportunistic security) also had some applicable text, but am not
finding it right now.

   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.

We assume that TLS is available where TLS support is to be added?  That
might merit a bit more explanation.

Also, what exactly does "PKI" mean, here?  PKIX X.509 certificates?

Section 4.1

   The mechanism described in the current document interoperates fully
   with RPC implementations that do not support RPC-over-TLS.  Policy
   settings on the RPC-over-TLS-enabled peer determine whether RPC

I'd consider joining the two sentences via ", subject to policy settings on
the RPC-over-TLS-enabled peer that determine".

   The RPC client might query the RPC server's rpcbind service to make
   this selection.  In all cases, an RPC server MUST listen on the same

Is there a reference we could put in for the rpcbind service?

   containing a NULL RPC procedure with an auth_flavor of AUTH_TLS.  The
   mechanism described in the current document does not support RPC
   transports other than TCP and UDP.

It might be nice if we could find a way to mention this transport
restriction in the previous paragraph, though it's hardly vital.

   The flavor value of the verifier in the RPC Reply message received
   from the server MUST be AUTH_NONE.  The length of the verifier's body
   field is eight.  The bytes of the verifier's body field encode the
   ASCII characters "STARTTLS" as a fixed-length opaque.

nit/style: I kind of want there to be mention of "to accept" starttls or
"a server supporting this mechanism" or something in this paragraph, since
of course a client that sent the proper probe message will not get this
response from a server that doesn't implement it.

   If an RPC client uses the AUTH_TLS authentication flavor on any
   procedure other than the NULL procedure, or an RPC client sends an
   RPC AUTH_TLS probe within an existing (D)TLS session, the RPC server
   MUST reject that RPC Call by setting the reply_stat field to
   MSG_DENIED, the reject_stat field to AUTH_ERROR, and the auth_stat
   field to AUTH_BADCRED.

nit: is the protocol element a 'reply_stat' field or a 'stat' field of type
'reply_stat'?  Likewise for reject_stat and auth_stat.

   Once the TLS session handshake is complete, the RPC client and server
   have established a secure channel for communicating.  A successful
   AUTH_TLS probe on one particular port/transport tuple never implies
   RPC-over-TLS is available on that same server using a different port/
   transport tuple.

It could be worth saying something about expected future availability of
RPC-over-TLS on the same server/port/transport (though it is, of course, not
guaranteed).  RFC 7435 admits this possibility when it discusses that peer
capabilities may be obtained by out-of-band mechanisms such as
trust-on-first-use (TOFU).

Section 4.2

   Each RPC server that supports RPC-over-TLS MUST possess a unique
   global identity (e.g., a certificate that is signed by a well-known
   trust anchor).  Such an RPC server MUST request a TLS peer identity

This is perhaps sufficiently vague to not be actively problematic, but at
least comes close to a touchy area.  The main source of "well-known trust
anchor" that many readers will think of is the Web PKI, but use of TLS
certificates issued from the Web PKI for authenticating RPC operation enters
a grey area in terms of CA policy; if the CA determines that the certificate
is being used for a purpose other than the one it was issued for, the
certificate is subject to revocation by the CA.  A hypothetical
mass-revocation event due to publicity about wide-scale "misuse" of TLS
certificate for RPC (i.e., not HTTP) would have knock-on effects on other
consumers of those CAs via expanded CRL size and the resources needed to
perform revocation checks.  Things would be easier in this regard if a
dedicated "well-known" CA infrastructure appeared for RPC usage, though many
things would have to align for that to happen (which would themselves not be
"easy"!), and there are of course options involving site-local CAs where the
combination of issuer and subject serves to satisfy the "unique global
identity" criterion.

   from each client upon first contact.  There are two different modes

nit: "contact" is perhaps needlessly ambiguous (i.e., w.r.t. TLS handshake
vs. NULL RPC probe); perhaps "during the TLS handshake" suffices?

      identities.  If authentication of either peer fails, or if
      authorization based on those identities blocks access to the
      server, the peers MUST reject the association.

nit: there's something like a singular/plural mismatch, in that only
authorization based on the client identity would "block access to the
server", but we talk about "authorization based on those identities" plural.
I guess in some sense the client could reject a server as unauthorized, but
given how the server identity check happens usually the client would make
that rejection before it even does a DNS resolution and starts the TLS
handshake, with the in-handshake checks being limited to authenticating that
the server is the one the client was trying to talk to.

   In either of these modes, RPC user authentication is not affected by
   the use of transport layer security.  When a client presents a TLS
   peer identity to an RPC server, the protocol extension described in
   the current document provides no way for the server to know whether
   that identity represents one RPC user on that client, or is shared
   amongst many RPC users.  Therefore, a server implementation must not

That's only true to the extent that we haven't yet defined X.509 mechanisms
to convey that information.  It's certainly imaginable that we would define
new name types or key usage that are specific to RPC client or RPC user
authentication, though I don't know of any such mechanism that already
exists today.

Section 4.2.1

   RPCSEC GSS can also perform per-request integrity or confidentiality
   protection.  When operating over a TLS session, these GSS services
   become redundant.  An RPC implementation capable of concurrently

At risk of being called a pedant, these services are only "largely
redundant" -- most TLS setups will be using standard asymmetric key exchange
that is vulnerable to a quantum computer, whereas a kerberos-backed
RPCSEC_GSS will be using symmetric crypto that is or can be
quantum-resistant for appropriate key sizes.  When a "record now, decrypt
later" attack is relevant the distinction can be important to make (though
for purely ephemeral traffic the distinction collapses).

Section 5

   *  Negotiation of a ciphersuite providing confidentiality as well as
      integrity protection is REQUIRED.  Support for and negotiation of
      compression is OPTIONAL.

There's a bit of tidying we can do that falls out from the "1.3 only" change
-- all TLS 1.3 ciphersuites provide confidentiality (by virtue of needing to
be AEAD ciphers), and compression is forbidden in TLS 1.3.

   *  Implementations MUST support certificate-based mutual
      authentication.  Support for TLS-PSK mutual authentication
      [RFC4279] is OPTIONAL.  See Section 4.2 for further details.

(Roman's Discuss is valid, but also) people using TLS-PSK (with TLS 1.3)
might be interested in the topics discussed in
draft-ietf-tls-external-psk-guidance and
draft-ietf-tls-external-psk-importer.  I don't insist on referencing them,
but it might be worth considering.

   Client implementations MUST include the
   "application_layer_protocol_negotiation(16)" extension [RFC7301] in
   their "ClientHello" message and MUST include the protocol identifier
   defined in Section 8.2 in that message's ProtocolNameList value.

   Similary, in response to the "ClientHello" message, server
   implementations MUST include the
   "application_layer_protocol_negotiation(16)" extension [RFC7301] in
   their "ServerHello" message and MUST include only the protocol
   identifier defined in Section 8.2 in that message's ProtocolNameList
   value.

[this would change if we end up using ALPN to indicate whether GSS channel
binding is used]

   If the server responds incorrectly (for instance, if the
   "ServerHello" message does not conform to the above requirements),
   the client MUST NOT establish a TLS session for use with RPC on this
   connection.  See [RFC7301] for further details about how to form
   these messages properly.

We could probably give a bit more detail about what happens here.
Specifically, once you abort the TLS handshake, most implementations don't
give you a guaranteed clean way to get back to a non-TLS socket, so you
generally end up tearing the whole thing down.  If we expect people to be
able to say "well, STARTTLS failed, let me just reuse this connection for
unencrypted RPC", we should be clear about that.

Section 5.1.1

                                                                      If
   spurious traffic appears on a TCP connection between the initial
   clear-text AUTH_TLS probe and the TLS session handshake, receivers
   MUST discard that data without response and then SHOULD drop the
   connection.

Is this "spurious traffic" supposed to be just in one direction or in both?
IIUC at least one of those cases would probably be malformed RPC (and thus
discarded anyway?).

   The protocol convention specified in the current document assumes
   there can be no more than one concurrent TLS session per TCP
   connection.  This is true of current generations of TLS, but might be
   different in a future version of TLS.

I'd be pretty surprised if a future version of TLS grew this feature; I've
asked the TLS WG if we think there's not need to include such a statement in
this document.

                                         To protect reverse-direction
   RPC operations, the RPC server does not establish a separate TLS
   session on the TCP connection, but instead uses the existing TLS
   session on that connection to protect these operations.

My apologies for zoning out during the WG discussions, but we're sure that
the RPC framing is enough to let this work (with forward and
reverse-direction RPCs intermingled on the same TLS connection)?

Section 5.1.2

   Using DTLS does not introduce reliable or in-order semantics to RPC
   on UDP.  Each RPC message MUST fit in a single DTLS record.  DTLS
   encapsulation has overhead, which reduces the effective Path MTU
   (PMTU) and thus the maximum RPC payload size.  The use of DTLS record

"Packetization Layer Path MTU" (PLPMTU, draft-ietf-tsvwg-datagram-plpmtud,
in the RFC Editor's queue) might be a better term to use.

   As soon as a client initializes a UDP socket for use with an RPC
   server, it uses the mechanism described in Section 4.1 to discover
   DTLS support for an RPC program on a particular port.  It then
   negotiates a DTLS session.

We could probably normalize the wording between the TCP and UDP cases (e.g.,
TCP says "typically, once a client completes the TCP handshake, it uses the
mechanism [...]" but this uses descriptive text).  That would also let us
decide whether or not to mention that (D)TLS usage is contingent on mutual
support for STARTTLS.

   extension described in Section 9 of [I-D.ietf-tls-dtls13], and RPC-
   on-DTLS peer endpoints MUST provide a ConnectionID with a non-zero

nit: we seem to prefer RPC-over- to RPC-on (as is used here, across the line
break)

Section 5.1.3

   Transports that provide intrinsic TLS-level security (e.g., QUIC)
   need to be addressed separately from the current document.  In such
   cases, the use of TLS is not opportunistic as it can be for TCP or
   UDP.

nit(?): somehow "can be" doesn't feel like the right wording here, but "must
be" isn't right either...

   scope of the current document.  Because there might not be other
   provisions to exchange client and server certificates, authentication

Er, "other provisions" than what?

Section 5.2.1

   X.509 certificates are specified in [X.509] and extended in
   [RFC5280].

Note that RFC 5280 claims to be a profile of X.509, not an extension to it.

   *  Certificate validation MUST include the verification rules as per
      [RFC5280].

It might be appropriate to reference RFC 6125 as well (though that places
some restrictions on how servers are named, claims to only apply to server
certificate validation, and requires specifying what type of name is to be
validated and how the input name to validation is obtained)

   *  Peer validation always includes a check on whether the locally
      configured expected DNS name or IP address of the server that is
      contacted matches its presented certificate.  DNS names and IP

In the RFC 6125 parlance these would be the "DNS-ID" and "iPAddress
subjectAltName", respectively, and such a reference would obviate the need
for most of the subsequent explanation.

   *  Implementations MAY allow the configuration of a set of additional
      properties of the certificate to check for a peer's authorization
      to communicate (e.g., a set of allowed values in
      subjectAltName:URI or a set of allowed X.509v3 Certificate
      Policies).

I could imagine an extendedKeyUsage being configured, too.

   trust model.  As a suggestion, at least the following parameters of
   the X.509 client certificate SHOULD be exposed:

What about non-extended keyUsage, and arbitrary X.509 extensions?

   *  Originating IP address

I don't think "originating IP address" is a parameter of the X.509 client
certificate.

   *  Certificate Fingerprint

Using what hash algorithm?

   *  Subject
   [...]
   *  all X.509v3 Subject Alternative Name

Per RFC 5280 (§ 4.1.2.6) the SAN *is* (part of) the Subject.

Section 5.2.2

As above, fingerprint using what hash algorithm?

Section 5.2.3

   This mechanism is OPTIONAL to implement.  In this mode, the RPC peer
   is uniquely identified by keying material that has been shared out-
   of-band or by a previous TLS-protected connection (see Section 2.2 of
   [RFC8446]).  [...]

I strongly suggest not mentioning the "by a previous TLS-protected
connection (see Section 2.2 of [RFC8446])" case here; the TLS stack should
handle resumption transparently and expose the identity information from the
original handshake.  There's no need to make the application manage and
track the resumption PSK identifier values.

   *  TLS Identifier

nit: missing "PSK".

Section 7

It's probably worth pulling in (by reference) the security considerations of
RFCs 5280 and 8446 as well.

Section 7.1.1

   *  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

It might be worth adding a few more words about how this is a "fail-safe"
setup where the attacker cannot cause the client to fall back to plaintext.

Section 7.1.2

   The exception to this edict is the initial RPC NULL procedure that
   acts as a STARTTLS message, which cannot be protected.  This RPC NULL
   procedure contains no arguments or results, and the AUTH_TLS
   authentication flavor it uses does not contain user information.

I suggest hammering home the conclusion, ", so there is negligible privacy
impact from this exception".

Section 7.2

I'd consider using the phrase "credentials" instead of, or in addition to,
"identity material".

Section 7.3

   but it does enable receivers to reject non-participant messages.  In
   particular, transport layer encryption plus peer authentication
   protects receiving XDR decoders from deserializing untrusted data, a
   common coding vulnerability.

I might go on to add that these decoders would still be exposed to untrusted
input in the case of the compromise of a trusted peer (or trusted CA).

   In light of the above, it is RECOMMENDED that when AUTH_SYS is used,
   every RPC client should present host authentication material to RPC
   servers to prove that the client is a known one.  The server can then
   determine whether the UIDs and GIDs in AUTH_SYS requests from that
   client can be accepted.

Perhaps add ", based on the authenticated identity of the client"?

Section 7.4

   *  When using AUTH_NULL or AUTH_SYS, both peers are required to have
      DNS TLSA records and certificate material, and a policy that

I suggest to s/DNS/DANE/ or s/DNS/DNSSEC/.

   *  RCPSEC_GSS provides integrity and privacy services which are
      redundant when TLS is in use.  These services should be disabled

["largely redundant", again]

Section 8

I think we should consider getting IANA to allocate OIDs for some X.509
extendedKeyUsage values that correspond to RPC-TLS client/server usage.
It's not necessarily something that we'd require to be present (but would be
helpful if a dedicated RPC-TLS PKI was to appear), but is useful to have
available for when it's needed.  This would presumably be under the
1.3.6.1.5.5.7.3 arc, and the referenced documents for existing allocations
usable as a template for what text to put in.

Section 8.1

Isn't it codepoint squatting to claim auth flavor 7 before IANA has
allocated it?  (This is usually a Discuss-level issue, but that part is too
long already so I left it here.)

Section 9.1

RFC 7258 doesn't seem like it needs to be normative.

Appendix A

Maybe link to draft-dnoveck-nfsv4-security-needs for further (extensive!)
discussion of the weaknesses of AUTH_SYS?

   3.  The use of 32-bit unsigned integers as user and group identifiers
       is problematic because these data types are not cryptographically
       signed or otherwise verified by any authority.

Also problematic due to the need for database consistency between
client/server.