Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls

[Benjamin Kaduk <[e-mail]>]

On Sun, Apr 12, 2020 at 12:27:14PM -0400, Chuck Lever wrote:
> Hi Ben -
> 
> > On Apr 11, 2020, at 10:37 PM, Benjamin Kaduk <[e-mail]> wrote:
> > 
> > On Fri, Apr 10, 2020 at 03:33:51PM +0000, Rick Macklem wrote:
> >> Chuck Lever wrote:
> >> [stuff snipped]
> >>> Then I started thinking about TCP.
> >>> 
> >>> Since we have implementations that use the same connection to transport
> >>> multiple RPC programs, we have to make a different statement. What should
> >>> that statement be?
> >>> 
> >>> I wondered again about whether it makes sense to permit or encourage
> >>> multiple TLS sessions on the same connection.
> >>> 
> >>> If you wanted to, how would you establish a second TLS session? Because
> >>> of the "no clear-text RPCs after a TLS session has been established"
> >>> stipulation, the client would have to perform a bunch of AUTH_TLS probes
> >>> _before_ sending any ClientHello messages.
> >>> 
> >>> (And in any event we probably want rpc-tls to discuss what should happen
> >>> if there is traffic on the connection between the AUTH_TLS probe and
> >>> the ClientHello message).
> >> I think that multiple AUTH_TLS probes before sending ClientHello
> >> is both difficult to implement and confusing.
> >> 
> >> The AUTH_TLS probe serves two purposes well.
> >> 1 - It establishes whether or not RPC-over-TLS is supported by the server.
> >> 2 - If supported, it triggers a TLS handshake for the first session.
> >> 
> >> If you do want multiple TLS sessions on the same TCP connection (I'll assume TLS
> >> allows this?), then I think a separate kind of AUTH_TLS Null RPC which is done
> > 
> > TLS doesn't really allow this.
> 
> I want to understand how to word the text in rpc-tls. "this" here means
> "multiple TLS sessions on the same TCP connection" ? What happens when
> the client peer sends a second ClientHello message on a connection with
> an established TLS session? I haven't been able to find a firm description
> of how a server is supposed to respond in this case.

There's two possibilities that I see:

(1) the second ClientHello is unencrypted, in which case the server sees a
TLS record whose deprotection fails and aborts the connection

(2) the second ClientHello is encrypted with the current record-protection
keys, in which case a TLS 1.2 server starts the "renegotiation" process and
a TLS 1.3 server aborts the connection for a protocol violation.

TLS 1.2 renegotiation semantics are not particularly well specified, which
is part of why renegotiation was removed from TLS 1.3.  In particular, many
people will argue that that the "renegotiated" handshake would completely
replace the original one in a logical sense, so that only one client
authentication would be active (the latest one).  What is clear is that
only one cryptographic context would be active, so you could not interleave
TLS records on the TCP stream that are protected by different encryption
keys.

Does that help?

-Ben