Re: [secdir] Secdir last call review of draft-ietf-nfsv4-mv1-msns-update-04

David Noveck <davenoveck@gmail.com> Fri, 08 March 2019 23:52 UTC

Return-Path: <davenoveck@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F8F12788F; Fri, 8 Mar 2019 15:52:50 -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_PASS=-0.001, URIBL_BLOCKED=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 gVvMd907AOTP; Fri, 8 Mar 2019 15:52:46 -0800 (PST)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 F2D56126DFA; Fri, 8 Mar 2019 15:52:45 -0800 (PST)
Received: by mail-oi1-x232.google.com with SMTP id t82so17239719oie.12; Fri, 08 Mar 2019 15:52:45 -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=pTFDMWtIKHuM1Hmsmz5hpGhCqwN7HwGOoA9vQoJGzYU=; b=gWuW/zaGNcgqtWIt/dGuTj/uTFLVVvTLr9Z7Kiu/1yYTuJW1f25EuJaF2M3sCpv7kt HRw0s5XgeGNcL6enx+2K8zqnMpAK0fX22StZ2uOzviSsww0oNKJzZbnmwFFMRbkBSLrp lAu+VsT8I7EsNpV2XHwfnne2zGOBGaewVHl12RhILy3zltRXKsIR93JWYZI07P0hrmAa 7gVa+2DDlhaBbN8mLju/FyOq8N6hPUbw959wxrYdP21f8SKHExgUV7LMRbvXRlj3Ex9h 9PJfBcfDWvO2Fj2ub/6F0ilFEhgMY1PcZt5V03O2LPYm1EzAvGumOt7C8NS127plp3TK r16Q==
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=pTFDMWtIKHuM1Hmsmz5hpGhCqwN7HwGOoA9vQoJGzYU=; b=UHkPhTzKukSjvC/JlEttKjxeB/FkpIt9TNTQjnqMHBRPzyRkNcVr232ciTT8Y6HDLU tmD2RDIeDckw8DGPxYPDJiSR8BY+0rIbcAD8O4zAY0fZJM5HKwRbz1ffW8zr7CKTHDvO FH5taEginG26uMd8QVP5pAzDKdpj/BpNFQMZ8HiDlmkFgsc4cawsVvxmpJd+pwMdZvlW 2dMrh4aVBmecd/VHVbhEpJfKQyoyB6YwRPRv6juDzBYD56xK84bTjk3p54d2Y9dF4Wod wo50ySZ66xp9TngKOzmLNAyj0o53se7TdrNmA+/1ylcTa+tZqw7MxQZs3Ox1Yt6xrcFB 7CMQ==
X-Gm-Message-State: APjAAAU7hRFjjVsstu39yd1gBlg6Be5TGM4DNf86EZQ5rtddAC+ycY9n RjQVfGkt7vVTVaPzICkoj58/uNvabpixUT8QOzA=
X-Google-Smtp-Source: APXvYqxmJCYd29Vb5KuqtuegyYpxaVqoCeutcNYnYlDfovlDGYyCtopEthpoDo8vVf3/MlJww21BnIeDnrsTnuAwKwo=
X-Received: by 2002:aca:f0c3:: with SMTP id o186mr9312874oih.101.1552089164963; Fri, 08 Mar 2019 15:52:44 -0800 (PST)
MIME-Version: 1.0
References: <155128908237.14053.17188619727012241844@ietfa.amsl.com> <CADaq8jeQJi+azCcuMCRN8h+quqvx+NM2kiOAMq9E-n+Kp6eWRw@mail.gmail.com>
In-Reply-To: <CADaq8jeQJi+azCcuMCRN8h+quqvx+NM2kiOAMq9E-n+Kp6eWRw@mail.gmail.com>
From: David Noveck <davenoveck@gmail.com>
Date: Fri, 08 Mar 2019 18:52:33 -0500
Message-ID: <CADaq8jd9iAmsUO_Heyk8RMRiEue97W_TPwx_65YAxaS-ksR4OQ@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Cc: secdir@ietf.org, ietf@ietf.org, NFSv4 <nfsv4@ietf.org>, draft-ietf-nfsv4-mv1-msns-update.all@ietf.org
Content-Type: multipart/alternative; boundary="000000000000566aac05839debbf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/nkc4JITrVBJqeEFjL2P3OufEzdw>
Subject: Re: [secdir] Secdir last call review of draft-ietf-nfsv4-mv1-msns-update-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Mar 2019 23:52:51 -0000

I previously said:
> Will address nits 0)-4) and 6)-10) in -05.

However when I looked more closely at 9), I've found that I cannot make the
requested change.

> 9) s12.2.3: replace ietf.org with example.org (not supposed to use
> real domains even if it is “ours”).

This is not an example.   The use of ietf,org is intentional and is
intended as a way
to provide the ability to define globally usable variable definition as
well as domain-specific
ones.  This is specified in section 22.5 of RFC5661.   I'm not sure about
the details of
the prohibition of the use of real domain names but I can;t see how it
would apply in this
case where this form of vatibl specification, including a real domain name
has already
been adopted.


On Thu, Feb 28, 2019 at 8:30 PM David Noveck <davenoveck@gmail.com> wrote:

> > These
> > instructions will really help when work on a fully revised NFS RFC gets
> > going.
>
> That's the intention.  The working group is now discussing the possibility
> of an rfc5661bis
> that would use those instructions.   Note that the current document would
> be the source of
> a large set of the changes but there are also others: The
> internationalization section needs to
> be updated as it was in RFC7530.  Section 12 needs to be updated to
> reflect the work done by
> RFC8434.  Also, there are a lot of erratta that would need to be applied.
>
> > 0) The big issue being addressed in the security considerations is the
> fact
> > that RPSEC_GSS is must support not must use
>
> That reflects choices made for RFC3530 and carried over until now.   This
> has resulted in
> a situation in which AUTH_SYS is very commonly used despite its obvious
> security weaknesses.
>
> > So what do you do when RFC 5661 says:
>
> >  The fetching of attributes containing file system location
> >  information SHOULD be performed using RPCSEC_GSS with integrity
> >  protection,
>
> Not much, since there is not much I can do about that.
>
> > And, you don’t now change to MUST use RPSEC_GSS?
>
> No I don't.   Currently use of AUTH_SYS is allowed and the working
> group has not made any decision to change that.
>
> > Well I think at a minimum you should do some 2119 language:
>
> OK, but note that this is a widely-deployed protocol and we are not
> in a position to invalidate deployment choices made in line with RFC5661,
> even if we think they were ill-advised.
>
> > 0) s16 (after the bullets): 2119 this should:
>
> If you are suggesting changing "should" to "SHOULD" in this parapgraph,
> I'm OK with making that change in -05, although I will raise the issue with
> the working group to check about existing implemtations.
>
> > 1) s16 (2nd para after the bullets): 2199 this SHOULD NOT:
>
> I intend to shift this to "SHOULD NOT"  in -05.
>
> > 2) s16 (last bullet): 2119 this should:
>
> Given that this bullet appears in a summary, I think the "should" is
> misleading.   Converting it to "SHOULD" would lead to recommemmending
> filtering without specifying the filtering to be done.  What I propose to
> do in -05 is replace "should be subect to filtering" by "is made subject to
> filtering as described above".
>
> > The use of requests issued without RPCSEC_GSS (i.e. using
> >  the known to be insecure AUTH_SYS), while undesirable and
> >  Insecure, may not be avoidable in all cases.
>
> While I approve of drawing more attention to the weaknesses of
> AUTH_SYS, I feel the use of the word "insecure" is too vague.
> "Insecure" covers a range of problems whereby traffic is either
> exposed to prying eyes, subject to corruption in transit, or acted
> upon without authentiction.   Given the context, I think we need to
> be clear about what the actual problem is even though AUTH_SYS,
> in what has to be considered a virtuoso performance :-), manages
> to acomplish the hat trick of protocol insecurity.
>
> So I propose writing this as follows:
>
> The use of requests issued without RPCSEC_GSS (i.e. using AUTH_SYS which
> has no provision to avoid corruption of data in flight), while undesirable
> and a potential security exposure, may not be avoidable in all cases.
>
>
> > It’s probably also worth discussing whether s14.3 should drop
> > support for includes id-sha1
>
> The text you are referring to was carried over from RFC5661 as-is since
> there was no issue known with it.
>
> Regarding the potential deletion of id-sha1, the issue, given that server
> support is currently REQUIRED, is whether there are clients using this who
> might be impacted by a change.   I'll check with the working group.
>
> > 4) s4.3 (1st sentence): Not sure the 2119-RECOMMENDED is needed.
>
> These are really OPTIONAL althouh the word "RECOMMENDED" is (confusingly)
> used.
> Will delete.
>
> > 5) s4.3 (penultimate para): Seems like r/should/SHOULD.
>
> It is probably the case that RFC5661 made a poor choice here.  However, I
> don't think we can change it now.
>
> > 10) s16 (3rd bullet): Why is requirement is caps?
>
> It's because I was under the misapprehension that statement that things
> were REQUIRED or RECOMMENDED could be referred to as "REQUIREMENTS" or
> "RECOMMENDATIONS".  It turns out not to be so.
>
> Will address nits 0)-4) and 6)-10) in -05.
>
> On Wed, Feb 27, 2019 at 12:38 PM Sean Turner <sean@sn3rd.com> wrote:
>
>> Reviewer: Sean Turner
>> Review result: Has Issues
>>
>> This draft updates NFSv4.1 to correct handling of the fs_locations and
>> fs_locations_info attributes; NFSv4.1 weighs in at 617 pages and this
>> draft weighs in a relatively spry 106; let’s say I was really, really
>> hoping
>> for some multi-page ASCII art, but also no pretty much all text.  The
>> draft does a good job of explaining what’s being replaced and why, but
>> I have to say that I did not check all of section pointers.  These
>> instructions will really help when work on a fully revised NFS RFC gets
>> going.  Unfortunately for me, I do not have NFSv4.1 in my head so let’s
>> just say that I did my best …
>>
>> Summary: This draft is probably worthy of some type of DISCUSS based
>> on the following:
>>
>> 0) The big issue being addressed in the security considerations is the
>> fact
>> that RPSEC_GSS is must support not must use and the other mechanism
>> referred to by RFC 5661 are:
>>
>> - AUTH_NONE - nada authentication
>>
>> - AUTH_SYS as described in Appendix A is known to be insecure due to
>>    the lack of a verifier to permit the credential to be validated.
>>    AUTH_SYS SHOULD NOT be used for services that permit clients to
>>    modify data.  AUTH_SYS MUST NOT be specified as RECOMMENDED or
>>    REQUIRED for any Standards Track RPC service.
>>
>> - AUTH_DH as mentioned in Sections 8.2 and 13.4.2 is considered
>>    obsolete and insecure; see [RFC2695].  AUTH_DH SHOULD NOT be used for
>>    services that permit clients to modify data.  AUTH_DH MUST NOT be
>>    specified as RECOMMENDED or REQUIRED for any Standards Track RPC
>>    service.
>>
>> So what do you do when RFC 5661 says:
>>   The fetching of attributes containing file system location
>>   information SHOULD be performed using RPCSEC_GSS with integrity
>>   protection,
>> And, you don’t now change to MUST use RPSEC_GSS?  Well I think at a
>> minimum you should do some 2119 language:
>>
>> 0) s16 (after the bullets): 2119 this should:
>>
>>   In light of the above, a server should present file system
>>   location entries that correspond to file systems on other servers
>>   using a host name.
>>
>> 1) s16 (2nd para after the bullets): 2199 this SHOULD NOT:
>>
>>    As a
>>    result, the client should not use such unverified location entries
>>    as a basis for migration, even though RPCSEC_GSS might be
>>    available on the destination.
>>
>> 2) s16 (last bullet): 2119 this should:
>>
>>   Where the use of the returned information cannot be
>>   avoided, it should be subject to filtering to eliminate the
>>   possibility that the client would treat an invalid address as
>>   if it were a NFSv4 server.
>>
>> And, I guess since AUTH_SYS is insecure can I suggest a friendly
>> amendment to the following sentence:
>>
>> OLD:
>>   The use of requests issued without RPCSEC_GSS (i.e. using
>>   AUTH_SYS), while undesirable, may not be avoidable in all
>>   cases.
>>
>> NEW:
>>
>>   The use of requests issued without RPCSEC_GSS (i.e. using
>>   the known to be insecure AUTH_SYS), while undesirable and
>>   Insecure, may not be avoidable in all cases.
>>
>> It’s probably also worth discussing whether s14.3 should drop
>> support for includes id-sha1.
>>
>>
>> These are the nits:
>>
>> 0) Update to use new 2119 paragraph:
>>
>>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>>   "OPTIONAL" in this document are to be interpreted as described in BCP
>>   14 [RFC2119] [RFC8174] when, and only when, they appear in all
>>   capitals, as shown here.
>>
>> 1) s3.1 (wordy): r/since the
>>   ports to be used for various types of connections might be
>>   required to be different/since the
>>   ports to be used for various types of connections might be
>>   different.
>>
>> 2) s3.1 (missing period): r/Two such addresses support the use of clientid
>>   ID trunking, as described in [RFC5661]/Two such addresses support the
>> use of clientid
>>   ID trunking, as described in [RFC5661].
>>
>> 3) s4.2 (missing word): r/which may accessed/which may be accessed
>>
>> 4) s4.3 (1st sentence): Not sure the 2119-RECOMMENDED is needed.
>>
>> 5) s4.3 (penultimate para): Seems like r/should/SHOULD.
>>
>> 6) s4.5: r/present , is/present, is
>>
>> 7) s4.5: Note sure you need the parenthetical in the following:
>>   a server may (but is not required to)
>>
>> 8) s4.5.4: r/In the event that server failures,/In the event that
>> server fails,
>> or
>> r/In the event that server failures,/In the event of server failures,
>>
>> 9) s12.2.3: replace ietf.org with example.org (not supposed to use
>> real domains even if it is “ours”).
>>
>> 10) s16 (3rd bullet): Why is requirement is caps?
>>
>>