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

[Roman Danyliw via Datatracker <[e-mail]>]

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

** Despite Section 5.0 stating that only TLS v1.3+ can be used, there are two
references to TLS v1.2 mechanisms:

-- Section 5.0. Per “Implementations MUST support certificate-based mutual
authentication.  Support for TLS-PSK mutual authentication [RFC4279] is
OPTIONAL”.  Shouldn’t Section 2.2.2 or 4.2.11 of RFC8446 be used instead?

-- Section 5.2.4.  The token binding mechanism suggested here, RFC8471, only
applies to TLS v1.2.  The expired draft-ietf-tokbind-tls13 provides the TLS
v1.3 mechanism.

** Section 7.4.  Per “When using AUTH_NULL or AUTH_SYS, both peers are required
to have DNS TLSA records and certificate material …”, what is “certificate
materials”?  Can this guidance please be clarified (and perhaps related to the
options specified in Section 5.2).


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

Thank you for addressing the early SECDIR review items (and thank you Derrell
Piper and Alan Alan DeKok for doing them)

** Section 1.  Per “Encryption by Default: Transport encryption can be enabled
without … generating additional keying materials”, I’m not sure that this is
accurate if the server and clients need to be keyed with certificates or PSK
for TLS

** Section 4.1. Per “Policy settings on the RPC-over-TLS-enabled peer determine
whether RPC operation continues without the use of TLS or RPC operation is not
permitted.”, I had trouble parsing this sentence.

** Section 4.1.  Per “RPC operation can continue …”, it might be worth
repeating what was stated earlier that  “[t]he RPC operation can continue if
permitted by local policy …”

** Section 5.2.1.  Per “For services accessed by their network identifiers
(netids) and universal network addresses (uaddr), the iPAddress subjectAltName
SHOULD be present in the certificate and must exactly …”, why not a normative
MUST?

** Section 5.2.1.  Per “For example, if the Issuer is not in a trusted set of
Issuers, the RPC server may decline to perform RPC transactions with this
client.”, wouldn’t the TLS connection fail in this case and not even get to
whatever authorization logic the RPC server might have?

** Section 5.2.1.  Per “As a suggestion, at least the following parameters of
the X.509 client certificate SHOULD be exposed … Originating IP address”, how
exactly should this IP address be exposed in the certificate, or is this
intended to be the IP address of the peer which presented the certificate?

** Section 5.2.2 and 5.2.4.  Both 5.2.1 and 5.2.3 described what information
should be exposed by implementations.  These sections omit that information. 
For example, I would have expected Section 5.2.4 to discuss Token Binding IDs

** Section 5.2.2.  Is there any MTI guidance on the kinds of digests to support
for these fingerprints?

** Section 5.2.4.  Are there any MTI parameters for the token binding to
specify?

** Section 7.3.  Per “… it is RECOMMENDED that when AUTH_SYS is used, every RPC
client should present authentication materials to RPC servers …”, is this the
same thing as saying that when AUTH_SYS is used a mutual authentication
TLS-scheme is RECOMMENDED?  I concur with this approach.  I would just
recommended saying that explicitly.

** Section 7.4.  Is there a reason not to use normative language in this
section?  Specifically, RECOMMENDED for the first bullet and SHOULD for the
second.

** Editorial Nits:
-- Section 5.  Typo. s/Similary/Similarly/

-- Section 7.1.2. Typo. s/connnection/connection/