Re: [nfsv4] Genart last call review of draft-ietf-nfsv4-rpc-tls-07

Chuck Lever <> Sun, 24 May 2020 21:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0BE13A0D49; Sun, 24 May 2020 14:58:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.101
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DCWwZReiTznT; Sun, 24 May 2020 14:58:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C0583A0C88; Sun, 24 May 2020 14:58:09 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 04OLw016153320; Sun, 24 May 2020 21:58:00 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=+h+dTri+Yjp6Mh6K7go/OzXLeykkrTw1oVI+T/6t4Po=; b=tIqJuaeR9IxlooHzw8YPLB/JpOc/oUsmlV0+FScqf2/e0tv9o9cwr/BDhlNnYhiYZL3A 6S1o3NIZ7ZCrAY7fz6FmJln5pgINjhWmvTkc2ae02ThK8Gdrtum26oSglkeEKq84ViLa fUOb4xhOQYRbS5sGLRoV/S+KQmfzZdyBzkYzB/75UforcvwNAtYwi4ghO0uqE6El1pkF 1I2GxpF/M/dpmtnnjzBseJlzZYfzvz4xBZCTKDRl2pP+HhdT0bVnOGMph4h6e3MToQ6T 1POqNl6NfQADCU7XIKomv+l7lRJWibXYoazgVNaqzG4xDs3X1yF2/SlJanJiumQKNaCI 9A==
Received: from ( []) by with ESMTP id 316uskkduv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 24 May 2020 21:58:00 +0000
Received: from pps.filterd ( []) by ( with SMTP id 04OLrSqr020095; Sun, 24 May 2020 21:55:55 GMT
Received: from ( []) by with ESMTP id 317dkpcpsv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 24 May 2020 21:55:55 +0000
Received: from ( []) by (8.14.4/8.13.8) with ESMTP id 04OLtrnx006466; Sun, 24 May 2020 21:55:54 GMT
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 24 May 2020 14:55:53 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Chuck Lever <>
In-Reply-To: <>
Date: Sun, 24 May 2020 17:55:52 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Dale Worley <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9631 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 malwarescore=0 bulkscore=0 spamscore=0 suspectscore=0 mlxscore=0 adultscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005240182
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9631 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 lowpriorityscore=0 suspectscore=0 spamscore=0 priorityscore=1501 clxscore=1011 impostorscore=0 bulkscore=0 mlxlogscore=999 phishscore=0 cotscore=-2147483648 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005240183
Archived-At: <>
Subject: Re: [nfsv4] Genart last call review of draft-ietf-nfsv4-rpc-tls-07
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 24 May 2020 21:58:22 -0000

> On May 24, 2020, at 4:50 PM, Dale Worley via Datatracker <> wrote:
> Reviewer: Dale Worley
> Review result: Ready with Nits
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> For more information, please see the FAQ at
> <>.
> Document:  draft-ietf-nfsv4-rpc-tls-07
> Reviewer:  Dale R. Worley
> Review Date:  2020-05-24
> IETF LC End Date:  2020-05-27
> IESG Telechat date:  unknown
> Summary:
> Note that I am not familiar with the operations of TLS, so I have not
> reviewed issues that are specific to security implementations.  I
> assume the SECDIR review has adequately covered those.
> This draft is quite solid and nearly ready for publication, but has
> nits that should be fixed before publication.

Thank you, Dale, for the detailed feedback. I will reply to this
e-mail thread with specific text corrections in the next few days.

I do have a few initial reactions/follow-ups for you that appear
inline below.

> Nits:
> 4.1.  Discovering Server-side TLS Support
> Somewhere in this section you need to specify the semi-obvious:
>   In principle, RPC is transport-agnostic.  In the context of
>   RPC-Over-TLS, the initial request MUST be sent using either TCP or
>   UDP.  If an initial TCP request is successful, a TLS connection is
>   established.  If an initial UDP request is successful, a DTLS
>   association is established.

I can add something like this in Section 4.1, but note that Sections
5.1.1 and 5.1.2 already explain the relationships between TCP/UDP
and TLS/DTLS, respectively.

> 5.1.1.  Protected Operation on TCP
>   The server does not attempt to establish a TLS session
>   on a TCP connection for backchannel operation.
> I think "... does not attempt to establish a separate TLS session ..."
> is clearer.
> I can't find any discussion of "backchannel operation" in RFC 5531.
> Might this need an additional reference?

I agree that a deeper introduction of "backchannel operation" would
be helpful in this section.

There doesn't seem to be any adequate explanation for backchannel
operation in documents prior to RFC 8167, which explains reverse-
direction RPC operation over an RDMA transport.

Perhaps the best I can do here is add a paragraph introducing the
concept, and use the RFC 8167 terminology instead of "backchannel"?
Let me review RFC 8167 and see if I can reference it sensibly in
the context of RPC on TCP.

> 5.2.1.  X.509 Certificates Using PKIX trust
>   o  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 match the
>      address represented by universal address.
> I suspect that "iPAddress" is not capitalized correctly.

This is the capitalization used in RFC 6125, which is cited nearby
this text.

Chuck Lever