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

From: David Noveck <[email-masked]>
Date: Thu, 2 Jan 2020 10:29:06 -0500

On Tue, Dec 17, 2019 at 9:05 PM Roman Danyliw via Datatracker <
[email-masked]> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-nfsv4-rfc5661sesqui-msns-03: No Objection
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc5661sesqui-msns/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I conducted this review in the spirit of draft-roach-bis-documents-00 and
> the
> significant security caveats enumerated in Appendix C.  A big thanks to
> Sean
> Turner for his SECDIR reviews and the authors for incorporating this
> feedback
> where appropriate.
>
> ** Section 1.1.  The motivation for the editorial approach taken in this
> document is cited as being in [I.D-roach-bis-documents] but there is not
> such
> reference in the document.
>

Will fix.

** The SECDIR review asked about retaining id-sha1 in Section 14.3.  The WG
> was
> going to be consulted.  What was the resolution?

It turns out that I dropped the ball on that when that issue was raised in
February.  Sorry about that.

I raised the isse with the working group recently, but don't anticipate any
feedback soon.

I was originally worried about the possibility of interoperability issues,
but have concluded that they are
most unlikely to exist, even if we did remove id-sha1 as REQUIRED to be
supported by the server.
In part this is because there han't been much impementation activity for
SP4_SSV but also because
it would take a client specifying an ssp_hash_alg that *only* specfified
id-sha1 and a sever that decided,
once the new document was published, decding not to support it.   The
chance of that happening anytime
soon are miniscule.

In the spirit of this focused
> review, keeping it REQUIRED doesn’t present an issue, IMO.

True.

> However, would
> there be a reduced set of algorithms that could be RECOMMENDED in the
> Security
> Considerations?
>

That could mean several things:

   - Recommending that the client not include id-sha1 in ssp_hash_algs.
   - Recommending that the server, while supporting id-sha1, not select it
   if the client has specfied anyother supported algorithm in ssp_hash_algs.

In general, my tendency has been to try deferesecurity fixes to rfc5661bis,
rather than doing things piecemeal.  At times, I've worried about a
slippery-slope effect.   However, given the the weaknesses of sha1,  I
think we have enough traction to address this via the recommendations above
in sesqui and discuss the possibility of a change in required algorithms as
part of rfc5661bis.

One possibility I have considered is rewrting the ssp_hash_algs part   of
Section 18.35.3 to read
as follows:

   ssp_hash_algs:

      This is the set of algorithms the client supports for the purpose
      of computing the digests needed for the internal SSV GSS mechanism
      and for the SET_SSV operation.  Each algorithm is specified as an
      object identifier (OID).  The REQUIRED algorithms for a server are
      id-sha1, id-sha224, id-sha256, id-sha384, and id-sha512 [25].

      Due to to weaknesses in id-sha1, it is RECOMMENDED that the client
      specify at least one algorithm within ssp_hash_algs other than id-
      sha1.

      The algorithm the server selects among the set is indicated in
      spi_hash_alg, a field of spr_ssv_prot_info.  The field
      spi_hash_alg is an index into the array ssp_hash_algs.  Because of
      the weaknesses in id-sha1, it is RECOMMENDED that it not be
      selected as long as ssp_hash_algs contains any other supported
      algorithm.

      If the server does not support any of the offered algorithms, it
      returns NFS4ERR_HASH_ALG_UNSUPP.  If ssp_hash_algs is empty, the
      server MUST return NFS4ERR_INVAL

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 3 Jan 2020 23:02:23 -0800

> > draft-ietf-nfsv4-rfc5661sesqui-msns-03: No Objection
[...]
>       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

---

From: David Noveck <[email-masked]>
Date: Sun, 5 Jan 2020 11:51:56 -0500

On Sat, Jan 4, 2020, 2:02 AM Benjamin Kaduk <[email-masked]> wrote:

> 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

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 9 Jan 2020 15:57:04 -0800

> principal names, as explained in [29].

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

-Ben

---

From: David Noveck <[email-masked]>
Date: Fri, 10 Jan 2020 06:06:38 -0500

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

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

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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 12 Jan 2020 23:49:45 -0800

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