Subject: Re: [nfsv4] Erik Kline's No Objection on draft-ietf-nfsv4-rpc-tls-08: (with COMMENT)

From: Chuck Lever <[email-masked]>
Date: Wed, 1 Jul 2020 09:56:53 -0400

Hi Erik-

Thanks for your comments!

> On Jun 30, 2020, at 12:31 AM, Erik Kline via Datatracker <[email-masked]> wrote:
> 
> Erik Kline has entered the following ballot position for
> draft-ietf-nfsv4-rpc-tls-08: No Objection
> 
> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> [[ questions ]]
> 
> * Can/should the same AUTH_TLS w/ NULL RPC check be done on the rpcbind
>  (portmapper) service as well?

Yes. It would work like any RPC program that uses a well-known destination
port.

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

The document does not specify any mechanism for making that distinction
for UDP. The server would have to match ingress datagrams that appear to
be DTLS traffic to existing DTLS session state. The server treats datagrams
that fail to match as RPC messages.

For TCP, once a TLS session is established on a connection, the client is
forbidden from mixing TLS traffic with unprotected traffic on that
connection. To send unprotected traffic after establishing a session, a
client would have to establish a separate TCP connection that does not
have a TLS session.

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

I don't understand this comment. Section 7.2 is about user privilege
separation. What did you have in mind?

> [ section 7.4 ]
> 
> * s/RCPSEC_GSS/RPCSEC_GSS/

Thanks, will fix.

--
Chuck Lever

---

From: Erik Kline <[email-masked]>
Date: Wed, 1 Jul 2020 12:24:30 -0700

> client would have to establish a separate TCP connection that does not

This might be something worth a few sentences.

> separation. What did you have in mind?

I was just thinking that it would be useful to add a sentence to
dispel any ideas that it's a "one TLS connection, one request" system.
7.2 explicitly talks about sending multiple requests per session:

"""
   Moreover, client implementations are free to transmit RPC requests
   for more than one RPC user using the same TLS session.
"""

---

From: Chuck Lever <[email-masked]>
Date: Thu, 2 Jul 2020 11:30:48 -0400

Hi Erik-

> On Jul 1, 2020, at 3:24 PM, Erik Kline <[email-masked]> wrote:
> 

I agree that the DTLS case needs some guidance language because there
are socket resources shared between protected and unprotected datagrams.

OLD:

   DTLS support for an RPC program on a particular port.  It then
   negotiates a DTLS session.

   Multi-homed RPC clients and servers may send protected RPC messages
   via network interfaces that were not involved in the handshake that

NEW:

   DTLS support for an RPC program on a particular port.  It then
   negotiates a DTLS session.

   The current document does not specify a mechanism that enables a
   server to distinguish between DTLS traffic and unprotected RPC
   traffic directed to the same port.  To make this distinction, each
   peer matches ingress datagrams that appear to be DTLS traffic to
   existing DTLS session state.  A peer treats any datagram that
   fails the matching process as an RPC message.

   Multi-homed RPC clients and servers may send protected RPC messages
   via network interfaces that were not involved in the handshake that

However I'm not so sure about the TCP case. Why would a client want to
send a mix of protected and unprotected traffic on the same connection?
In any event, I propose this addition:

OLD:

   server will subsequently reject the same RPC program on a different
   TCP connection.

   Reverse-direction operation occurs only on connected transports such
   as TCP (see Section 2 of [RFC8166]).  To protect reverse-direction
   RPC operations, the RPC server does not establish a separate TLS
   session on the TCP connection, but instead uses the existing TLS
   session on that connection to protect these operations.

NEW:

   server will subsequently reject the same RPC program on a different
   TCP connection.

   Once a TLS session is established on a connection, TLS forbids the
   client from mixing session-protected traffic with unprotected RPC
   traffic on that connection.  To exchange unprotected RPC traffic with
   a server while a TLS session is established, the client establishes a
   separate TCP connection that does not have a TLS session.

   Reverse-direction operation occurs only on connected transports such
   as TCP (see Section 2 of [RFC8166]).  To protect reverse-direction
   RPC operations, the RPC server does not establish a separate TLS
   session on the TCP connection, but instead uses the existing TLS
   session on that connection to protect these operations.

>   for more than one RPC user using the same TLS session.

The Section 7.2 language assumes one TCP connection is used for many
RPC transactions because that's an optimization that's common to
existing RPC-over-TCP client implementations.

The point of 7.2 is that there is a security-related reason why this
optimization is not appropriate. A distinct TLS session is needed for
each security domain on a client (think client multi-tenancy). That
is orthogonal to the general case you are thinking of.

Though not a typical use case, it's totally valid to establish a TLS
session for one or a handful of RPC operations. But I think what you
are saying is the document might be read to suggest a TLS(TCP) session
is valid for the exchange of only one RPC transaction, and of course
that is not at all the case.

I propose the following change to Section 4.1, but perhaps more is
needed:

OLD:

   Once the TLS session handshake is complete, the RPC client and server
   have established a secure channel for communicating.  A successful
   AUTH_TLS probe on one particular port/transport tuple never implies
   RPC-over-TLS is available on that same server using a different port/
   transport tuple.

NEW:

   Once the TLS session handshake is complete, the RPC client and server
   have established a secure channel for exchanging RPC transactions.  A
   successful AUTH_TLS probe on one particular port/transport tuple
   never implies RPC-over-TLS is available on that same server using a
   different port/transport tuple.

I hope the following change addresses the grammar error you noticed:

OLD:

   When operation is complete, an RPC peer terminates a TLS session by
   sending a TLS Closure Alert and may then close the TCP connection.

NEW:

   When operation is complete, an RPC peer terminates a TLS session by
   sending a TLS Closure Alert.  It may then close the TCP connection.

--
Chuck Lever

---

From: Erik Kline <[email-masked]>
Date: Thu, 2 Jul 2020 11:08:57 -0700

Chuck,

>    via network interfaces that were not involved in the handshake that

LGTM, thank you.

>    session on that connection to protect these operations.

I hadn't thought about trying to mix protected and unprotected
traffic.  This new text seems good though, thank you.

I was more curious about text for how a TCP RPC server identifies TLS
ClientHello from the first of possibly several unencrypted RPCs after
the 3WHS.  And it seems like the same "try to parse a ClientHello else
try to parse an ONC RPC message"  is the recommended approach
(analogous to DTLS above)?  It was a statement to this effect that I
was after.

>    different port/transport tuple.

"transactions" here is plural; it implies to me "more than one over
the lifetime of the channel".  Perfect.

>    sending a TLS Closure Alert.  It may then close the TCP connection.

I was thinking of something like s/When operation is complete/When all
operations are complete/.

Sort of related: I'm not sufficiently familiar with RPC over TCP: does
a client ever close a TCP session while there are RPCs in flight (i.e.
as a matter of normal operations and not extraordinary circumstances)?
 If so, "... are complete" above might not be strictly correct.  I'll
defer to y'all.

Thanks,
-ek

---

From: Chuck Lever <[email-masked]>
Date: Thu, 2 Jul 2020 14:26:24 -0400

> On Jul 2, 2020, at 2:08 PM, Erik Kline <[email-masked]> wrote:
> 
> Chuck,
> 

> (analogous to DTLS above)?  It was a statement to this effect that I

Understood. I'll propose something in a follow-up e-mail.

> If so, "... are complete" above might not be strictly correct.  I'll

Either peer is permitted to close a TCP connection while there are
outstanding RPC transactions.

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Fri, 3 Jul 2020 11:57:33 -0400

> On Jul 2, 2020, at 2:26 PM, Chuck Lever <[email-masked]> wrote:
> 

I propose updating the first paragraph of Section 5.1.1:

OLD:

   The use of the Transport Layer Security (TLS) protocol [RFC8446]
   protects RPC on TCP connections.  Typically, once an RPC client
   completes the TCP handshake, it uses the mechanism described in
   Section 4.1 to discover RPC-over-TLS support for that connection.  If
   spurious traffic appears on a TCP connection between the initial
   clear-text AUTH_TLS probe and the TLS session handshake, receivers
   MUST discard that data without response and then SHOULD drop the
   connection.

NEW:

   The use of the Transport Layer Security (TLS) protocol [RFC8446]
   protects RPC on TCP connections.  Typically, once an RPC client
   completes the TCP handshake, it uses the mechanism described in
   Section 4.1 to discover RPC-over-TLS support for that connection.
   Until an AUTH_TLS probe is done on a connection, the RPC server
   treats all traffic as RPC messages.  If spurious traffic appears on a
   TCP connection between the initial clear-text AUTH_TLS probe and the
   TLS session handshake, receivers MUST discard that data without
   response and then SHOULD drop the connection.

--
Chuck Lever

---

From: Erik Kline <[email-masked]>
Date: Fri, 3 Jul 2020 13:43:46 -0700

>    response and then SHOULD drop the connection.

Ah, I failed to properly grasp that this needs to happen for each and
every new TCP connection.  I had assumed (for no good reason
whatsoever) that the AUTH_TLS-ability of a server TCP endpoint could
be cached for subsequent connection speedup.  If that's not happening
then this all makes sense.

I apologize for my confusion and I do like this new text -- it helps
hammer home the point.

Thanks again.