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

From: Chuck Lever <[email-masked]>
Date: Tue, 4 Aug 2020 08:58:50 -0400

Hi Roman-

This review process has been waiting on your response for a month.

> On Jul 20, 2020, at 8:32 AM, Chuck Lever <[email-masked]> wrote:
> 
> Hi Roman-
> 
> I haven't heard any response on these items. Is there something more
> you need from me?
> 
> 
>> On Jul 7, 2020, at 11:15 AM, Chuck Lever <[email-masked]> wrote:
>> 
>> Hi Roman-
>> 
>> Thanks for your review and comments. If I may, I'd like to handle
>> the DISCUSS first, and then respond to the COMMENTs in a separate
>> reply.
>> 
>> 
>>> On Jul 6, 2020, at 11:24 PM, Roman Danyliw via Datatracker <[email-masked]> wrote:
>>> 
>>> Roman Danyliw has entered the following ballot position for
>>> draft-ietf-nfsv4-rpc-tls-08: Discuss
>>> 
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>> 
>>> ** Despite Section 5.0 stating that only TLS v1.3+ can be used, there are two
>>> references to TLS v1.2 mechanisms:
>> 
>> Good catch!
>> 
>> 
>>> -- Section 5.0. Per “Implementations MUST support certificate-based mutual
>>> authentication.  Support for TLS-PSK mutual authentication [RFC4279] is
>>> OPTIONAL”.  Shouldn’t Section 2.2.2 or 4.2.11 of RFC8446 be used instead?
>> 
>> In fact Section 5.2.3 already cites RFC8446 Section 2.2. I propose changing
>> Section 5.0 as follows:
>> 
>> OLD:
>> 
>>  *  Implementations MUST support certificate-based mutual
>>     authentication.  Support for TLS-PSK mutual authentication
>>     [RFC4279] is OPTIONAL.  See Section 4.2 for further details.
>> 
>> NEW:
>> 
>>  *  Implementations MUST support certificate-based mutual
>>     authentication.  Support for PSK mutual authentication is
>>     OPTIONAL; see Section 5.2.3 for further details.
>> 
>> 
>>> -- Section 5.2.4.  The token binding mechanism suggested here, RFC8471, only
>>> applies to TLS v1.2.  The expired draft-ietf-tokbind-tls13 provides the TLS
>>> v1.3 mechanism.
>> 
>> Potential replacement:
>> 
>> OLD:
>> 
>> 5.2.4.  Token Binding
>> 
>>  This mechanism is OPTIONAL to implement.  In this mode, a token
>>  uniquely identifies the RPC peer.
>> 
>>  Versions of TLS after TLS 1.2 contain a token binding mechanism that
>>  is more secure than using certificates.  This mechanism is detailed
>>  in [RFC8471].
>> 
>> NEW:
>> 
>> 5.2.4.  Token Binding
>> 
>>  This mechanism is OPTIONAL to implement.  In this mode, a token
>>  uniquely identifies the RPC peer.  The TLSv1.3 token binding
>>  mechanism is detailed in [I-D.ietf-tokbind-tls13].
>> 
>> 
>> Another option would be to remove this section.
>> 
>> 
>>> ** Section 7.4.  Per “When using AUTH_NULL or AUTH_SYS, both peers are required
>>> to have DNS TLSA records and certificate material …”, what is “certificate
>>> materials”?  Can this guidance please be clarified (and perhaps related to the
>>> options specified in Section 5.2).
>> 
>> Potential replacement:
>> 
>> OLD:
>> 
>>  *  When using AUTH_NULL or AUTH_SYS, both peers are required to have
>>     DNS TLSA records and certificate material, and a policy that
>>     requires mutual peer authentication and rejection of a connection
>>     when host authentication fails.
>> 
>> NEW:
>> 
>>  *  When using AUTH_NULL or AUTH_SYS, both peers are required to have
>>     DNS TLSA records, keys with which to perform mutual peer
>>     authentication using one of the methods described in Section 5.2,
>>     and a security policy that requires mutual peer authentication and
>>     rejection of a connection when host authentication fails.
> 
> --
> Chuck Lever
> 
> 
> 

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Sat, 8 Aug 2020 19:31:17 -0400

On August 4th, Chuck Lever wrote:
> This review process has been waiting on your response for a month

Actually it was only 27 days then, since the messages that Chuck was
waiting for response to were only sent 7/7-8. Now that it has been a full
month, I think it is appropriate to look at where we are and how to  best
proceed on this review.

Considerable progress has been made on this document since IESG
Consideration began on 6/22. I'd like to thank everybody who participated
in moving this document toward being ready for RFC editing and subsequent
publication.   Clearly, we need to incorporate the many suggestions that
have been made in a new document revision.   However, I am afraid that, if
we continue as we have been,, we are facing an essentially unbounded delay
in moving this work forward.

Has anybody receiving this been in contact with Roman over the last month?
 I'm afraid he might be sick, in  which case we all wish him a speedy
recovery.   We haven't seen any out-of-the-office mail so he probably isn't
on vacation. I'd appreciate any info people have that bears on the question
of when we might expect a  response.  In any case, given the history so
far, it doesn't seem very likely that we will see a quick resolution of
this.

Chuck has, for understandable reasons, been reluctant to start on the
remaining DISCUSS (which is Ben K.'s, I believe) untIl we see closure
on the current one.   However, given the ongoing delay in receiving Roman's
response, I think it would be best if we moved on without waiting for a
response from Roman himself.   It would be helpful if the IESG as a whole
could look at Chuck's response to Roman's DISCUSS and COMMENTs and point
out any problems.   This would be especially important in the case of those
who supported Roman's DISCUSS (Ben K. at least). This might allow Chuck an
opportunity to deal with any issues/gaps that people see and allow him to
move on to deal with the final DISCUSS holding this up.

This will provide some additional time for Roman to get into contact,
without holding up the process waiting.   If he is able to get into
contact, he can make his own judgement about the adequacy of Chuck's
response.  Then, if the delay continues indefinitely, the IESG could
consider necessary administrative steps to allow the document to go forward
in the absence of Roman's participation.

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 21 Aug 2020 19:45:06 +0000

Hi David and Chuck!

Thanks for your patience and my apologize for the delay.  More inline …

Regards,
Roman

On Tue, Aug 4, 2020 at 8:59 AM Chuck Lever <[email-masked]<mailto:[email-masked]>> wrote:
>> On Jul 7, 2020, at 11:15 AM, Chuck Lever <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Hi Roman-
>>
>>> On Jul 6, 2020, at 11:24 PM, Roman Danyliw via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
>>>
[Roman] Make sense.  Thanks.
>> Another option would be to remove this section.

I leave this up to the working group/responsible AD to sort out.  My DISCUSS is on the fact this this behavior needs to be specified for TLS v1.3 not on how it gets documented.  My recommendation would be to remove the section – there is no IETF consensus reference for this behavior.  This binding can always be specified later.  If there is a desire to use ietf-tokbind-tls13 and there is work planned to publish it (i.e., pull it out of expired state and iterate to completion), this document could also wait in a MISREF state with the RFC Editorial until it is published.  I suspect there is also the option of re-calling consensus on the document for a downref to an unpublished document.  I’m flexible.

>>     rejection of a connection when host authentication fails.
[Roman] Works for me.  Thank you.

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Fri, 21 Aug 2020 16:46:58 -0400

To the WG:

> On Aug 21, 2020, at 3:45 PM, Roman Danyliw <[email-masked]> wrote:
> 

It seems to me that leaving this section in place introduces an
indeterminate delay before publication. At this point my preference
would be to remove all discussion of token binding, since it's not
clear when TLS v1.3 will properly support it.

Is there any objection to removal?

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Sat, 22 Aug 2020 04:49:56 -0400

no objection on my part.

On Fri, Aug 21, 2020, 4:49 PM Chuck Lever <[email-masked]> wrote:

> > I leave this up to the working group/responsible AD to sort out.  My
> DISCUSS is on the fact this this behavior needs to be specified for TLS
> v1.3 not on how it gets documented.  My recommendation would be to remove
> the section – there is no IETF consensus reference for this behavior.  This
> binding can always be specified later.  If there is a desire to use
> ietf-tokbind-tls13 and there is work planned to publish it (i.e., pull it
> out of expired state and iterate to completion), this document could also
> wait in a MISREF state with the RFC Editorial until it is published.  I
> suspect there is also the option of re-calling consensus on the document
> for a downref to an unpublished document.  I’m flexible.
>

---

From: Chuck Lever <[email-masked]>
Date: Mon, 24 Aug 2020 12:49:04 -0400

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 <[email-masked]> wrote:
> 
> Hi Roman-
> 
> Here are my responses to your COMMENTs in Section 5.
> 
> 
>> 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

---

From: David Noveck <[email-masked]>
Date: Mon, 24 Aug 2020 16:40:04 -0400

> comment still stands for Certificate Fingerprints (Section 5.2.2).

I'll try to help.

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

 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.

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

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.

> > 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"  :-(

---

From: Chuck Lever <[email-masked]>
Date: Wed, 26 Aug 2020 13:58:46 -0400

> On Aug 24, 2020, at 4:40 PM, David Noveck <[email-masked]> wrote:
> 
> 
> 
> That doesn't count for much.   After all, the de facto  standard for NFS authentication is AUTH_SYS.
>   
> However,
>  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.
> 
> > 
> It appears it is too insecure to get through the IESG but not so insecure that people have stopped using it.
>  
> 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.

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

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.

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

---

From: David Noveck <[email-masked]>
Date: Wed, 26 Aug 2020 14:21:31 -0400

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

> >  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.
> >
> > >
> > It appears it is too insecure to get through the IESG but not so
> insecure that people have stopped using it.
> >

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.

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

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

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

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

---

From: Chuck Lever <[email-masked]>
Date: Fri, 28 Aug 2020 14:05:52 -0400

> On Aug 26, 2020, at 2:21 PM, David Noveck <[email-masked]> wrote:
> 
> 
> 
> 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.
> 
> > > 
> 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. 
> 
> 

After thinking about it more, it probably is not sensible to
include the section on fingerprints. I'll remove it and move
on to Ben's DISCUSS comments.

--
Chuck Lever