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

David Noveck <davenoveck@gmail.com> Thu, 25 April 2019 08:46 UTC

Return-Path: <davenoveck@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A756F1200D7 for <nfsv4@ietfa.amsl.com>; Thu, 25 Apr 2019 01:46:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAsnN5Enj0i8 for <nfsv4@ietfa.amsl.com>; Thu, 25 Apr 2019 01:46:20 -0700 (PDT)
Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03A7120075 for <nfsv4@ietf.org>; Thu, 25 Apr 2019 01:46:20 -0700 (PDT)
Received: by mail-oi1-x22b.google.com with SMTP id l203so16548773oia.3 for <nfsv4@ietf.org>; Thu, 25 Apr 2019 01:46:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XDj7TApAdeXQoLmuJZqEZX7izoAq4usQht+juIFDVAM=; b=ClJxxqvfKvoQSGwJMesdMIh22TJJfR1/wWeXweYPtNN8KG5wkuR07ngVptMm+guPGv RxKgprSY6dRcsOLfjpQ2VuwADwxRmbi329ObeNLdad75D2UobcCb6NIobZSClo/tIKGz 0IGgConpUhc/g8dfpAUYoximkNBk1V0Ki0+1tQaqd9z619KKs/X7KWG4+1h/Jh6xYTiS bRoOALArPN1t0W5/BoD7mJUElgQRCkbQk0WwYxofUPkiVjDoPCF95FZt8rklv+WrSGb+ wo346dIC4yDADEuD7ThIWotardxfgvIF2vNAmNo1IlIK1RDMIR65VhNaO3bsC3NJe3Ax rl1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XDj7TApAdeXQoLmuJZqEZX7izoAq4usQht+juIFDVAM=; b=O10aFYKdZ+YxJOxlz2nUU5/L5wy/41jgSe4816FNs57rrQMJvH0cdr28jpJyQRi1mP worKx1GIibGOpNP+rvYnA2QxhXo9BYRYq2OFUu0DOFhJGFs42MVwgRVDS9Phr92iZnkU xszqpJKdj7LxtK7Tp3HBFhx84cV2MMocnpyGk1ach16h5BCe/Y+LqQJLDMSf+oME6PYM vl9iP8YcFXQThaWI7aHFIBPsnHQJSwBNLKg155krYnetPJrIzBYnqoezbhCV3iu8kUOA qU2VJp28U4dK/Sk6WuwQcZ2bOvIgwpom/ViDfEW0liIyGpzXdRVM7Qclkchx/1/WBtCu pAXA==
X-Gm-Message-State: APjAAAWNPTzLnma/zDNCB56u64FWboxwPDcBiBk3u/SJ5ZidDAxGzQnH ZZerVe/syuGnsa9RZ8FIxVefKsrEwBAuSSvMwMA=
X-Google-Smtp-Source: APXvYqwYx6cexGdFGXmoaFGkMT3/rkv8GKQb0cmQO5KVZKEqu0NqPLQwaUMygo03kK8ko/wVQeR8o1OlcOtnNJmxtZ4=
X-Received: by 2002:aca:b68a:: with SMTP id g132mr2486777oif.47.1556181979624; Thu, 25 Apr 2019 01:46:19 -0700 (PDT)
MIME-Version: 1.0
References: <155535049832.10773.1565621811584007627@ietfa.amsl.com> <CADaq8jcCB9g9v=h4iXu1f6=cAsU7wMdmfh31gCQKvEFw2eG=rA@mail.gmail.com> <804CB622-D696-4FAA-8040-993CB4029508@oracle.com> <20190422154814.GH72232@kduck.mit.edu> <2664782D-629E-4AA7-991D-76BAC465686D@oracle.com> <CADaq8jciwJanPJ09p95c5WR3QsBcmH6Z6Px4QbkG9_NTfUoJEA@mail.gmail.com> <66F78DBB-5D22-4FC2-A3C3-E69DBF87E4DB@oracle.com> <CADaq8jd8Vbia+i5svQSzhBbOy_PF-qa+ZQ7uGE1NTnFvpatcuQ@mail.gmail.com> <2022642036.2051077.1556175442469.JavaMail.zimbra@desy.de>
In-Reply-To: <2022642036.2051077.1556175442469.JavaMail.zimbra@desy.de>
From: David Noveck <davenoveck@gmail.com>
Date: Thu, 25 Apr 2019 04:46:09 -0400
Message-ID: <CADaq8jdZnSjDQiF4Jjv2+CXCP3xVYCHPdhGYmOgOauPy9ytn7w@mail.gmail.com>
To: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>
Cc: Chuck Lever <chuck.lever@oracle.com>, NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000019fb45058756da9b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/jjMejzhIWxSNsVu5XfYqFKPfCvI>
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Apr 2019 08:46:26 -0000

> I think Chuck's proposal is not contradicting to what I am saying.

I don't know.  I think I'm pretty clear about what you are saying but I'm
less clear about exactly what Chuck is proposing.

Part of the problem is that there are multiple possible "current" documents
being discussed, making the issue of proposed changes to those murky at
best.

> In "opportunistic"
> TLS model it's up to client to close the connection to a server that does
not
> support TLS and it up to server to reject RPC requests from the clients
that
> don't start conversation with STARTTLS. Such situation is well defined in
rfc3207 (SMTP):

The text you cite is clear enough and I feel rpc-tls would do well to
emulate it, although
it need not make the same decisions.

Unfortunately, if you look at the current document as most people people
would understand
it, i.e. at rpc-tls-01, we see the following problems:

   - There is no discussion of rejection cases, such as rfc3207 provides.
   Instead, the handwavy adverb "automatically" is used.
   - There is no explanation of the opportunistic model leading to
   uncertainty.   Although I have no problem with the way this is done in
   SMTP, I would have a problem with "opportunistic security" as described in
   RFC7435.   If, as Ben indicates, this is a model that is not safe againt
   active attacks, I really don't think we want to go there.

I suggest that we get back to a single current document by Chuck submitting
some reasonably current version.   Then, once that is done, we can discuss
and address the issues of providing a description analogous to the one in
rfc3207 and clarifying use of the term "opportunistic".

By the way, although I don't dispute Chuck's description of this as a "term
of art", the range of descriptions I've seen suggests to me that the most
appropriate artist to cite is Luigi Pirandello, the author of *Così è (se
vi pare) * :-)



On Thu, Apr 25, 2019 at 2:57 AM Mkrtchyan, Tigran <tigran.mkrtchyan@desy.de>
wrote:

>
>
> ----- Original Message -----
> > From: "Dave Noveck" <davenoveck@gmail.com>
> > To: "Chuck Lever" <chuck.lever@oracle.com>
> > Cc: "NFSv4" <nfsv4@ietf.org>
> > Sent: Wednesday, April 24, 2019 9:41:01 PM
> > Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt
>
> >> 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.
>
> I think Chuck's proposal is not contradicting to what I am saying. In
> "opportunistic"
> TLS model it's up to client to close the connection to a server that does
> not
> support TLS and it up to server to reject RPC requests from the clients
> that
> don't start conversation with STARTTLS. Such situation is well defined in
> rfc3207 (SMTP):
>
>
> ...
>    After the client gives the STARTTLS command, the server responds with
>    one of the following reply codes:
>
>    220 Ready to start TLS
>    501 Syntax error (no parameters allowed)
>    454 TLS not available due to temporary reason
>
>
>    If the client receives the 454 response, the client must decide
>    whether or not to continue the SMTP session. Such a decision is
>    based on local policy.
> ...
>
> and
>
> ...
>
>    A SMTP server that is not publicly referenced may choose to require
>    that the client perform a TLS negotiation before accepting any
>    commands.  In this case, the server SHOULD return the reply code:
>
>    530 Must issue a STARTTLS command first
> ...
>
>
> Again, I am not pushing for one or an other solution, but for a document
> with a monosemantic description.
>
> Tigran.
>
> >
> >> 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 <chuck.lever@oracle.com>
> wrote:
> >
> >>
> >>
> >> > On Apr 24, 2019, at 10:48 AM, David Noveck <davenoveck@gmail.com>
> 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 <chuck.lever@oracle.com>
> >> wrote:
> >> >
> >> >
> >> > > On Apr 22, 2019, at 11:48 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> >> > >
> >> > > On Tue, Apr 16, 2019 at 01:11:54PM -0400, Chuck Lever wrote:
> >> > >>
> >> > >>> On Apr 16, 2019, at 1:09 PM, David Noveck <davenoveck@gmail.com>
> >> 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
> >>
> >>
> >>
> >>
> >
> > _______________________________________________
> > nfsv4 mailing list
> > nfsv4@ietf.org
> > https://www.ietf.org/mailman/listinfo/nfsv4
>