Re: [nfsv4] Roman Danyliw's No Objection on draft-ietf-nfsv4-rfc5661sesqui-msns-03: (with COMMENT)
David Noveck <davenoveck@gmail.com> Thu, 02 January 2020 15:29 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 58636120018; Thu, 2 Jan 2020 07:29:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, 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 5vsvx-8jMTD8; Thu, 2 Jan 2020 07:29:20 -0800 (PST)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 5079F120142; Thu, 2 Jan 2020 07:29:19 -0800 (PST)
Received: by mail-ed1-x535.google.com with SMTP id e10so39388728edv.9; Thu, 02 Jan 2020 07:29:19 -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=eflFjVMv6kioPmtgnDChr9AOtPIjWeCNLRFh/eLobeM=; b=k4h/5DG2UelT8xUbNJKcu1wHgPfVEwR5h2uViUuHaNaaZ7QtXC0g4j3L/DBJIWOR/f TkBNJr0MleYnpPQy9korYf3lnZgmtSB/XtL3Yd4mow22g9MmCboWTPpNy5ZPi3g2qxbM TM5HZ5cQZFRyNcP6SB+C3NUhj6laRshIqgMIVMFSJSyZSH2PYjTfH1T+hmVFEY7KhGcm vSMFN3djHt/Eh93wY4Zn1S218ALSJ7OVqSdmBj9/R+yH9IF2oqTGJxJHvZiq431QE7gM xPpv0+6AjVomkUjy3nXr3LQXijUGl0b3IZdYMaQjchtxsNSySAJ7VYGu0HL8WBXMmi5/ 2/nw==
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=eflFjVMv6kioPmtgnDChr9AOtPIjWeCNLRFh/eLobeM=; b=KACA3hCm3N1/swYorvv1UdZdVyiCrYARvuVtJhzz+TPkKKG0TSY/HdVRnNrSTaiGcX tHcefTHyL+Y5MeonjzymSChnL3pSG4p4g0BED6eaMDkBmM1xfk1pDfLcgZApIr0W1rtN 9PAeqyqb2JZ016fwZusf9/yXX5bgnA0TtKe3bch+UO6d7lsLJLf1gI8a6AYiF2w5tZIP mnCmXlqWYTVY+CfSixhb5Za5GHktvkwNHNPGoXtIRYa9YwG0b6CPzCL7rQ7jhMYItr+N a6fmrJwI6NHCJC3+2anWY5rQYMdibWXfV6T9yr2p589aJZPa6pr5VvFrYvz8g7/8Y5Dd og8w==
X-Gm-Message-State: APjAAAUS9CnFMYbXQADaDUIjX8HgwiwK0Ty62MEmELvVJgu5vJbFRqIL RUOnn3oPpmnNN46p9QpqI++9+SOEzzld1tPuHr0hcw==
X-Google-Smtp-Source: APXvYqxNAu/+oEhfSFskArrgVgVwDGxPNZWxlQb01axILSjPNXtEmDKL2UA33C1YUj7WcaXfQw67NutOgO1NengRufw=
X-Received: by 2002:a17:906:2e53:: with SMTP id r19mr88032805eji.306.1577978957761; Thu, 02 Jan 2020 07:29:17 -0800 (PST)
MIME-Version: 1.0
References: <157663474296.5117.5297432225833522411.idtracker@ietfa.amsl.com>
In-Reply-To: <157663474296.5117.5297432225833522411.idtracker@ietfa.amsl.com>
From: David Noveck <davenoveck@gmail.com>
Date: Thu, 02 Jan 2020 10:29:06 -0500
Message-ID: <CADaq8jc5QdZ2sQ=buSH4dJFYdE0sMcFU-2sQMU6VtvM0ae5vRA@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-rfc5661sesqui-msns@ietf.org, nfsv4-chairs@ietf.org, Magnus Westerlund <magnus.westerlund@ericsson.com>, NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003d90fb059b29db23"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/AdLQzyePltmvCDU8juyHhjTS-hc>
Subject: Re: [nfsv4] Roman Danyliw's No Objection on draft-ietf-nfsv4-rfc5661sesqui-msns-03: (with COMMENT)
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, 02 Jan 2020 15:29:23 -0000
On Tue, Dec 17, 2019 at 9:05 PM Roman Danyliw via Datatracker < noreply@ietf.org> wrote: > Roman Danyliw has entered the following ballot position for > draft-ietf-nfsv4-rfc5661sesqui-msns-03: No Objection > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc5661sesqui-msns/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I conducted this review in the spirit of draft-roach-bis-documents-00 and > the > significant security caveats enumerated in Appendix C. A big thanks to > Sean > Turner for his SECDIR reviews and the authors for incorporating this > feedback > where appropriate. > > ** Section 1.1. The motivation for the editorial approach taken in this > document is cited as being in [I.D-roach-bis-documents] but there is not > such > reference in the document. > Will fix. ** The SECDIR review asked about retaining id-sha1 in Section 14.3. The WG > was > going to be consulted. What was the resolution? It turns out that I dropped the ball on that when that issue was raised in February. Sorry about that. I raised the isse with the working group recently, but don't anticipate any feedback soon. I was originally worried about the possibility of interoperability issues, but have concluded that they are most unlikely to exist, even if we did remove id-sha1 as REQUIRED to be supported by the server. In part this is because there han't been much impementation activity for SP4_SSV but also because it would take a client specifying an ssp_hash_alg that *only* specfified id-sha1 and a sever that decided, once the new document was published, decding not to support it. The chance of that happening anytime soon are miniscule. In the spirit of this focused > review, keeping it REQUIRED doesn’t present an issue, IMO. True. > However, would > there be a reduced set of algorithms that could be RECOMMENDED in the > Security > Considerations? > That could mean several things: - Recommending that the client not include id-sha1 in ssp_hash_algs. - Recommending that the server, while supporting id-sha1, not select it if the client has specfied anyother supported algorithm in ssp_hash_algs. In general, my tendency has been to try deferesecurity fixes to rfc5661bis, rather than doing things piecemeal. At times, I've worried about a slippery-slope effect. However, given the the weaknesses of sha1, I think we have enough traction to address this via the recommendations above in sesqui and discuss the possibility of a change in required algorithms as part of rfc5661bis. One possibility I have considered is rewrting the ssp_hash_algs part of Section 18.35.3 to read as follows: ssp_hash_algs: This is the set of algorithms the client supports for the purpose of computing the digests needed for the internal SSV GSS mechanism and for the SET_SSV operation. Each algorithm is specified as an object identifier (OID). The REQUIRED algorithms for a server are id-sha1, id-sha224, id-sha256, id-sha384, and id-sha512 [25]. Due to to weaknesses in id-sha1, it is RECOMMENDED that the client specify at least one algorithm within ssp_hash_algs other than id- sha1. The algorithm the server selects among the set is indicated in spi_hash_alg, a field of spr_ssv_prot_info. The field spi_hash_alg is an index into the array ssp_hash_algs. Because of the weaknesses in id-sha1, it is RECOMMENDED that it not be selected as long as ssp_hash_algs contains any other supported algorithm. If the server does not support any of the offered algorithms, it returns NFS4ERR_HASH_ALG_UNSUPP. If ssp_hash_algs is empty, the server MUST return NFS4ERR_INVAL > > ** Section 21, Per “When DNS is used to convert server names to addresses > and > DNSSEC [29] is not available, the validity of the network addresses > returned > cannot be relied upon.”, this concern about the fidelity of the DNS > information > is a helpful consideration. It would be worth mentioning/recommending the > use > of other DNS technologies such as DNS over TLS [RFC7858] and DNS over HTTPS > [RFC8484] that could provide additional/alternatives confidence mechanisms > in > the DNS data. > > Will add. Could revise that bullet to read as follows: o When DNS is used to convert server names to addresses and none of DNSSEC [30], DNS over TLS [31], and DNS over HTTPS [35] are available, the validity of the network addresses returned cannot be relied upon. However, when the client uses RPCSEC_GSS to access the designated server, it is possible for mutual authentication to discover invalid server addresses provided, as long as the RPCSEC_GSS implementation used does not use insecure DNS queries to canonicalize the hostname components of the service principal names, as explained in [29].
- [nfsv4] Roman Danyliw's No Objection on draft-iet… Roman Danyliw via Datatracker
- Re: [nfsv4] Roman Danyliw's No Objection on draft… David Noveck
- Re: [nfsv4] Roman Danyliw's No Objection on draft… Benjamin Kaduk
- Re: [nfsv4] Roman Danyliw's No Objection on draft… David Noveck
- Re: [nfsv4] Roman Danyliw's No Objection on draft… Benjamin Kaduk
- Re: [nfsv4] Roman Danyliw's No Objection on draft… David Noveck
- Re: [nfsv4] Roman Danyliw's No Objection on draft… Benjamin Kaduk