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

David Noveck <davenoveck@gmail.com> Thu, 25 April 2019 19:27 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 01B371203D3; Thu, 25 Apr 2019 12:27:02 -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 uSJaCkLHvP7T; Thu, 25 Apr 2019 12:27:00 -0700 (PDT)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 0D2F41203D2; Thu, 25 Apr 2019 12:27:00 -0700 (PDT)
Received: by mail-ot1-x32d.google.com with SMTP id w6so548878otl.7; Thu, 25 Apr 2019 12:27:00 -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=Pwf2vzzJlV/zqvb7Wf0CLqRg42tSEjN2cKEBUEG9DX8=; b=DGd6wRQrIBVc8n+Jtp7+gybkNJC+bVJfKVRUu/lOMVt+qaMblsDY0RanL7hkRAEW8V kgLN93ZFR2wYmAqX7QL175zsYazFUAi7+Lb3P5tSY2CGWcIQcIn4kVSlV75XghOsNRUu hIkWNrPZLtUb7MyxGPbyEKvE0H28IMfGjGLFoOyzNcsBUYfNSZ9+1+DLqrljjez1J0Zh d/CTeF+hyn6/XWEEf0sBru0t6psdLpsKLuMVNgAHWKWAirBwaUJ8Yxqur3sfFlHunX8j Z2M4fRMPdUuhBdL3BLN52Jtdhcz9HO8v92TC04631w1ZMnsileZGPElIVjstUy8yxvR2 PlcQ==
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=Pwf2vzzJlV/zqvb7Wf0CLqRg42tSEjN2cKEBUEG9DX8=; b=iO1/jBusGBnuxLjDRp9uDgk4IZW7caNrDIDug0HHfpD+lzMcputp4j2gR3o9b+ZZ0e IUogk/ITBom045RWmH2zlwFl0N3Tto65R3ADuOjoW0SXY1s5fXP+vAAf51RybP+w2ayU lSxar3iBby8dCx47NziYmxwCFtnJunEc0UaFcHZGEDlhuVb8/m94ShtuMH+KfgwwPqIo ePv+yiL+otAofVROAtlzONgrUrGMdxkahmV2deAWOeY+v/qjuwHeazWbbBdCEUtPzkss eDSv5x8/xJWjSkowoMx9bRKEQNbB/7+adZRgd/X+uFvC4DJkkEcdbgzBwjfeCgXInEOa 90yA==
X-Gm-Message-State: APjAAAVhuDnQaPP9mhu7rmB0OE46XHvX2kfBnW6eRxqUKMeMvrVipBkn Qw1jDp+kEsgSXRJAMlRtK2uAFARkx0oVTuMdAAzpmtj9
X-Google-Smtp-Source: APXvYqydZQGd4iq8aKuGKnXivs0gb0oDQHSXnDI4CeW+zu+nLYcz5GnzpCC9j5HsAxhr7ofwGQmtwWOsZnZsu/ji8VM=
X-Received: by 2002:a9d:63d2:: with SMTP id e18mr1372112otl.20.1556220418580; Thu, 25 Apr 2019 12:26:58 -0700 (PDT)
MIME-Version: 1.0
References: <155621322619.872.17246549991239853787@ietfa.amsl.com>
In-Reply-To: <155621322619.872.17246549991239853787@ietfa.amsl.com>
From: David Noveck <davenoveck@gmail.com>
Date: Thu, 25 Apr 2019 15:26:47 -0400
Message-ID: <CADaq8jd8C77hKudC4iSp14GECa1m5hLWmWOGABtvWA6W23-bUA@mail.gmail.com>
To: NFSv4 <nfsv4@ietf.org>
Cc: i-d-announce@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003de67405875fcd95"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/OHLOx9W-0V0EF0Z_8p6OOSiO0ik>
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-02.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 19:27:02 -0000

Thanks for getting this out.   As far as I can see, this gives Tigran what
he needs to implement the policies he thinks miht be needed although not in
he form he is asking for.   I'd like to know if he is satisfied with this.

With regard to clarification of the use of the term "opporunistic", I feel
what is in the abstract is clear and accurate.

However, I do have issues with the (new) last paragraph of the
introduction.   Of particular concern to me is the phrase, "until a more
thorough approach can be provided", which might be read as suggesting we
would have to go through a similar exercise later to define a (new) more
thorough approach. NFS has had a number of failed approaches to security
and we don't to have more than one in our future if we can avoid it, and I
believe we can.

I don't really think that an opportunistic approach to security (as opposed
to the use of "opprtunistic TLS") is truly part of the security approach
here. It apppears to me that it is an expedient device to deal with current
lack of rpc-tls suport. As a result, I don't thiink we will need a new
approach, but instead a new set of policies more appropriate to cases in
which rpc-tls support is more common. So I would suggest rewriting the
paragraph as follows:


The use of TLS as described in this document is compatible with policies
adopting an opportunistic security approach, as defined by [RFC7435], to
RPC-based protocols. As long as there is still a significant fleet of RPC
deployments that lack support for TLS, policies embodying an opportunistic
approach can ameliorate the challenges that prevent the broad use of
encryption with RPC-based protocols (including the most popular such
protocols, which are NFS versions). The use of other policies is provided
for, although the specfications for the specfic rpc protocols may make
recommendations or define requirements which constrain client and server
policy choice.


On Thu, Apr 25, 2019 at 1:27 PM <internet-drafts@ietf.org> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Network File System Version 4 WG of the
> IETF.
>
>         Title           : Remote Procedure Call Encryption By Default
>         Authors         : Trond Myklebust
>                           Charles Lever
>         Filename        : draft-ietf-nfsv4-rpc-tls-02.txt
>         Pages           : 18
>         Date            : 2019-04-25
>
> Abstract:
>    This document describes a mechanism that, through the use of
>    opportunistic Transport Layer Security (TLS), enables encryption of
>    in-transit Remote Procedure Call (RPC) transactions while
>    interoperating with ONC RPC implementations that do not support this
>    mechanism.  This document updates RFC 5531.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-nfsv4-rpc-tls-02
> https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-rpc-tls-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-rpc-tls-02
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>