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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-nfsv4-rpc-tls-09: 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:
----------------------------------------------------------------------

Thank you for the updates in the -09; they address all my previous Discuss points
(from the -08).  Unfortunately, there is one more issue that was introduced in the
update and will need to be resolved:

While I appreciate the efforts to find appropriate external specifications to
reference, I do not believe that an id-kp-rpcTLSServer certificate
is a Resource Certificate per RFC 6487 -- that specification deals with
the RPKI (Resource PKI) used to authenticate IP address assignment, but
the RPKI is an entirely separate PKI than the Internet PKI ("PKIX").  I
think we should drop that sentence entirely.


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

I also have a few non-discuss-level comments on the -09.

Section 5.1.2

   Sending a TLS Closure Alert terminates a DTLS session.  Because
   neither DTLS nor UDP provide in-order delivery, after session closure
   there can be ambiguity as to whether a datagram should be interpreted
   as DTLS protected or not.  Therefore receivers MUST discard datagrams
   exchanged using the same 5-tuple that just terminated the DTLS
   session for 60 seconds.

The mandatory waiting period before reusing a 5-tuple is a fine
mechanism for resolving the ambiguity.  However, I worry that
prescribing the exact 60-second timeout is over-prescriptive, and it
might be better to say something like "MUST discard [...] for a
sufficient length of time to ensure that retransmissions have ceased and
packets already in the network have been delivered.  In the absence of
more specific data, a period of 60 seconds is expected to suffice."

Section 5.2.1.1

   The current document defines two new KeyPurposeId values: one that
   identifies the RPC-over-TLS peer as an RPC client, and one that
   identifies the RPC-over-TLS peer as an RPC server.  Additional
   KeyPurposeId values related to RPC-over-TLS may be specified in
   subsequent Standards Track documents.

Perhaps I am just forgetting a previous discussion, but I am not sure
why this is apparently limited to Standards-Track documents -- the
normal PKIX convention is that anyone can define whatever EKU they want
and specify the semantics of it.

Section 7.1.2

   Appendix C of [RFC8446] discusses precautions that can mitigate
   exposure during the exchange of connection handshake information and
   TLS certificate material that might enable attackers to track the RPC
   client.

I suggest adding another sentence at the end: "When PSK authentication
is used, the PSK identifier is exposed during the TLS handshake, and can
be used to track the RPC client."  I'm a bit surprised that this fact
was not stated in the referenced appendix, but didn't find it there!