[nfsv4] Thinking about an RFC5661bis.

David Noveck <davenoveck@gmail.com> Thu, 28 February 2019 14:37 UTC

Return-Path: <davenoveck@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AB2D3130F30 for <nfsv4@ietfa.amsl.com>; Thu, 28 Feb 2019 06:37:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Q2Y8Z6kX8b91 for <nfsv4@ietfa.amsl.com>; Thu, 28 Feb 2019 06:37:40 -0800 (PST)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 4841A130F43 for <nfsv4@ietf.org>; Thu, 28 Feb 2019 06:37:40 -0800 (PST)
Received: by mail-ot1-x335.google.com with SMTP id v62so17832875otb.3 for <nfsv4@ietf.org>; Thu, 28 Feb 2019 06:37:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=DJMx9fwr7w50Q/6ZFX6ax+fGaWS4D1WsKW41Wxmmpy8=; b=oam31/VCZiivv0pdnvCMzLNjTl9Xapxvj6JEg65IYEH6X7pJtfbKJb3+cfGhi72JZZ V+RTTJlqzk8KxZnc5x3YW8VOunPeSx6K9LlQfiI++ebpA7LSCZMfDXmRJbdM9cYkjZX9 FBvdi3Z1OqcXWigVCTrqmQhREJ7CWa8tkhSOkedDelANzqRrI8VE4SkQuEBN3gUKoNdB pPoM6aX9O1SIchnbwgEQO4VVErXdki49L9JB8z9mQytE9VsEY3wXsM5Zdh1znWvtrhjE KL0PrFY9268IPrXh9gNYuJ/a9BmOLpPLdJHPLj9RRfdtSze8nZ3jV5DvCQkGwq/aFCbr PzhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DJMx9fwr7w50Q/6ZFX6ax+fGaWS4D1WsKW41Wxmmpy8=; b=S6IuX0ZnmuXS0GHRFQBOg5KM36fL+GpqoiYNr1M1nEdzE4yostSPjTCHJAFlwqXu76 mUpCss133FMYKxJ99YHlc2f2sn6gSIurJurLaKr9w8FNvD//auIzizOIvzwNNJ2o44x7 kzYM5pSbPizyyVPCGTc3PJW0Vlf7U7wtD83hTG9SLTbA8Gwb1XYscQlEo+rBIkFrQndw V4OqUbDgO5jh7lk+Gz53cAruMCpsEdUvgLEOg1oC8j0zCQdMk9R2kjAqK/O8aXSeFnxB R2ffO+ibonl2MEIOQya9omVRGNZL6APfZMcUknAcbiTm5JdFSQESNY31JIdt7+qyQJrt DxDQ==
X-Gm-Message-State: AHQUAub5w4oaMZel8DQBx6RVVzO4zdMe4gj3cmng8VjPVsdjv3dGffYT bePO/VM+ZbXolUFRGhzpWlraXkke+HwGcHl/i659Gg==
X-Google-Smtp-Source: AHgI3IZ8SxZxjlAeavqyetL3/s/fmEXmweJ+PQqrMbSXmx+zVQphvcahCXfo5VODxB33VOaXGvBeDvKyYGUaHSLagFk=
X-Received: by 2002:a9d:6f17:: with SMTP id n23mr5691326otq.163.1551364658997; Thu, 28 Feb 2019 06:37:38 -0800 (PST)
MIME-Version: 1.0
From: David Noveck <davenoveck@gmail.com>
Date: Thu, 28 Feb 2019 09:37:28 -0500
Message-ID: <CADaq8je5pzF7m+4oVCNfSeeBDQ98kBwAdCN_o1hBrfDob=SBaA@mail.gmail.com>
To: NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006aaf520582f53bb5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/Hj5dTm-qYG3dZFyhy1VBqWv44XA>
Subject: [nfsv4] Thinking about an RFC5661bis.
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, 28 Feb 2019 14:37:52 -0000

A number of review comments regarding draft-ietf-nfsv4-mv1-msns-update have
raised the issue of a possible bis document for NFSv4.1.   These range all
the way from those assuming that mv1-msns-update is a stepping stone on the
way to the bis document, which I agree with, to those that are asking us to
explain why we haven't already done that.   I will have to respond to that
latter comment, but I'm hoping to delay that until after the telechat.

In any case, it seems that we have accumulated enough changes to and issues
with RFC5661 that we need to start thinking about producing a bis
document.  These include:

   - All the material in mv1-msns-update modiying Section 11 and other
   parts of RFC5661.
   - The need to replace Section 14 (Internationalization) of RFC5661 with
   something like Section 12 of RFC7530.
   - Revising Section 2.4 of RFC5661 so it no longer contradicts RFC8178.
   - Updating Section 12 of RFC5661 to be in line with RFC8434.
   - Reflecting all of the verified RFC5661 erratta.  There were seventeen
   last time I checked.  There may also be things discussed as possible
   erratta, that were considered to big for the erratta process, but could be
   done as part of a bis document.

If anyone knows of other material that should go into such a document, or
has concerns about the working group starting on this, now is a good time
to raise your issue on the list.

The joker in this particular pack is the Security Considerations section.
 While we have to address the Security Directorate's notorious, "collection
of random observations" comment, I think we need to do so in a way that is
compatible with the expected draft-nfsv4-rpc-tls (hint, hint), even though
we want to be able to publish without waiting for rpc-tls to become an
RFC.  While draft-cel-rpc-tls-02 states that use of AUTH_SYS is currently
"discouraged" and that is a fair summary, I don't think RF5661 ever does
that explicitly.   It may be that we will need to explicitly discourage use
of AUTH_SYS  in an rfc5661bis (without, I hope, going so far as "SHOULD
NOT").  I think we need to frame the discussion around the three big
security deficits present using AUTH_SYS in the clear (exposing your data
to prying eves, using  data that has traversed the newtwork without
integrity protection, acting on unauthenticated requests) and not on the
use of AUTH_SYS per se.  If we do this, we can publish and implement
rpc-tls without needng to further deal with the security considerations
section of the NFSv4.1 spec.