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

[Chuck Lever <[e-mail]>]

Hi Erik-

> On Jul 1, 2020, at 3:24 PM, Erik Kline <[e-mail]> wrote:
> 
>>> * 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.
> 
> This might be something worth a few sentences.

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.


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

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