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].