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

[Chuck Lever <[e-mail]>]

> 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.


--
Chuck Lever