Towards Remote Procedure Call Encryption By Default
Note: This ballot was opened for revision 08 and is now closed.
Benjamin Kaduk (was Discuss) Yes
Comment (2020-11-02 for -10)
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)
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.