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

[Erik Kline <[e-mail]>]

Chuck,

On Thu, Jul 2, 2020 at 8:30 AM Chuck Lever <[e-mail]> wrote:
>
> 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

LGTM, thank you.

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

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.

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

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

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

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