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

On Thu, Jan 9, 2020 at 6:57 PM Benjamin Kaduk <[email protected]> wrote:

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

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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4