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 >
- [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-02.t… internet-drafts
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-… David Noveck