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

[David Noveck <[e-mail]>]

On Wed, Aug 26, 2020 at 1:58 PM Chuck Lever <[e-mail]> wrote:

>
>
> > On Aug 24, 2020, at 4:40 PM, David Noveck <[e-mail]> wrote:
> >
> >
> >
> > 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.
>

OK, but that doesn't mean the IESG will accept it.   Go ahead if you want
to try it
but if they object there is no point in continuing to knock your head
against the wall.

> >
> > > 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.
>
> Yes, "or stronger" was Gen-ART reviewer's complaint. I largely agree
> that the phrase is weasel-y.
>
>
> > > 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.
>
> I'm not sure that a list of digest algorithms is the right answer.
>

OK, If you think one will do, go for it.


>
> SHA-1 seems to be what everyone uses, and I haven't found any public
> document that states clearly that SHA-1 is not adequate for certificate
> fingerprinting.
>
> Even RFC 4387 (in Section 2.2) defines a certificate fingerprint as the
> SHA-1 hash of a certificate.
>

That document was published fourteen years ago.   Perhaps it needs to
be updated but we don't want to have to wait for that.

>
>
> > 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.
>
> Can you provide a reference to "the secure hash standard?"


 https://www.nist.gov/publications/secure-hash-standard

If that points
> to an RFC that can be obsoleted, that could be adequate. But again, I'm
> not sure that's the right thing to do if everyone else feels SHA-1 is
> adequate for the purpose of fingerprinting x.509 certificates.
>

I don't know what everyone else feels about this issue.   I don't a have
real opinion
as to SHA-1's adequacy for this purpose so I'm anxious about relying on
SHA-1 with
no fallback.

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