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

Chuck Lever <chuck.lever@oracle.com> Wed, 26 August 2020 17:58 UTC

Return-Path: <chuck.lever@oracle.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3273A1955; Wed, 26 Aug 2020 10:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ol2srg6vtmc4; Wed, 26 Aug 2020 10:58:51 -0700 (PDT)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6173A1953; Wed, 26 Aug 2020 10:58:51 -0700 (PDT)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 07QHsZRn184650; Wed, 26 Aug 2020 17:58:49 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2020-01-29; bh=S/Cu8Eea5lDH4CQjB6s+qqJ8no4lQ15TR5KCgpGvbt4=; b=QySq6PDb4DcBtHotqAWKzsTO2hwCYEYzxC+JQEbVltklXcYrgT+GHgsmaG3Ve2tUj+x4 yLzIeSidC/lfPVAgS80mwHsoynBMbzDpiNquSA5/kFB7Ot0MU5lmu4Cq15PbVE1TyNgu Gyt8NUAabrGkKarF+UJ8hJolzR27cMhoXK/1RV4e7ThCBHJCgbiuchCiuVqgT4CZneOm Z5N4CyBJQmDGmGRozgYRG70HGOXoO+HVwa+r7hg6+RIZ4lUzec0Nol3e6CCs8HQqc/P3 9GgrWrYHfckCj+/5Kb6oYfG0yvU0veSDVmwSE2Xu8O3L5gH/fmKKjEmzl0nEe7bfAU3g PA==
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 335gw83tta-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 26 Aug 2020 17:58:49 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 07QHuF2I066410; Wed, 26 Aug 2020 17:58:48 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 333ruauv11-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 26 Aug 2020 17:58:48 +0000
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 07QHwm8S001234; Wed, 26 Aug 2020 17:58:48 GMT
Received: from anon-dhcp-152.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Aug 2020 10:58:47 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <CADaq8jejNL3NRVRi7DSD6TOK_0e6UOWZt=gt+kzCZL8JUO8kzA@mail.gmail.com>
Date: Wed, 26 Aug 2020 13:58:46 -0400
Cc: NFSv4 <nfsv4@ietf.org>, draft-ietf-nfsv4-rpc-tls@ietf.org, nfsv4-chairs <nfsv4-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7962DB37-E760-4A8C-8AE8-F1161D3E61BF@oracle.com>
References: <159409225571.12966.1097397622994927028@ietfa.amsl.com> <9BEC1316-A219-408F-AB27-74B28D702148@oracle.com> <0B907D1D-5818-46F7-9ADE-091D945A2A32@oracle.com> <CADaq8jejNL3NRVRi7DSD6TOK_0e6UOWZt=gt+kzCZL8JUO8kzA@mail.gmail.com>
To: David Noveck <davenoveck@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9725 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 phishscore=0 bulkscore=0 suspectscore=0 spamscore=0 mlxscore=0 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008260133
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9725 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 lowpriorityscore=0 mlxscore=0 phishscore=0 bulkscore=0 impostorscore=0 adultscore=0 malwarescore=0 clxscore=1015 spamscore=0 mlxlogscore=999 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008260133
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/lLASaiO1aiZvfLx5AOTk_o4OEsA>
Subject: Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Aug 2020 17:58:53 -0000


> On Aug 24, 2020, at 4:40 PM, David Noveck <davenoveck@gmail.com> wrote:
> 
> 
> 
> On Mon, Aug 24, 2020 at 12:49 PM Chuck Lever <chuck.lever@oracle.com> 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 <chuck.lever@oracle.com> 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 <noreply@ietf.org> 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.

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.

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