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: 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?

Tom.