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

[Trond Myklebust <[e-mail]>]

On Thu, 28 Mar 2019 at 20:35, Tom Talpey
<ttalpey=[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?

Anything advertised by the portmapper is as vulnerable to man in the
middle attacks as the current proposal. If your attacker can intercept
connections to the NFS server, then they can do the exact same thing
to the portmapper. Furthermore, using the portmapper doesn't pass
Tigran's requirement for fast discovery because it may require the
setup of a second TCP connection (unless you are using UDP) and it
definitely requires an extra RPC call.

The proposal just to use a different well known port would work,
however it messes up pNFS for us because the MDS would have to
advertise both ports to the client if it wants to ensure that the
client can connect.

Cheers
  Trond