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

[Chuck Lever <[e-mail]>]

Hi Ben-

I've browsed all your replies so far. Haven't seen anything
outlandish. Give me a few days to digest them thoroughly and
come up with appropriate replacement text.

Glad you are on the mend!



> On Oct 8, 2020, at 5:56 PM, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> 
> 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!
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever