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

[Tom Talpey <[e-mail]>]

> -----Original Message-----
> From: Chuck Lever <[e-mail]>
> Sent: Friday, March 29, 2019 10:18 AM
> To: Tom Talpey <[e-mail]>
> Cc: Lars Eggert <[e-mail]>; NFSv4 <[e-mail]>
> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt
> 
> 
> 
> > On Mar 28, 2019, at 8:35 PM, Tom Talpey <[e-mail]> wrote:
> >
> >> -----Original Message-----
> >> From: Chuck Lever <[e-mail]>
> >> Sent: Thursday, March 28, 2019 3:43 PM
> >> To: Tom Talpey <[e-mail]>
> >> Cc: Lars Eggert <[e-mail]>; NFSv4 <[e-mail]>
> >> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-
> 01.txt
> >>
> >>
> >>> On Mar 26, 2019, at 1:58 PM, Tom Talpey <[e-mail]>
> wrote:
> >>>
> >>>> -----Original Message-----
> >>>> From: nfsv4 <[e-mail]> On Behalf Of Chuck Lever
> >>>> Sent: Tuesday, March 26, 2019 1:52 PM
> >>>> To: Lars Eggert <[e-mail]>
> >>>> Cc: NFSv4 <[e-mail]>
> >>>> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-
> >> 01.txt
> >>>>
> >>>>
> >>>>
> >>>>> On Mar 26, 2019, at 12:35 PM, Lars Eggert <[e-mail]> wrote:
> >>>>>
> >>>>> On 2019-3-26, at 17:33, Lars Eggert <[e-mail]> wrote:
> >>>>>> Also note that STARTTLS is somewhat less secure than running TLS
> >> directly.
> >>>> See for example Section 6 of RFC3207:
> >>>>>>
> >>>>>>  A man-in-the-middle attack can be launched by deleting the "250
> >>>>>>  STARTTLS" response from the server.  This would cause the client not
> >>>>>>  to try to start a TLS session.  Another man-in-the-middle attack is
> >>>>>>  to allow the server to announce its STARTTLS capability, but to alter
> >>>>>>  the client's request to start TLS and the server's response.
> >>>>>>
> >>>>>>  ...
> >>>>>
> >>>>> And RFC8314 recommends (for mail) that "implicit TLS" should be used
> >>>> instead of STARTTLS.
> >>>>
> >>>> Perhaps that is what we should require for RPC on TLS;
> >>>> that is, "STARTTLS MUST NOT be used"?
> >>>
> >>> It's a fine requirement, but there may need to be a justification for the
> MUST.
> >>>
> >>> It's important to note that such a requirement means you'll need to
> allocate
> >>> a new port number for such connections. This would apply to any upper
> >>> layer using the new RPC flavor, which in turn might impact the
> portmapper.
> >>> Note, it may also have implications on the proposed negotiation. If TLS is
> >>> a "done deal", negotiating the auth flavor may be moot.
> >>
> >> We could create a new netid for this purpose.
> >>
> >> Advertise an RPC program with this new netid, and no STARTTLS would
> >> be needed. The client simply connects and begins TLS negotiation.
> >
> > But, the current draft proposes using a new AUTH_TLS exchange, which
> > if successful allows the client to perform a STARTTLS. If you define a netid
> > and/or port number, the client would simply start in TLS, prior to even
> > sending its first RPC.
> >
> > Would that not simply make the whole draft unnecessary?
> 
> No. The current revision places a number of restrictions on how TLS
> is used, and that is needed in any case. But, the draft could define
> new netids and reserve a new port number for making portmapper requests
> using TLS.
> 
> Anyway, this is a strawman. I wanted to bring it up to ensure we are
> happy with using STARTTLS.

Ok. I definitely feel that STARTTLS, or some form of dynamic TLS enablement,
is important here. For one thing, not all transports support TLS, for example RDMA.
By the same token, servers may not support TLS-only services on new ports, or
new portmappers, and allocating new ports for existing RPC services is just
as problematic.

I do agree that MITM protection is critical if STARTTLS is to be used. Perhaps
the RPC AUTH exchange could address this protection, by extending the
AUTH_TLS exchange. This may require messages to be sent both before and
after establishing TLS. The SMB3 protocol, for example, uses something it
calls VALIDATE_NEGOTIATE for a similar purpose.

I look forward to the next draft.

Tom.