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.

Alvaro Retana No Objection

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 ]


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

Martin Vigoureux No Objection

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?

Robert Wilton 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.

Warren Kumari 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,




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

(Magnus Westerlund; former steering group member) Yes

Yes ( for -08)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -08)

(Barry Leiba; former steering group member) No Objection

No Objection ( for -08)

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -08)