Re: [secdir] Secdir last call review of draft-ietf-nfsv4-mv1-msns-update-04
Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 09 March 2019 01:37 UTC
Return-Path: <brian.e.carpenter@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 5F4C11274D0; Fri, 8 Mar 2019 17:37:37 -0800 (PST)
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, 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 k-KGQ4bSeG9V; Fri, 8 Mar 2019 17:37:34 -0800 (PST)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 67924126C15; Fri, 8 Mar 2019 17:37:34 -0800 (PST)
Received: by mail-pg1-x531.google.com with SMTP id h8so15484428pgp.6; Fri, 08 Mar 2019 17:37:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=RbBsuFG9cS51hZ2NDcjZ75YUZ/YhWT76190VcvX7MFU=; b=uxWdqQHI8DIGfYNwuMc+u9O5X5ImgCLisFZeeamOaE8NCO+ftJKPf5XbwJwuh+pU7u C1+8VU8bgWLtRkwcq9RdZBOvFmgzMF+Su886pqA+Ez6Z1X26EvZxLEJryA5iRlN+wicg XxpVcGTM7b6MZw/fiFH+mpuMy48Yi70d+iIAZOsbB5QKU/7aiY6NZYgAr+Z/7Wh6Cmos S0P/2vrxWLowD0MkFn7KcywdeYCskQORcz03WT0N2DkyyqDd0Dg+n4aU8B2s7+Z6zS/t bKBxoFrigpkpoDG18u+0fv98zp18G35k37tRFtAvmVYfF21yjZ0jdIeIy+MAGmSK97dY SodQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RbBsuFG9cS51hZ2NDcjZ75YUZ/YhWT76190VcvX7MFU=; b=kSrh+Ojbc3GWymGFyEmZ7WoOmBjC0RafJDWQJkXEUHItQJZsGd/2UoZWuqaHL2h7+8 ZmyOvBB3d9kRUAmyUcdqQ8U/QkrioCQg1SkxHtcbkegs2PdCzhiDzVEC1IZg7M1sP/Zx 6wPl7nEoxv/kdEu16dRiQeNnuIaMyPurdF8DHr/A9PARjcf3oly2VUvex4FAXdVU83wv 475CATwdEPy1jBnlCgLmnbeGhGUHUasxJ4qJ73nnWmWBlZW2SQdShUAIO2WYweKRIkBh taxjGtdP+Gyon8coyn6a7XRRNlLZa++joWdj1LBcKUJRFwMxqZ3ov055uvqmmfjfaEhm 7aJw==
X-Gm-Message-State: APjAAAUGFpcT9876Hzx1+kMAszXM/GN4gav5IrKZiOanNP4PgHYWTa00 x3ZXwOISaeZPILkokAiwsjjabSPv
X-Google-Smtp-Source: APXvYqxHTvAysb7kUHA4AnrOTVff5uMgg4MK2Ys2TLAxUpwYsGe1Y7xxwq1u/8JRrs4k1d5ap4p8Og==
X-Received: by 2002:a65:438a:: with SMTP id m10mr19542979pgp.191.1552095453388; Fri, 08 Mar 2019 17:37:33 -0800 (PST)
Received: from [192.168.178.30] (211.231.69.111.dynamic.snap.net.nz. [111.69.231.211]) by smtp.gmail.com with ESMTPSA id h6sm488759pgn.59.2019.03.08.17.37.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Mar 2019 17:37:32 -0800 (PST)
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, David Noveck <davenoveck@gmail.com>
Cc: draft-ietf-nfsv4-mv1-msns-update.all@ietf.org, NFSv4 <nfsv4@ietf.org>, IESG <iesg@ietf.org>, secdir@ietf.org
References: <155128908237.14053.17188619727012241844@ietfa.amsl.com> <CADaq8jeQJi+azCcuMCRN8h+quqvx+NM2kiOAMq9E-n+Kp6eWRw@mail.gmail.com> <CADaq8jd9iAmsUO_Heyk8RMRiEue97W_TPwx_65YAxaS-ksR4OQ@mail.gmail.com> <CAKKJt-dqw=Q-0pk=NgJQZqQ7+LPU_CRWJEua8pi9Y0JAJv_D7A@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <cb69201e-1cea-6479-d4d1-67366a31953a@gmail.com>
Date: Sat, 09 Mar 2019 14:37:28 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <CAKKJt-dqw=Q-0pk=NgJQZqQ7+LPU_CRWJEua8pi9Y0JAJv_D7A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/aUqueIPAqnT3OMtT4sxG-aQw5mM>
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: Sat, 09 Mar 2019 01:37:37 -0000
(reducing the CCs by several thousand) In line... On 09-Mar-19 14:11, Spencer Dawkins at IETF wrote: > Hi, David, > > On Fri, Mar 8, 2019 at 5:52 PM David Noveck <davenoveck@gmail.com> wrote: > >> 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. >> > > Soon, I will not be the IESG Whisperer for this document, but we defined > test and documentation domains in https://tools.ietf.org/html/rfc2606, a > LONG time ago. If I'm reading https://tools.ietf.org/html/rfc2606#section-2 > and https://tools.ietf.org/html/rfc2606#section-3 correctly, the use of > ..example, or .example.com, is intended to avoid people copying a domain > name from documentation that someone is actually using now, or starts or > stops using in the future, along with all the possible paths through > confusion that could result. > > ISTM that ietf.org is in use now, so, picking a name that someone starts > using later isn't a problem, and if ietf.org stops working or starts > referring to the International Egret Trading Federation, we may have bigger > problems than this draft not using example.com ... > > But do the right thing, of course. I'm commenting only because I spent a little time with this draft as Gen-ART reviewer. Of course this draft can't change the domain name used in RFC5661 for the same purpose, which is already embedded in the IANA registry: https://www.iana.org/assignments/nfsv4-path-variables/nfsv4-path-variables.xhtml It isn't used for documentation; I think it's used to provide uniqueness in a naming structure. You could possibly argue that would be better done using something in .arpa (like IN-ADDR.ARPA and IP6.ARPA) but you'd have needed to argue that about ten years ago. So the right thing to do in this case is nothing ;-) Unintended side effect: such use of ietf.org ought to trigger the addition of ietf.org to the "technical" assignments referred to in note (a) on clause 4.3 of https://tools.ietf.org/html/rfc2860. Which incidentally means that our domain name is pretty well protected. Brian > > Spencer > > >> 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? >>>> >>>> >
- [secdir] Secdir last call review of draft-ietf-nf… Sean Turner
- Re: [secdir] Secdir last call review of draft-iet… David Noveck
- Re: [secdir] Secdir last call review of draft-iet… David Noveck
- Re: [secdir] Secdir last call review of draft-iet… Spencer Dawkins at IETF
- Re: [secdir] Secdir last call review of draft-iet… Brian E Carpenter