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

[David Noveck <[e-mail]>]

Regarding the proposal to reference draft-dnoveck-nfsv4-security-needs, I
need to point out that the  current plan is not to publish the successor
working group document as an informational RFC. It is intended for internal
working group use


On Wed, Jul 8, 2020, 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:
> ----------------------------------------------------------------------
>
> 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.
>
>
>
>