Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)

[Chuck Lever <[e-mail]>]

Hi Roman-

Here are my responses to your COMMENTs in Section 5.


> On Jul 6, 2020, at 11:24 PM, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ** Section 5.2.1.  Per “For services accessed by their network identifiers
> (netids) and universal network addresses (uaddr), the iPAddress subjectAltName
> SHOULD be present in the certificate and must exactly …”, why not a normative
> MUST?

This language came from Tigran Mkrtchyan. Tigran, can you comment?


> ** Section 5.2.1.  Per “For example, if the Issuer is not in a trusted set of
> Issuers, the RPC server may decline to perform RPC transactions with this
> client.”, wouldn’t the TLS connection fail in this case and not even get to
> whatever authorization logic the RPC server might have?

I can remove this sentence.


> ** Section 5.2.1.  Per “As a suggestion, at least the following parameters of
> the X.509 client certificate SHOULD be exposed … Originating IP address”, how
> exactly should this IP address be exposed in the certificate, or is this
> intended to be the IP address of the peer which presented the certificate?

I believe this is the IP address of the peer which presented the certificate.


> ** Section 5.2.2 and 5.2.4.  Both 5.2.1 and 5.2.3 described what information
> should be exposed by implementations.  These sections omit that information. 
> For example, I would have expected Section 5.2.4 to discuss Token Binding IDs

PSK and Token Binding were added on request, and no further details were provided
by the requesters.


> ** Section 5.2.2.  Is there any MTI guidance on the kinds of digests to support
> for these fingerprints?

I've had some difficulty with this. Originally the document required SHA-1, as
it is the de facto standard algorithm for certificate fingerprinting. However,
subsequent security review pointed out that SHA-1 is deprecated.

I changed the requirement to SHA-256, but this is problematic: most fingerprint
implementations I'm aware of use SHA-1. I have found no published document that
suggests that SHA-1 is a problem for certificate fingerprinting, and no standard
that specifically discusses certificate fingerprinting algorithms.

During Gen-ART review, the reviewer complained about the comparative:

  Implementations MUST support SHA-256
  [FIPS.180-4] or stronger as the hash algorithm for the fingerprint.

Suggesting that the document would need to provide a fixed list of particular
algorithms here, rather than an open-ended requirement. I punted and removed
the sentence.

I'm not sure how to proceed.


> ** Section 5.2.4.  Are there any MTI parameters for the token binding to
> specify?

After reviewing RFC 8473, it appears that more changes to the RPC protocol would
be necessary to support Token Binding. Thus perhaps support for token binding in
this context should be deferred to a separate document. Can anyone with more
domain expertise comment?


--
Chuck Lever