Re: [nfsv4] questions w.r.t RPC-over-TLS draft

[Chuck Lever <[e-mail]>]

> On Jan 24, 2020, at 6:03 PM, Rick Macklem <[e-mail]> wrote:
> 
> Benjamin Kaduk wrote:
>> On Wed, Jan 22, 2020 at 10:51:04PM +0000, Rick Macklem wrote:
>>> Mkrtchyan, Tigran wrote:
>>> [stuff snipped]
>>>>> Chuck Lever wrote:
>>>>>> It seems to me the new text clearly allows an unencrypted NULL RPC at any
>>>>>> time. I'm not sure that's even feasible, but it's an implementer's choice.
>>>>> I wrote:
>>>>> Yea. I'm not sure if this is feasible either (at least for TCP), but NULL RPCs
>>>>> seem
>>>>> harmless, so I think the current wording is ok, at least for reliable ordered
>>>>> transports
>>>>> like TCP.
>>>> 
>>>> 
>>>> I am pretty sure, that once TLS session is established, you can't sent any other
>>>> requests outside of it.
>>> Yea, the only case I can think of where it might be possible for TCP is after an
>>> SSL_shutdown is done on the socket. I also haven't looked at the RFC enough to figure out
>> 
>> "SSL_shutdown is done on the socket" translates (roughly) to TLS-speak as
>> "both endpoints send and receive "close_notify" alerts from the peer", and
>> in theory the protocol can support this but evidence of real-world
>> functionality is quite sparse.  (Many implementations do not really do
>> "close_notify" quite according to the spec, and trying to wait for it from
>> the peer is pretty dicey.)
> Yes. According to the OpenSSL doc, you can check for a 0 return from the first SSL_shutdown()
> call and do a second one in that case, to make sure you get the close_notify from the peer.
> None of the sample code I've found (some in the OpenSSL doc) does that, or even checks
> the return value from the SSL_shutdown() calls.
> 
> Just to be clear, I don't see any need for unencrypted RPC traffic to work on the socket
> after the TLS handshake starts.
> 
> I also don't care if NULL RPCs with AUTH_NULL are allowed before the NULL RPC with
> AUTH_TLS is done.
> The draft said "no unencrypted RPC traffic", whereas the NULL RPC with AUTH_TLS is
> just that, so it seems there needs to be some rewording done.
> 
> I do think that the draft should clearly state:
> 1 - A NULL RPC with AUTH_TLS that gets a successful reply with "STARTTLS" in the
>     reply verifier is a "STARTTLS command, with the TLS handshake following immediately
>     after this".
> 2 - What, if any, unencrypted RPC traffic is allowed to precede the NULL RPC with AUTH_TLS.

I'm willing to make some alterations. I don't think we're changing any
consensus decisions here, so probably the best approach would be for me
to submit another revision after we resolve the wording issues.

Does that sound right, NFSv4 chairs?


>>> if unencrypted (I think it calls them cleartext) TLS records can be mixed into encrypted >ones.
>> 
>> They can't.  (If there was a severe need a way could be found, e.g., with a
>> new record type, but there would be a lot o...
> I can't see any reason to do this.

Mixing might not be an issue on TCP connections, but I'm wondering how to
deal with DTLS.


--
Chuck Lever