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

[Chuck Lever <[e-mail]>]

Hi Craig-

I don't know of a functional dependency, but someone who would know best
(perhaps a member of the IESG, I don't remember exactly whom) requested that
this document REQUIRE the known most secure version of TLS, which at present
is 1.3, to avoid certain known security exposures in 1.2 and enable the use
of token binding as an OPTIONAL means of peer authentication.

The requirement has been present since draft-ietf-nfsv4-rpc-tls-00 was
submitted a year ago, but is absent in the predecessor personal draft.

I believe RPC-on-TLS can be implemented on TLS 1.2. It won't be spec-compliant
in that case, and it won't be as secure.


> On Apr 12, 2020, at 6:30 PM, Craig Everhart <[e-mail]> wrote:
> 
> Is there a reason to require TLS 1.3?  TLS 1.2 isn’t old in many contexts.
> 
> Best,
> Craig
> 
> 
>> On Apr 12, 2020, at 12:52 PM, Chuck Lever <[e-mail]> wrote:
>> 
>> 
>> 
>>> 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
>> 
>> 
>> 
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever