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

[Chuck Lever <[e-mail]>]

Hi nfsv4-

The latest updates to address Roman Danyliw's ballot comments have
been pushed to: 

https://chucklever.github.io/i-d-rpc-tls/draft-ietf-nfsv4-rpc-tls.html

Before I can reach closure on these comments, I'm still in need of
guidance for resolving the following issues with Section 5.2.2 of
rpc-tls.

(Ben's DISCUSS still remains. I plan to address those when closure
on Roman's comments has been reached).


> On Jul 8, 2020, at 11:43 AM, Chuck Lever <[e-mail]> wrote:
> 
> 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.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.

Token Binding (Section 5.2.4) has been removed. However, Roman's
comment still stands for Certificate Fingerprints (Section 5.2.2).

Can anyone help?


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

Any advice is welcome. I'd like to keep the discussion of the use of
Certificate Fingerprints, if possible.


--
Chuck Lever