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

On Sat, Jan 4, 2020, 2:02 AM Benjamin Kaduk <[email protected]> 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 <
> > [email protected]> 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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4