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

[Chuck Lever <[e-mail]>]

> On Apr 12, 2020, at 12:32 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> 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?

Yes this explanation does help, thank you! rpc-tls requires the use of TLS
1.3 or later, so it needn't be concerned with the TLS 1.2 renegotiation
case at all.

The RPC-on-TLS protocol already assumed only a single TLS session per
connection. It will simplify the text, I think, that the multiple
session case, though not supported, is right off the table.

Within the next day or two I intend to post updated text for Sections 4.1
and 5.1, based on the conversation from the past few days, for review and
comment.


--
Chuck Lever