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

[Trond Myklebust <[e-mail]>]

On Thu, 28 Mar 2019 at 22:20, Trond Myklebust <[e-mail]> wrote:
>
> 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.

BTW: The netid proposal does resolve the issue of quick NFSv4.x
migration/replication/referral connections and for pNFS. Assuming your
fs_locations or LAYOUTGET call to the main NFSv4 server is already TLS
protected, then there are no issues with man in the middle. One
downside is that you would presumably then have to define netids for
all protocols that you need to support RPC/TLS.