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

[Chuck Lever <[e-mail]>]

> On Apr 10, 2020, at 8:40 AM, David Noveck <[e-mail]> wrote:
> 
> 
> 
> On Thu, Apr 9, 2020, 3:28 PM Chuck Lever <[e-mail] <mailto:[e-mail]>> wrote:
> 
> > On Apr 1, 2020, at 4:27 AM, Magnus Westerlund <[e-mail] <mailto:[e-mail]>> wrote:
> > 
> > 8. Section 5.1.2:
> >  
> >    As soon as a client
> >    initializes a socket for use with an unfamiliar server, it uses the
> >    mechanism described in Section 4.1 to discover DTLS support and then
> >    negotiate a DTLS session.
> >  
> > So first of all is the usage of TLS for TCP completely separate from using DTLS over UDP?
> 
> It seems that that was Chuck's intention and was the way I have been reading the spec.  However, it is not explicitly stated right now and does need to be clarified as part of the response to Magnus's review.
>    
> So having determined TLS support for TCP does not indicate the same for UDP?
> 
> I would hope not.   Ad a practical matter, there are many servers that would not be all
> interested in implementing DTLS, given that UDP is not allowed by NFSv4.   Tying this
> to TLS support would haveth effect of increasing the effort to provide support without
> correspondingly increasing the benefit.
> 
> Even though we cleary don't have consensus on the TCP-connection-sharing, we might
> well have consensus on this. 
> 
> And is it in any cases possible to skip the initial RPC null request with AUTH_TLS authentication and go directly to negotiate TLS after support has been determined with a server? 
> 
> rpc-tls does not discuss this a possibility.  On the other hand it does not forbid it either.
> Addressing this whole area is part of the needed clarification.
> 
> rpc-tls is written assuming opportunistic TLS access is the only means 
> of RPC-TLS  access but it never states that explicitly.  As a result, Magnus, 
> quite reasonably, asks whether there are cases in which opportnistic acces 
> might be used as an information-gathering mechasnism to support non-
> opportunistic TLS access.
>     
> There seems to be a high-order bit here that rpc-tls does not currently
> address. Leaving it unaddressed could introduce significant
> interoperability issues.
> 
> I don't think that's the high order bit but I agree it does need to be resolved :-(
>  
> Our new STARTTLS RPC NULL probe carries an RPC program.
> 
> It does.
>  
> Does a successful
> probe mean that the RPC server supports TLS for every RPC program on that
> that host? on that port? Or just for the program used in the probe? I think
> it means TLS can be used only with the RPC program used in that probe, 
> 
> While I read things that way, I'm not committed to that reading.   Given the lack
> of consensus on that point, I want to understand how important that
> reading is to you.

At this point I'm simply trying to align my understanding and the text in rpc-tls
with the WG's consensus. So, I'm not strongly advocating this interpretation.
Think of it, I guess, as a strawman.


> and only for the lifetime of that connection. (ie each connection has to
> do the probe).
> 
> I think that part is the high-order bit.

Yes, probably so.


> I'm hoping we might be able to get 
> consensus on that since I feel that changing that might be more disruptive
> than restrictions on the program used which run into the contentious
> connection-sharing issue.
>  
> Since the STARTTLS RPC NULL probe is always done in clear-text, that means
> a second probe cannot be done once a TLS session has been established on
> a connection.
> 
> Right.
>  
> (A separate connection must be established to initiate a
> second TLS session).
> 
> That's not made clear in rpc-rls but I hope that everyone is OK with that
> being made explicit.

IMO rpc-tls should be updated to make it clear.

However, it needs to be made clear in a way that does not preclude the
possibility of having multiple sessions per connection in a future RPC-on-TLS
iteration.


> Therefore with RPC-on-TLS we do not allow multiple RPC programs to share
> a TLS session.
> 
>  What is the justification for the "therefore"?

See my response to Trond: it was a thought experiment that reached this
conclusion.


> Although we may reasonably conclude that a successful STARTTLS indicates
> that you do may support for the specified program and version, I don't see that
> you are forced to conclude that no other program is supported.   I read it that
> way because the connection sharing case isn't important to me, but, since it appears
> that we can't reach consensus on that, we might want to consider whether being
> more relaxed on that point is a viable path forward.

Using the existing PROG_UNAVAIL accept status seems appropriate to enable
clients to work through this issue. I proposed some new text in my response to
Trond that leads in that direction.


> And we do not allow multiple RPC-on-TLS sessions per TCP
> connection.
> 
> Yes.
>  
> For DTLS, the STARTTLS probe has to be done for each RPC program on each
> server. Only that one RPC program can use the established DTLS session.
> 
> I hope we can achieve consensus on that. 
> 
> This means RPC-on-TLS robs us of some TCP connection sharing opportunities.
> 
> I don't feel robbed, but it appears some people do :-(
>  
> Is there consensus on this,
> 
> I appears not.
>  
> or should these design points be revisited?
> 
> Not all of them,   I would hope we can disturb as few decisions already made as possible.

That is my hope too.


--
Chuck Lever