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

[David Noveck <[e-mail]>]

>> 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". :-(


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