Towards Remote Procedure Call Encryption by Default
draft-ietf-nfsv4-rpc-tls-11

[[ questions ]]

* Can/should the same AUTH_TLS w/ NULL RPC check be done on the rpcbind
  (portmapper) service as well?

* What mechanism guarantees that (D)TLS traffic can always and easily be
  distinguished from RPC traffic on the same port?


[[ nits ]]

[ section 5.1.1 ]

* "When operation is complete" ... In addition to a grammar tweak, you
  might repeat a few choice words from section 7.2 about the ability to
  send multiple requests over a connection.

[ section 7.4 ]

* s/RCPSEC_GSS/RPCSEC_GSS/

I'm having trouble parsing the first paragraph of Section 4.1.

Thank you for including Section 6.

The REQUIRED in Section 7.1 isn't actually an interoperability concern, is it?

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

Thank you for addressing by DISCUSS and COMMENT items.

Thank you for the work put into this document. 

Please find below a couple on non-blocking COMMENTs.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
As section 4.2 specifies the use of at least server-side authenticated TLS session, I wonder why the abstract contains 'opportunistic encryption'.

-- Section 4.1 --

"(D)TLS-protected RPC" while DTLS was never expanded before... or did I miss it ?

-- Section 6.3 --
Just puzzled by "No comments from implementors" about Hammerspace while one author is affiliated with Hammerspace.

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