Re: [nfsv4] Éric Vyncke's No Objection on draft-ietf-nfsv4-rpc-tls-08: (with COMMENT)

Chuck Lever <chuck.lever@oracle.com> Fri, 03 July 2020 15:33 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 AF7023A0942; Fri, 3 Jul 2020 08:33:01 -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 SdfS6t8bj_vy; Fri, 3 Jul 2020 08:33:00 -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 45F9F3A093A; Fri, 3 Jul 2020 08:33:00 -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 063FHVrt156345; Fri, 3 Jul 2020 15:32:58 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=SclUjz0wsNAusX6sLz7xzcwkRSiC+kV51piMwuYOct4=; b=XavbZ5P8MA38PhL0ypX3sozhhtiDx56rctT8wFxN9DvPWAFH7eehxwwTvsMSTTpyCKAp JoXLWyIhnZWicrZe6MzFvL1V4ryA95HOgUIv3zDAhANlss9f38FoyoWTE0bj+veDJCT3 GYO5A7OSi63TQhHOrf3hWXg0+bFJUnXT6pVx9rE+wjNGI93KJ4si/DoFcKBG4s0wgka2 bi5tHW5bnhxi4PdTBFf56+aTSDnhNFzx+vNUfglO1fa7a8XRU31ZyTIqOIOFuuO6ydVs sUM+xViDes5qTa0FqKAMWJfkFO8kzHuHd9iCYctW8Z6Ru1/nlASVWPxdX+NV64yVO8nl pw==
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 31ywrc4fgx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 03 Jul 2020 15:32:58 +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 063FIroc174520; Fri, 3 Jul 2020 15:32:57 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3020.oracle.com with ESMTP id 31xg1cpmes-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 Jul 2020 15:32:57 +0000
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 063FWv8i017794; Fri, 3 Jul 2020 15:32:57 GMT
Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 03 Jul 2020 15:32:56 +0000
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: <159376981406.23976.3823367265505746988@ietfa.amsl.com>
Date: Fri, 3 Jul 2020 11:32:55 -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: <779F15A7-6217-4865-9155-49FD305340FF@oracle.com>
References: <159376981406.23976.3823367265505746988@ietfa.amsl.com>
To: =?utf-8?Q?=C3=89ric_Vyncke?= <evyncke@cisco.com>
X-Mailer: Apple Mail (2.3445.104.14)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9671 signatures=668680
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 mlxlogscore=999 suspectscore=0 bulkscore=0 mlxscore=0 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2007030105
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9671 signatures=668680
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 mlxlogscore=999 clxscore=1011 cotscore=-2147483648 priorityscore=1501 lowpriorityscore=0 malwarescore=0 mlxscore=0 adultscore=0 suspectscore=0 impostorscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2007030105
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/MYbSUvCtPlACku2KzgnabJoijVg>
Subject: Re: [nfsv4] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-nfsv4-rpc-tls-08=3A_=28with_COMMENT=29?=
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: Fri, 03 Jul 2020 15:33:02 -0000

Hi Éric-

Thanks for your review and comments.


> On Jul 3, 2020, at 5:50 AM, Éric Vyncke via Datatracker <noreply@ietf.org> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-nfsv4-rpc-tls-08: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for the work put into this document.
> 
> Please find below a couple on non-blocking COMMENTs.
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> 
> -- Abstract --
> As section 4.2 specifies the use of at least server-side authenticated TLS
> session, I wonder why the abstract contains 'opportunistic encryption'.

Clients that support TLS can be deployed in environments with servers that
do not. The client has to detect a server's TLS support before TLS can be
used.

Opportunism here means that the RPC protocol still works if the server does
not support TLS. The choice of whether to proceed with operation is
determined by security policy.


> -- Section 4.1 --
> 
> "(D)TLS-protected RPC" while DTLS was never expanded before... or did I miss it
> ?

That's recently-added text. Sorry for the oversight. To address it, I
propose changing the Introduction as follows:

OLD:

   The alternative described in the current document is to employ a
   transport layer security mechanism that can protect the
   confidentiality of each RPC connection transparently to RPC and
   upper-layer protocols.  The Transport Layer Security protocol
   [RFC8446] (TLS) is a well-established Internet building block that
   protects many standard Internet protocols such as the Hypertext
   Transport Protocol (HTTP) [RFC2818].

NEW:

   The alternative described in the current document is to employ a
   transport layer security mechanism that can protect the
   confidentiality of each RPC connection transparently to RPC and
   upper-layer protocols.  The Transport Layer Security [RFC8446] (TLS)
   and Datagram Transport Layer Security [I-D.ietf-tls-dtls13] (DTLS)
   protocols are a well-established Internet building blocks that
   protect many standard Internet protocols such as the Hypertext
   Transport Protocol (HTTP) [RFC2818].


> -- Section 6.3 --
> Just puzzled by "No comments from implementors" about Hammerspace while one
> author is affiliated with Hammerspace.

Hammerspace is covered in Section 6.2.

Trond invented the probing mechanism specified in Section 4.1, but as far
as I know has not proffered any direct feedback resulting from
implementation experience. If that's incorrect, I invite him to correct me.

However, I see that Section 6.3 should be updated:

When this section was written many months ago, we optimistically assumed
the Linux prototype would be further along by now.

A Linux in-kernel prototype is underway, but implementation delays have
resulted from the challenges of handling a TLS handshake in a kernel
environment. Those issues stem from the architecture of TLS and the
kernel, not from the design of the RPC-over-TLS protocol.


--
Chuck Lever