Re: [nfsv4] Roman Danyliw's No Objection on draft-ietf-nfsv4-rfc5661sesqui-msns-03: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

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 <
> [e-mail]> 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.  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
%     [...]

-Ben