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

On Fri, Jan 10, 2020 at 06:06:38AM -0500, David Noveck wrote:
> 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.

Correct.  (In fact, it's fairly common for ADs to not formally withdraw the
DISCUSS until the revised I-D is in the repository, though by no means
required.)

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

I see your notes from 12/20 in my inbox but they arrived while my inbox was
in disarray and got queued for processing, which took longer than
anticipated :(

I'll probably get to respond to them tomorrow, and sorry for the delay.

-Ben

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