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

[David Noveck <[e-mail]>]

On Mon, Aug 24, 2020 at 12:49 PM Chuck Lever <[e-mail]> wrote:

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

I'll try to 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.


That's putting it mildly.   The whole thing is kind of Sisyphean :-(


> Originally the document required SHA-1, as
> > it is the de facto standard algorithm for certificate fingerprinting.


That doesn't count for much.   After all, the de facto  standard for NFS
authentication is AUTH_SYS.


> However,
> > subsequent security review pointed out that SHA-1 is deprecated.
>

 I can see that it would be hard to get this  accepted without the ability
to the ability to argue cogently that SHA-1 weaknesses are not relevant in
this case.

>
> > I changed the requirement to SHA-256, but this is problematic: most
> fingerprint
> > implementations I'm aware of use SHA-1.


It appears it is too insecure to get through the IESG but not so insecure
that people have stopped using it.


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

I can see the "or stronger" being an issue.  It is often the case that it
is not completely clear whether A is stronger than B.

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


The only issue  I see if you can get a list including SHA-1 accepted.   It
is easier than SHA-1 alone but not a sure bet.   you might be able to sell
it as a stop-gap, if there are ways to upgrade it later, especially if this
is part of pushing AUTH-SYS towards the scrapheap of history.

SHA-1 + SHA-256 is one possible list.  The other is to include everything
within the secure hash standard.

I'm think of rpc-tls allowing other layers in the stack to impose
further restrictions on the algorithm to be used, e.g.

   - Allowing ULPs to require specific hash algorithms.    This would allow
   us to get rpc-tls out now and upgrade it when draft-ietf-nfsv4-security is
   out.
   - Allowing RPC to require specific hash algorithms when used for
   particular purposes such as verifying the identity of a client host using
   AUTH_SYS.     This would allow us to get rpc-tls out now and upgrade it
   when an update to RFC5531 dealing with AUTH_SYS is out.

I punted and removed
> the sentence.
>

I think going for a field goal would have been better.  Then again, I'm not
trying to do that while a seven-footer is running toward me is waving his
huge arms and screaming "DEPRECATED"  :-(

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