Re: [nfsv4] Roman Danyliw's No Objection on draft-ietf-nfsv4-rfc5661sesqui-msns-03: (with COMMENT)
David Noveck <davenoveck@gmail.com> Fri, 10 January 2020 11:06 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 730FD120020; Fri, 10 Jan 2020 03:06:56 -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 DJh0OlK4BPBO; Fri, 10 Jan 2020 03:06:53 -0800 (PST)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 8FAB512001B; Fri, 10 Jan 2020 03:06:53 -0800 (PST)
Received: by mail-ed1-x52a.google.com with SMTP id l8so1184646edw.1; Fri, 10 Jan 2020 03:06:53 -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=9Kxmd5QnQZFpOhzBKAzhCjxzSKgwGjiKgWV6G29CxUs=; b=iPZheWj1CjbKPozoHhJSbqKr3RNJqpyzP+YMToQUk5U/oeuhq2N5kXKNlYT3JUC7Xt KPKzEB4qtEQ5bxjP2tE15EGNKk+vCETV2WHpF2Z++XWThKdRsjd+t8clGpHBZ3p3qrX0 T7ayqrQyLKP7dvKdb/IZ0XpyrjgZd4grdRfydTl3N256AVenBz8bcG2svZHZQP6nH5Q5 fq8htnmtGrSZu5lV3Vz2JOZHPJfTR2nuPyFi9nmUzYGEboXTQVLEviQtrH7pS8HEyBiK oHqkFIWTHine/jpO1w47JkTCYQ+vYHR05YoI5Yw1X5HJHs5oiQ7JqEV/zA6wqNTwPbn6 oDjA==
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=9Kxmd5QnQZFpOhzBKAzhCjxzSKgwGjiKgWV6G29CxUs=; b=YCrXHPb97EfPHFeO+Zftz/ugVnTsu2aZBirUsIFAns8rrwASN2sghS8E/XDwRZYTho nlwAzB8ObWuvSM1qElhmmLb4th1sRDd1t2UeIpkt3ZeAdU0UW6jmi3/9YJkzsE3gn4pw 9xsNkxCDxxQKKAKND+yjL70w6Rqd0F31NwoNhzrWzgolOTkxI41Kq10kfY3s4MvaE5Kh R7E0bpaEi2jtdEFBeJqCAVSgOwKTc1XdoyI1zROEM2pQiZD4P2FOecs0p9rI0qic1T5Y iG106fnVBXNv1asmAFIasPS416jjok3WXE97B5sNZERj/XiVg9W9nwZTQlyL/aNwLKD6 03Mw==
X-Gm-Message-State: APjAAAW4PinG/MXYBRGzbQ2v5zlqvmpYzx6MS/E72KS6o+i5ETYij2Kj 6BARJdPOLdMCrMQdaf8EacyXZcnRvFbuhacV/vXyTA==
X-Google-Smtp-Source: APXvYqxS5qzmbcSmT7QjxCL/jIE05cTjPmq9P3VW7HMDE0Yc4Tyi0jE0Np4l23CUznOxHUY+68Q20TNTsN1Xkr+MTNc=
X-Received: by 2002:a05:6402:c8a:: with SMTP id cm10mr2887902edb.287.1578654412016; Fri, 10 Jan 2020 03:06:52 -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> <CADaq8jd1u3EdOoEB+A0Jkn9YBfKphy2cSTPPohBs5pr57CnsEA@mail.gmail.com> <20200109235704.GJ57294@kduck.mit.edu>
In-Reply-To: <20200109235704.GJ57294@kduck.mit.edu>
From: David Noveck <davenoveck@gmail.com>
Date: Fri, 10 Jan 2020 06:06:38 -0500
Message-ID: <CADaq8jc7bTdggjC2Y8m0X8HsMiMm8V3pm1HbgohhHJRBMy9-UA@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="000000000000738e78059bc71f7f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/WKSZyjcvWPtBGKKi1HuLFKvTEK0>
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: Fri, 10 Jan 2020 11:06:56 -0000
On Thu, Jan 9, 2020 at 6:57 PM Benjamin Kaduk <kaduk@mit.edu> wrote: > On Sun, Jan 05, 2020 at 11:51:56AM -0500, David Noveck wrote: > > 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]. > > That all looks good; thanks for applying a nice wordsmithing touch! > > -Ben > It will appear that way in -04. Clarifying where we are on getting to -04: - I think I responded to your DISCUSS on 12/20 and that we resolved any discrepancies on 1/2. I'm assuming that none of this would prevent submission of -04, even though the DISCUSS has not been formally withdrawn. - I addressed your other non-DISCUSS COMMENTs in an mail on 1/2 but have not heard back so I'm unclear what issues still need to be resolved. Also if there are other comments/issues that people have that have not been addressed, please raise them now. My impression is that all have been but I want to make sure nothing has slipped through the cracks.
- [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