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

[Chuck Lever <[e-mail]>]

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.


> You could in theory make a TLS variant that
> did it anyway, but you'd have to add a protocol field for a connection
> identifier and/or do trial decryption on each TLS record, which doesn't
> really make sense.
> 
> -Ben

--
Chuck Lever