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

[Martin Duke via Datatracker <[e-mail]>]

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

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.


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

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