Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls

[Chuck Lever <[e-mail]>]

Hi Magnus -

> On Apr 6, 2020, at 9:08 AM, Magnus Westerlund <[e-mail]> wrote:
> 
> Hi Chuck,
> 
> So this document is clearly an opportunistic mechanism. And I am not trying to
> push things beyond this in this document. However, I need to understand the
> answers to certain questions that are likely to arise in the IETF last call and
> IESG evaluation. 
> 
> Thanks for clarifying that due to layering, it would be a bad idea for this
> document to demand anything from NFS implementation. The NFS specificaiton
> extension/updates will have to make such requirement. I am fine with conveying
> that message to anyone raising this as an issue.

OK, glad we agree!


> Even on the RPC level, I do think the document can become clearer in that this
> document's solution is strongly recommended to be implemented to improve
> security. It is good that the document do dicsuss how policies can be
> established to move this mechanism beyond just opportunistic. Hinting on the
> likelihood that you will soon be required to support it. 
> 
> Thus, can one in introduce any RECOMMENDED/SHOULD writings on implementation of
> this mechanism for RPC implementors?

One choice is Dave's proposed expansion to the Introduction, but the use of
compliance keywords is usually not appropriate in the Introduction. So it sounds
like you are asking for changes somewhere else in the document...

Perhaps Section 7.1 is the best place, as it directly addresses the shortcomings
of opportunistic security mechanisms.


> Second are there aspect of the non-normative text that can be improved?

Always. Is there a particular example that stands out to you?


> Cheers
> 
> Magnus
> 
> 
> 
> 
> On Sun, 2020-04-05 at 13:58 -0400, Chuck Lever wrote:
>> Going back to Magnus' original concern:
>> 
>>> On Apr 1, 2020, at 4:27 AM, Magnus Westerlund <
>>> [e-mail]> wrote:
>>> 
>>> 13. Requirement on implementation
>>> 
>>> Should this document actually update any or all of the versions of NFS 4 to
>>> mandate implementation support?
>> 
>> IMO the proper place to make fresh requirements on NFSv4 implementations is
>> in NFSv4-specific documents. I would rather not focus this document any more
>> on NFS than it already is. And we have a plan to author and publish one or
>> more NFSv4-specific documents regarding NFS-on-TLS (which will be covered
>> to some extent during our interim meeting).
>> 
>> So, I vote that this document should not update any NFSv4 standards-track
>> documents.
>> 
>> 
>>> From the WG's perspective doesn't it make sense to start demand
>>> implementation support. The mechanism is clearly opportunistic in its
>>> establishment, however the goal here needs to be to get support in as many
>>> places is as possible.
>> 
>> Agreed, but practically speaking, the WG is not in control of
>> implementations.
>> 
>> With the rpc-tls proposal IMO we are trying to walk a very fine line
>> between limiting protocol changes for existing implementations and
>> meeting a critical security need. The opportunistic behavior of this
>> mechanism is a key part of this proposal. And the document describes
>> clearly ways that implementations can make the force the use of TLS.
>> 
>> In other words, I'm hoping rpc-tls provides an easy step forward
>> towards "support in as many places as possible".
>> 
>> 
>>> Thus, sending a clearer signal that NFS 4.x servers and client are expected
>>> to support this should be sent. If not can you clarify what the concerns
>>> are? Because we are going to get this question again in the IESG evaluation.
>> 
>> We've placed early versions of this document in front of members of the
>> IETF's Security Directorate. They immediately recognized that an
>> opportunistic tactic such as the one we propose in rpc-tls is a well-
>> understand and practical way to improve security of legacy protocols
>> such as NFS. I don't expect that they will object to the opportunistic
>> nature of the proposal.
>> 
>> However, more context (like a security strategy statement) could be
>> helpful. Dave was working on a document like that, but I don't know
>> what state is is currently in. I don't see it in the personal drafts
>> section of the nfsv4 document datatracker.
>> 
>> Alternately we could introduce some security-related text to the
>> WG's charter that outlines NFSv4 security strategy.
>> 
>> 
>>> To me the reasonable plan towards always used transport security (something
>>> I expect the full updates, for example of NFS v4.1 to require) is to require
>>> implementation but not usage now. Then next step to require its usage.
>> 
>> That seems like jumping ahead of the gun. We have to get the new
>> mechanism out there first. Then a subsequent NFS-on-RPC-on-TLS I-D can
>> address the specifics of how NFSv4 will operate on TLS-protected
>> transports. As recent nfsv4@ threads show, there are crucial NFS-
>> specific details that need to be resolved before a requirement that
>> is practical for NFS implementations can be made.
>> 
>> IMO we are on a path towards requiring NFS with TLS. This document
>> is but the initial step.
>> 
>> 
>> --
>> Chuck Lever
>> 
>> 
>> 
> -- 
> Cheers
> 
> Magnus Westerlund 
> 
> 
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------

--
Chuck Lever