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

["Mkrtchyan, Tigran" <[e-mail]>]

Hi Roman,

----- Original Message -----
> From: "Chuck Lever" <[e-mail]>
> To: "Roman Danyliw" <[e-mail]>, "Tigran Mkrtchyan" <[e-mail]>
> Cc: "The IESG" <[e-mail]>, [e-mail], "nfsv4-chairs" <[e-mail]>, "NFSv4"
> <[e-mail]>
> Sent: Wednesday, July 8, 2020 5:43:57 PM
> Subject: Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)

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

The MUST implies that protocol require client to reject the connection to a server
which doesen't provide ipAddress, however, with SHOULD protocol delegates the decision
to the application, similar to how one can pass `-k` option to curl to bypass
certificate validation.

@Chuck
Feel free to change it to MUST, if it's more appropriate.

Thanks, 
   Tigran.

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