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

On Sun, Jan 05, 2020 at 11:51:56AM -0500, David Noveck wrote:
> 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].

That all looks good; thanks for applying a nice wordsmithing touch!

-Ben

_______________________________________________
nfsv4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4