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

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

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