Re: [nfsv4] Roman Danyliw's No Objection on draft-ietf-nfsv4-rfc5661sesqui-msns-03: (with COMMENT)
David Noveck <davenoveck@gmail.com> Sun, 05 January 2020 16:52 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 597E81200FA; Sun, 5 Jan 2020 08:52:14 -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 LFDP2wkJodO0; Sun, 5 Jan 2020 08:52:10 -0800 (PST)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 2B265120018; Sun, 5 Jan 2020 08:52:10 -0800 (PST)
Received: by mail-ed1-x530.google.com with SMTP id cy15so45583684edb.4; Sun, 05 Jan 2020 08:52:10 -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=a9fTJNqzNXNhWJOgtq3m28O49PsC57CqFaSPAlo4yoQ=; b=hN4IMajF7TTdPWTccs3f5hL+KEqXbbvV5QQu9XXrLkLVUEnn2mmbgSxUo3W/Zv+9yi c/yS5xkzcnXMEJwnCb5Hx4Z3qU7T5UQly0rcaczFTFyG1pwVEa2QG6/uAzSqpQfZ4h0I TU1H5fHKaZNC6AXXkILaV10wFepDI8/CTpyyPoAeHBokKCZTl4VpZkdSWaAv/aZFb3xz tDKr09OitoNWoiKG7qxfkbg84B5DZS7BVq3gTv6b0wHjv7vPa/d+JQuXdrKp2OOg7IUz eZmWPk2RymQPMQY542p5/VEs1Uxf3dk8t409pc5Hdj8JgICgBtegiOt0WSCjaUC018Lt 3UKg==
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=a9fTJNqzNXNhWJOgtq3m28O49PsC57CqFaSPAlo4yoQ=; b=SbHRDQazDub0amIjV8S7J28a0Tun16/GFsnsgPdXwZa2liuM2P4sla5nO06sReXpO2 xdtkzf4hq/xNXjnidxp82B49PTGLguGHjM/xaNgGBlOmwQkka2pNzqL/BB931dwJDRUQ rKVPNn03cAU6UbIhHl0y/uicpeG8REYH+n9ADULqdUnHWCsOxXG0HN5JwVfaeRp2VLV2 HUPWje3N6skR04UNDPXOpjRkOoOsX1wECyobkfcOhIOIB5aNIPLVOcit76cJa1Nq2JKn SYgwr1HWq88OqjJyEwZI3yPaOXsYiwB71HUEwnjM9hXMOxTdgaZWLFtCrZOB8te5d86+ UuWw==
X-Gm-Message-State: APjAAAWTt6hzbuha3VQdzKaETDan5Zo1G1yCWpN+KWePluWVzUvYBna2 CehzAiKGOhi4mIHW2s0G0NAbAkcdjyblKiv0l7eIBw==
X-Google-Smtp-Source: APXvYqwtk9bhcoK/5IxHYxJJvdZBRZrzhAcFaGeRqEwEOgA7cQnIb7WQV4c4uxJzZ6ohCwT4t4Wws7o4nX09ZnSW5d8=
X-Received: by 2002:a17:906:7b96:: with SMTP id s22mr103490924ejo.213.1578243128508; Sun, 05 Jan 2020 08:52:08 -0800 (PST)
MIME-Version: 1.0
References: <157663474296.5117.5297432225833522411.idtracker@ietfa.amsl.com> <CADaq8jc5QdZ2sQ=buSH4dJFYdE0sMcFU-2sQMU6VtvM0ae5vRA@mail.gmail.com> <20200104070223.GM57294@kduck.mit.edu>
In-Reply-To: <20200104070223.GM57294@kduck.mit.edu>
From: David Noveck <davenoveck@gmail.com>
Date: Sun, 05 Jan 2020 11:51:56 -0500
Message-ID: <CADaq8jd1u3EdOoEB+A0Jkn9YBfKphy2cSTPPohBs5pr57CnsEA@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Roman Danyliw <rdd@cert.org>, draft-ietf-nfsv4-rfc5661sesqui-msns@ietf.org, The IESG <iesg@ietf.org>, NFSv4 <nfsv4@ietf.org>, nfsv4-chairs@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000b4992059b675d04"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/KXvl_4kGepYEQY8VXtF01TEvXe4>
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: Sun, 05 Jan 2020 16:52:15 -0000
On Sat, Jan 4, 2020, 2:02 AM Benjamin Kaduk <kaduk@mit.edu> wrote: > On Thu, Jan 02, 2020 at 10:29:06AM -0500, David Noveck wrote: > > 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 > > > > [...] > > > > > > ** 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]. > > This is a fairly subtle area, and it's pretty hard to write something > that's 100% accurate. It looks like what I came up with is 60% accurate at best. Specifically > , it's still possible for the returned > network addresses to still be unreliable even when DoT or DoH are used > (though they do provide significant protection over traditional > DNS-on-port-53). This all comes back to DNS resolution (generally) being a > multi-stage process, with stub resolver talking to recursive talking to > authority. Only the authority is, well, authoritative for the returned > results (addresses), and the only end-to-end way to provide authentication > for the results is DNSSEC. But, DoT and DoH provide integrity protection > for the stub-to-recursive leg (in current usage; in theory they can also be > used from recursive to authority), and when the recursive is trusted, that > combines to provide trust in the returned addresses even if there is not > necessarily cryptographic protection between recursive and authority. [more > discussion of various attacks and the subtle differences in provided > protection elilded]. > > So, my suggestion would be a different approach, along the lines of: > > % o When DNS is used to convert server names to addresses and DNSSEC > % [29] is not available, the validity of the network addresses > % returned generally cannot be relied upon, though when combined with a > % trusted resolver, DNS over TLS [31] and DNS over HTTPS [35] can also > % provide resolved addresses in a reliable manner. However, when the > % [...] > How about the following, which is based on your treatment above? It divides the discussion into two paragraphs: one about DNS result validity and the other about steps to deal with the possibility of invalidity: - When DNS is used to convert server names to addresses and DNSSEC [29] is not available, the validity of the network addresses returned generally cannot be relied upon. However, when combined with a trusted resolver, DNS over TLS [31] and DNS over HTTPS [35] can also be relied upon to provide valid address resolutions. In situations in which the validity of the provided addresses cannot be relied upon and the client uses RPCSEC_GSS to access the designated server, it is possible for mutual authentication to discover invalid server addresses 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