Re: [nfsv4] Comments on draft-ietf-nfsv4-integrity-measurement-07
spencer shepler <spencer.shepler@gmail.com> Thu, 07 November 2019 07:05 UTC
Return-Path: <spencer.shepler@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 505EA1200FA for <nfsv4@ietfa.amsl.com>; Wed, 6 Nov 2019 23:05:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, 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 AguBOJJo_giT for <nfsv4@ietfa.amsl.com>; Wed, 6 Nov 2019 23:05:56 -0800 (PST)
Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 6601212002E for <nfsv4@ietf.org>; Wed, 6 Nov 2019 23:05:55 -0800 (PST)
Received: by mail-lj1-x241.google.com with SMTP id r7so1015265ljg.2 for <nfsv4@ietf.org>; Wed, 06 Nov 2019 23:05:55 -0800 (PST)
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=/Ze/Z4vLYIVs0QEqyUnArYv58nP3A8P4TkBlTaoEe5w=; b=agAkM1qPk0Mcmx2iED2IQioXlNou8QmMmaEwD0aY5o8bdBIWqKLh9tejfTvkEqfp6p /peuQ3yGPkogq2QaSoi0Y7gjWem/+dIFfDqi0aemNsl2TP8r9SzwQm4Z8ceermHShPz8 ktK3gxrNzr9pMkhWDFLeL3Tb4rXG5S1tRz19NaNYrI/zGGIIrCmDUv4cAaInBfz9WMxD S6a8ThUhAuymlc5mLKKouooyI3LGKGddRABufStUyrRBY3jOn/4fDvCSOk+Sjdmdc0Mp rtEzl2BIW5hCzRjgnTuQrZCKMaXhpZ4LuS7kmBpftUpbHsHg8xFaSWqINJXWy61ycV+5 95yQ==
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=/Ze/Z4vLYIVs0QEqyUnArYv58nP3A8P4TkBlTaoEe5w=; b=ZO9QR+6gleSy379rG9litYjqx3gNcXFXhCW0NXgb63coPpFe5S73wOABEQUMCmy9fR YMvV4XhN9jkYE4JdSkKUaLihinfMkGT0PKdGAgLqY8rYeN1ZQEC7D9wBppnNlDjfg13F +DIxBzAQ2FeTf7GwTIX1Mj16hQhn3oT0rWUjhuMwRxToYkMRHVl/ws7FKvM6QooCZkdj as95h3luOh15T4Seje4RFwnP+7XodJVkFWPVdGWcybbUydBuEpEa9EgyZREXBCQjAhs9 ur8jv8jkA6d4AMXAx1UMRPMfe27a3+dv9YP/8lLaN50JGLX1QHjgIDf15+Nb54AiVDzb yRDg==
X-Gm-Message-State: APjAAAUqwGZOlnlcessujFfz/N2PNAepveUQ4tY+VhN24QixDpL+qnbi f/G3tgucuyw7wtaJ4QkE32C1w4XkPMTiiRJ1BkA=
X-Google-Smtp-Source: APXvYqx1yu2Bb8+x1m/1p2Zu5tmYVBXctK7rCWEaI2R0GURWo8nl0oLMIcyP9rivvPGlVGDJhwGNQMydDynHrm28IIk=
X-Received: by 2002:a2e:481:: with SMTP id a1mr1126417ljf.209.1573110353505; Wed, 06 Nov 2019 23:05:53 -0800 (PST)
MIME-Version: 1.0
References: <CAFt6BakApq=FJWs+r-jwxvTdXYs9yOg9KS47no93kdnp2gZ_+Q@mail.gmail.com> <9BEBDE7A-522A-4A6B-8132-D9C3A8A4922C@oracle.com> <CAFt6Ba=q=vSt+wtcHsi59gWnwFpuUaDqQue7f=GFSUvd25uV+g@mail.gmail.com> <BFDF314F-B913-4C4A-BAB4-C09FA840F4F6@oracle.com> <CADaq8jc_gM0SWe9weRJYp7s7xjtN9kihbVnUiBN61hF2LUJjzQ@mail.gmail.com> <FD12C92F-BBF4-4174-B896-48738C02B78E@oracle.com> <CAFt6BanwC4uu=9SpZQdiGjFswzkC3cSWPzGia34qBT5W+uuMNw@mail.gmail.com> <5B51BB44-F39D-4EF6-9E1E-3EF958F90260@oracle.com> <20191031192409.GJ88302@kduck.mit.edu> <67D69A00-D231-4845-A840-F3D67D629554@oracle.com>
In-Reply-To: <67D69A00-D231-4845-A840-F3D67D629554@oracle.com>
From: spencer shepler <spencer.shepler@gmail.com>
Date: Wed, 06 Nov 2019 23:05:42 -0800
Message-ID: <CAFt6BanShDjwD3SftuDUvChFq9zOU5h1UC2y=W+3bVm++jAEKA@mail.gmail.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d0359b0596bc4b3c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/z0WdENrKLZOt1kgrE3Fs4do4ScE>
Subject: Re: [nfsv4] Comments on draft-ietf-nfsv4-integrity-measurement-07
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, 07 Nov 2019 07:05:59 -0000
Apologies for top posting but I would like to address one portion of this thread only. I have poached one particular comment.... the below is quoted from Chuck's last response on this thread. -- > I think I lack the background to understand why Spencer doesn't believe > this is an appropriate use of the NFS protocol, but I don't think that this > is the right thread to educate me. I'm also interested in learning more about this. The same argument has been made in the past about extending NFS in general, and I guess I had assumed that this had been resolved with the publication of RFCs 8178 and 8276. -- I agree that RFC 8178 provides the ability to add features, particularly attributes, to the protocol and I agree with the utility of 8178 and that is appropriate. I also agree with the utility of RFC 8276 but I disagree with the interpreted precedent of the RFC per Chuck's comment. To quote from RFC 8276: "Xattr keys and values MUST NOT be interpreted by the NFS clients and servers, as such behavior would lead to non-interoperable implementations. If there were a need to specify one or more attributes that servers need to act upon, the appropriate semantics would be specified by adding a new attribute for the purpose as provided for by [RFC5661] and [RFC8178]." I read the proposed integrity measurement capability as providing a "system-level" interpretation. The decision to allow for the execution of application binaries is a "system" level activity or in other words, a feature that explicitly requires the client to interpret the semantics of the protocol extension. Because of the client's need to interpret the capability, the definition should be defined in a way that it can be implemented in an open fashion and hopefully, but not required, defined in a way that it is "upgradeable". To the point of "open", I don't believe the availability of open source sufficient in this instance. Yes, a clean-room approach to implementation can be executed but even with that action, a patent claim can still be made. Therefore, without the protocol definition being captured in a way that clearly allows the reader to have a sense that IETF's policies for disclosure have followed, I don't believe it should be allowed as an extension of the NFS protocol. So, I am left with my objection to this work moving forward. If this proposal would to be accepted, it sets a precedent that a individual could define a similar extension for their favorite XYZ product in such a way that interoperable implementations could be not implemented. In least this could lead to a proliferation of OS, vendor specific feature creep and at worse, non IP infringing implementations would be impossible to implement. Spencer On Thu, Oct 31, 2019 at 12:54 PM Chuck Lever <chuck.lever@oracle.com> wrote: > > > > On Oct 31, 2019, at 3:24 PM, Benjamin Kaduk <kaduk@mit.edu> wrote: > > > > A few points/questions inline: > > > > On Tue, Oct 29, 2019 at 11:33:18AM -0400, Chuck Lever wrote: > >> > >>> On Oct 29, 2019, at 2:15 AM, spencer shepler < > spencer.shepler@gmail.com> wrote: > >>>> > >>>> On Mon, Oct 28, 2019 at 1:05 PM Chuck Lever <chuck.lever@oracle.com> > wrote: > >>>> > >>>>> On Oct 28, 2019, at 3:28 PM, David Noveck <davenoveck@gmail.com> > wrote: > >>>>> > >>>> > >>>> In my earlier reply, I proposed breaking this process into two steps: > >>>> > >>>> 1. Specify how NFS is to transport IMA metadata in an IETF publication > >>>> 2. Specify the Linux IMA metadata format itself in some other venue > >>>> > >>>> So then: > >>>> > >>>> 1. would be a Normative extension to the NFS protocol > > > > I'm probably missing something obvious, but why does it have to be a > > normative extension to the NFS protocol? Is there some IANA registry > with > > a Standards Action registration policy? > > IETF WGs can publish informational documents, is where I'm going with > this. > > I'm proposing that: > > The transport piece would be Normative, as NFS protocol extensions > typically are. > > The metadata format would be Informative, just as you suggest. > > Not clear to me how making the transport piece Informative would > allay concerns about the metadata format. > > Btw, I've added Spencer's review along with some thoughts about how > to address his comments in an issue: > > https://github.com/chucklever/i-d-integrity-measurement/issues/7 > > > >>>> 2. might be published by the nfsv4 as an Informative description of > the > >>>> metadata format, in lieu of getting this published somewhere else. > Think > >>>> of it as an illustrative example rather than a hard specification. > >>>> > >>>> It still doesn't feel like it's the job of an inter-networking > standards > >>>> body to maintain this metadata data format specification, however. > >>>> > >>>> Does it make sense to publish either a separate Informative document > or > >>>> have an Appendix to this document that provides an Informative example > >>>> that gives a specific format for Linux IMA metadata? > >>>> > >>> Chuck, > >>> > >>> Given this last set of responses, you seem to be saying that the only > implementation of this capability will be with Linux and that you would be > surprised to find any other implementations that would need to implement > the support for this feature. > >> > >> That's not at all what I'm saying. > >> > >> There is currently no published standard definition of the IMA metadata > format. > >> I've made it clear from the very beginning that one does not yet exist, > and > >> have asked repeatedly whether this will be a problem. For the past 18 > months, > >> I've gotten the answer "no, it shouldn't be, because NFS > implementations won't > >> be required to interpret the metadata format." > >> > >> Thus I'm asking for a protocol extension so that NFS can transport, and > NFS > >> servers can store, a particular piece of opaque metadata. This is a > narrow > >> scope. All I want to do is store and retrieve this metadata via NFS. > >> > >> I've been asked to provide the format of the metadata. But at this > time, no-one, > >> except for Linux, has stated a plan to actually use it. Thus, this > sounds like > >> a piece of this puzzle that can be deferred until it is actually needed > (or > >> until someone decides the Linux IMA format is awesome and publishes it). > >> > >> I'm also not claiming the metadata format should /never/ be published; > merely > >> that we don't need this format definition to create a mechanism for > storing it. > >> > >> - Interpretation of the metadata can be left to the future because > there is > >> a clean dividing line between moving the data and parsing it. This > allows > >> the protocol piece of this work to move forward quickly while we > wrestle > >> with the standards issues around the metadata format. > >> > >> - I don't believe the IETF is the right place to publish the metadata > format. > >> The IETF does networking, not data storage and not Trusted Computing. > If > >> we have to publish anything, it should be Informative only. Or maybe > we > >> can approach another standards setting organization where it would be > more > >> appropriate. I'm open to hear arguments either way about this. > > > > I'm not arguing that the IETF should take on and publish the Linux IMA > > format (for one, we don't seem to have many people willing to put energy > > into doing so), but I will note that the IETF has recently chartered a WG > > for remote attestation procedures and does have people thinking about > > endpoint security and endpoint assessment (e.g., the SACM WG). > > That's interesting! I'll investigate. > > > >> It seems to me that the only thing that is missing from the current > document > >> is a clear statement that this document, by itself, will not enable the > >> implementation of an IMA appraiser on the NFS server or client. The > document > >> does not prevent or forbid future publication that would enable such an > >> implementation. > >> > >> > >>> So, this is then clearly opening the door for the NFS protocol to be > used for implementation specific features and to the point that all that is > needed is an opaque attribute and possibly some error codes to go along > with it to achieve a side band protocol for that specific implementation. > And if anyone is interested in the feature, a pointer to some "open source" > is sufficient. > >>> > >>> Well, I don't believe that is an appropriate use of the NFS protocol > as defined within the IETF. I apologize if I have the characterization > incorrect and would be happy to hear otherwise. > > > > I think I lack the background to understand why Spencer doesn't believe > > this is an appropriate use of the NFS protocol, but I don't think that > this > > is the right thread to educate me. > > I'm also interested in learning more about this. The same argument has been > made in the past about extending NFS in general, and I guess I had assumed > that this had been resolved with the publication of RFCs 8178 and 8276. > > > -- > Chuck Lever > > > >
- [nfsv4] Comments on draft-ietf-nfsv4-integrity-me… spencer shepler
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… David Noveck
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Craig Everhart
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… spencer shepler
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… spencer shepler
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… David Noveck
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… David Noveck
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… spencer shepler
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Benjamin Kaduk
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… spencer shepler
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… David Noveck
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Benjamin Kaduk
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… David Noveck
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… David Noveck
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever