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

Note: This ballot was opened for revision 08 and is now closed.

Benjamin Kaduk (was Discuss) Yes

Comment (2020-11-02 for -10)
No email
send info
Thank you for all the updates in response to my earlier reviews.

One final note (no response necessary):

Section 1

The -10 has "must typically" where I (thought I) suggested "typically must".
If that's intentional, that's fine; I just wasn't 100% sure at first look.

Magnus Westerlund Yes

Deborah Brungard No Objection

Alissa Cooper No Objection

Roman Danyliw (was Discuss) No Objection

Comment (2020-09-18 for -09)
No email
send info
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.

Martin Duke (was Discuss) No Objection

Comment (2020-10-20 for -09)
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."

Erik Kline No Objection

Comment (2020-06-29 for -08)
[[ 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/

Murray Kucherawy No Objection

Comment (2020-07-05 for -08)
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?

Warren Kumari No Objection

Barry Leiba No Objection

Alvaro Retana No Objection

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2020-07-03 for -08)
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.

Robert Wilton No Objection