Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt

[David Noveck <[e-mail]>]

> The opportunistic approach is meant to be a step up, not
> a full solution.

OK, but the question at hand is whether rpc-tls (or the RFC that results
from it) is to be limited to the opportunistic approach.   I'm arguing that
it should not, and much of what you say below seems to indicate
that you agree.

However, other things you say lead me to a contrary conclusion, so it
would be best if we got a clear answer on this point.

> We are bridging a gap here, and I think
> we all expect/hope to have deeper solutions in the future.

To get those, I think we need do more than expect/hope for them.   I think
we need to plan for them.   One way to do that is to allow rpc-tls to be
used either opprtunistically or non-oportunistically. rather than
restructing it to opprtuunistic use and expect something else to
provide support for the non-opportunistic case.

> For instance, we could define an RPC on QUIC transport
> type that requires host authentication and encryption from
> the get-go.

I've heard some rumblings about QUIC and would like to see an RPC
transport type defined.   However, we haven't yet seen even a
fragmentary individual submission on this topic.   Yes, we could
do this in the future, but it is unwise to count on it any time soon/

> The current rpc-tls document now RECOMMENDS that an RPC
> client's security policy insists on the use of TLS (ie,
> that they will immediately close a connection to a server
> that does not support TLS).

If it does, then it is not opportunistic and there is a conflict with
the abstract which says "opportunistically".

I've been unable to see where it says that.  I've searched the document
for "RECOMMEND".  Also:

It does  say the following which seems to contradict it:

The mechanism described in this document interoperates fully with RPC
implementations that do not support TLS.  The use of TLS is
automatically disabled in these cases.

Tigran is looking for a discussion of this case and can't find it, so, in
any case, it is not just me who isn't able to see this.

> That is a reasonable way to
> address active attackers while there is still a large fleet
> of RPC implementations without TLS support.

I don't see that you can RECOMMEND that unconditionally,
especially in an RPC-generic document.   When there are
a large set   of RPC implementations without TLS support,
is precisely when the alternative (i.e. opportunistic) approach
has its greatest value.

> We could also strongly RECOMMEND the use of authentication.

I don't think we should do that in the context of an RPC-generic
document.  Each protocol might reasonbly have its own needs and
policies.

The decision to proceed with an rpc-generic document was intended to
accellerate development of rpc-tls.  That's worked so far but I think that
to
maintain progress we have to avoid the temptation to put protocol-
specific material (most likely for NFSv4) into what should be an rpc-
generic document.   That would essentially undo the decision to make
this an rpc-generic document.

I've thought about something like this for v4-oriented document but
I think that there the need/requirement for authentication of the client
is best tied to use of AUTH_SYS.    If you are using RPCSEC GSS and
have an encrypted channel, you would have adequate NFSv4 security, even
in an internet environment. :-). At that point, client authentication, which
might be work to add to the work already done to implement RPCSEC GSS,
is better seen as OPTIONAL.

On Wed, Apr 24, 2019 at 10:55 AM Chuck Lever <[e-mail]> wrote:

>
>
> > On Apr 24, 2019, at 10:48 AM, David Noveck <[e-mail]> wrote:
> >
> > >> The summary of the reasoning for the use of this term is basically
> that it
> > >> does not provide protection in the face of an *active* attacker (that
> can
> > >> force downgrade to the previous/insecure technology), but does protect
> > >> against passive observation.
> >
> > > Indeed, this looks directly on point.
> >
> > It does but having read this document and considering Ben's statement
> > that "it :does not provide protection in the face of an 'active'
> attacker, I'm
> > wondering if the 'opportunistic" nature of this approach should be
> mentioned
> > quite as prominently as it is in -01.
> >
> > For example, Tigran is basically asking for a description of how this
> mechanism
> > would be used non-opprtunistically and it seems clear to me that
> eventually
> > there will be a need such deployments.   If and when this mechanism is
> widely
> > deployed the failure to establish an encrypted connection is more likely
> to be
> > due to an active attacker rather than a non-rpc-tls-supporting server.
> >
> > It is not clear to me why, in that event the client should behave
> passively in the
> > face of an active attack.   As i understand it, an eventual Security
> Consideraations
> > is going to have to consider all possible attacks and we want to avoid a
> situation
> > in which an accurate Security Consideration would need to say, in
> essence, "omigod,
> > it's hopeless". :-(
>
> The opportunistic approach is meant to be a step up, not
> a full solution. We are bridging a gap here, and I think
> we all expect/hope to have deeper solutions in the future.
>
> For instance, we could define an RPC on QUIC transport
> type that requires host authentication and encryption from
> the get-go.
>
>
> The current rpc-tls document now RECOMMENDS that an RPC
> client's security policy insists on the use of TLS (ie,
> that they will immediately close a connection to a server
> that does not support TLS). That is a reasonable way to
> address active attackers while there is still a large fleet
> of RPC implementations without TLS support.
>
> We could also strongly RECOMMEND the use of authentication.
>
>
> > On Wed, Apr 24, 2019 at 9:53 AM Chuck Lever <[e-mail]>
> wrote:
> >
> >
> > > On Apr 22, 2019, at 11:48 AM, Benjamin Kaduk <[e-mail]> wrote:
> > >
> > > On Tue, Apr 16, 2019 at 01:11:54PM -0400, Chuck Lever wrote:
> > >>
> > >>> On Apr 16, 2019, at 1:09 PM, David Noveck <[e-mail]>
> wrote:
> > >>>
> > >>> I'm confused by the addition of the word "opportunistically" in the
> abstract.   This document defines an important way of providing security to
> RPC-based protocols such as NFSv4, so as to deal with the very real
> security problemms that these protocols have.    While these facilities can
> only be used when both client and the server provides support, I don't
> think that fact alone make the use of these facilties "opportunistic".
> What exactlty is this word intended to imply?
> > >>
> > >> "Opportunistic" is a term of art. See:
> > >>
> > >> https://en.wikipedia.org/wiki/Opportunistic_TLS
> > >
> > > RFC 7435 is also a good reference for this topic (and one that has IETF
> > > consensus, FWIW).
> > >
> > > The summary of the reasoning for the use of this term is basically
> that it
> > > does not provide protection in the face of an *active* attacker (that
> can
> > > force downgrade to the previous/insecure technology), but does protect
> > > against passive observation.
> >
> > Indeed, this looks directly on point.
> >
> > --
> > Chuck Lever
> >
> >
> >
>
> --
> Chuck Lever
>
>
>
>