Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt

[Chuck Lever <[e-mail]>]

> On Mar 26, 2019, at 3:05 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> On Tue, Mar 26, 2019 at 09:56:10AM -0400, Chuck Lever wrote:
>> 
>> 
>>> On Mar 25, 2019, at 4:44 PM, Mkrtchyan, Tigran <[e-mail]> wrote:
>>> 
>>> 
>>> 
>>> ----- Original Message -----
>>>> From: "Chuck Lever" <[e-mail]>
>>>> To: "Tigran Mkrtchyan" <[e-mail]>
>>>> Cc: "NFSv4" <[e-mail]>
>>>> Sent: Monday, March 25, 2019 2:44:32 PM
>>>> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt
>>> 
>>>>> On Mar 25, 2019, at 4:53 AM, Mkrtchyan, Tigran <[e-mail]> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> Hi Chuck,
>>>>> 
>>>>> By working on our implementation we got a following questions:
>>>>> 
>>>>> what should server do when a client requests startTLS twice? Fail
>>>>> with an auth error or just ignore?
>>>> 
>>>> I don't have a ready answer, but seems to me your TLS library
>>>> might have an opinion. Can a web browser be made to generate
>>>> a second STARTTLS to see what the behavior is like?
>>>> 
>>>> Is there any guidance in RFC 8446 or its antecedants?
>>> 
>>> Looks like LDAP have that case clearly specified rfc2830:
>>> 
>>> 2.3:
>>> 
>>> ...
>>> 
>>>  If the Start TLS extended request was not successful, the resultCode
>>>  will be one of:
>>> 
>>>  operationsError  (operations sequencing incorrect; e.g. TLS already
>>>                   established)
>>> 
>>> 3.1:
>>> 
>>> ...
>>> 
>>>  The client MAY send the Start TLS extended request at any time after
>>>  establishing an LDAP association, except that in the following cases
>>>  the client MUST NOT send a Start TLS extended request:
>>> 
>>>    - if TLS is currently established on the connection, or
>>> 
>>> You may adopt a similar wording to rpc-over-tls. However, what about UDP and
>>> retransmits?
>> 
>> UDP will use DTLS.
>> 
>> My hesitance is that STARTTLS is part of the TLS protocol, and we're
>> not specifying that here, we're only using it. Surely TLS has a proper
>> mechanism for managing this situation.
> 
> As others have covered, this is a matter for the application that is trying
> to use the opportunistic TLS.
> 
>> I would like to see a recent RFC that covers your case. RFC 6614 appears
>> to require TLS negotiation to occur immediately after the underlying
>> transport connection is established, and never later. Is that what you
>> want?
> 
> Since STARTTLS for NFS doesn't exist other than this draft (right?), you
> have a pretty clean slate to work from and should be able to set tight
> bounds on usage, disallowing a lot of the potential complications.
> 
> So, requiring at most one STARTTLS, and for that to be the first RPC (or
> othr traffic) after the transport connection is established, seems
> simplest.  STARTTLS when TLS is already active can be rejected, and
> STARTTLS after non-TLS RPCs have occurred as well.  That would be my
> recommendation, at least (having not really read the draft,at least
> recently).

Thanks, after this explanation and reading the wiki page that Olga sent,
I think I understand what text needs to be added.


--
Chuck Lever