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

[Chuck Lever <[e-mail]>]

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


--
Chuck Lever