Summary: Has a DISCUSS. Needs 8 more YES or NO OBJECTION positions to pass.
This presumably a trivial fix but I think it's important enough to be a DISCUSS: I think the document needs some discussion of the security properties of TLS1.3 early data over TCP, if only to refer to Section 8 of RFC 8446 (replay) and mention that it is not forward-secure, unlike the rest of the payload.
Thank you for this draft. I fully support bringing TLS into more use cases of this type. Some comments: Sec 1. "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. Administrators must provide keying material for each RPC client, including transient clients. 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." The text above says that something is still in use because..., and then mentions two things that are bad. I think the two items are supposed to refer to GSS? Sec 4.2 This sure looks like normative text, so s/must not/MUST NOT "... utilize the remote TLS peer identity for RPC user authentication" Sec 5.1.2 Similarly, s/should/SHOULD "...employ ConnectionIDs of at least 4 bytes in length."
[[ questions ]] * Can/should the same AUTH_TLS w/ NULL RPC check be done on the rpcbind (portmapper) service as well? * What mechanism guarantees that (D)TLS traffic can always and easily be distinguished from RPC traffic on the same port? [[ nits ]] [ section 5.1.1 ] * "When operation is complete" ... In addition to a grammar tweak, you might repeat a few choice words from section 7.2 about the ability to send multiple requests over a connection. [ section 7.4 ] * s/RCPSEC_GSS/RPCSEC_GSS/