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

[Benjamin Kaduk <[e-mail]>]

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).

-Ben