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

Chuck Lever <chuck.lever@oracle.com> Wed, 08 July 2020 15:46 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 7FBD73A0E5B; Wed, 8 Jul 2020 08:46:12 -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 yOqdyKvaPvkt; Wed, 8 Jul 2020 08:46:11 -0700 (PDT)
Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 167D73A0E5A; Wed, 8 Jul 2020 08:46:10 -0700 (PDT)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 068FbsFs052561; Wed, 8 Jul 2020 15:46:05 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=omdFTegKxcJ+EBYGgmp7AqafVGCc0SJTycrvyIHun8g=; b=u177BK56yZtRd05vJdriNrHburSrLOo9aLePVovF/nt2QzwULLgdd5o5YjpPrs+UXZbX ZSNo39XVqy8qmWTyE/d5yR4MqRwIPFrBrFbtsaOaF+qV2/cKtRAh0sFrvDAz7/4mmw/6 akxKkKMjO3yvuesbX1w+Z/5Caw5PCifKbG9LseVZwPszHo6xDyyUoMexfadWFD3WtOvt 2RrDEoqD+t0tP7O6XuUx+FJvFyDwqDtQ4otJDoT8crz+O2rAIWtehHW5WhkzZET67e62 jWLsFRcwrQFl6ps3UjhO6C5xAyFUKyLMryp7o7BQswlug0Za3XlYqOgThuNE6NkEWLAw sQ==
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 325bgf24t7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 08 Jul 2020 15:46:05 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 068FdEla131641; Wed, 8 Jul 2020 15:44:05 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3030.oracle.com with ESMTP id 3233br265h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 08 Jul 2020 15:44:04 +0000
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 068FhxAh025934; Wed, 8 Jul 2020 15:43:59 GMT
Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 08 Jul 2020 08:43:59 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <159409225571.12966.1097397622994927028@ietfa.amsl.com>
Date: Wed, 8 Jul 2020 11:43:57 -0400
Cc: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-rpc-tls@ietf.org, nfsv4-chairs@ietf.org, nfsv4@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9BEC1316-A219-408F-AB27-74B28D702148@oracle.com>
References: <159409225571.12966.1097397622994927028@ietfa.amsl.com>
To: Roman Danyliw <rdd@cert.org>, "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>
X-Mailer: Apple Mail (2.3445.104.14)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9676 signatures=668680
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 adultscore=0 malwarescore=0 spamscore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2007080106
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9676 signatures=668680
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0 cotscore=-2147483648 clxscore=1011 mlxscore=0 spamscore=0 bulkscore=0 suspectscore=0 mlxlogscore=999 malwarescore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2007080106
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/JaQP9mLy5GhVKkONh39IfPvcNbg>
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, 08 Jul 2020 15:46:13 -0000

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.1.  Per “For services accessed by their network identifiers
> (netids) and universal network addresses (uaddr), the iPAddress subjectAltName
> SHOULD be present in the certificate and must exactly …”, why not a normative
> MUST?

This language came from Tigran Mkrtchyan. Tigran, can you comment?


> ** Section 5.2.1.  Per “For example, if the Issuer is not in a trusted set of
> Issuers, the RPC server may decline to perform RPC transactions with this
> client.”, wouldn’t the TLS connection fail in this case and not even get to
> whatever authorization logic the RPC server might have?

I can remove this sentence.


> ** Section 5.2.1.  Per “As a suggestion, at least the following parameters of
> the X.509 client certificate SHOULD be exposed … Originating IP address”, how
> exactly should this IP address be exposed in the certificate, or is this
> intended to be the IP address of the peer which presented the certificate?

I believe this is the IP address of the peer which presented the certificate.


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


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


> ** Section 5.2.4.  Are there any MTI parameters for the token binding to
> specify?

After reviewing RFC 8473, it appears that more changes to the RPC protocol would
be necessary to support Token Binding. Thus perhaps support for token binding in
this context should be deferred to a separate document. Can anyone with more
domain expertise comment?


--
Chuck Lever