Subject: [nfsv4] Martin Duke's No Objection on draft-ietf-nfsv4-rpc-tls-09: (with COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Tue, 20 Oct 2020 07:04:38 -0700

Martin Duke has entered the following ballot position for
draft-ietf-nfsv4-rpc-tls-09: No Objection

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/

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

Thanks for addressing my DISCUSS about Early Data.

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