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

Chuck Lever <chuck.lever@oracle.com> Fri, 11 September 2020 16:50 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 2B6443A144E; Fri, 11 Sep 2020 09:50:39 -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 2Xs2p9BMYjaP; Fri, 11 Sep 2020 09:50:37 -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 BE86C3A0D7E; Fri, 11 Sep 2020 09:50:36 -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 08BGi6YY005985; Fri, 11 Sep 2020 16:50:36 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=rwJo93gY0M0VWhFfyjQT04PkB5qvsBx/3mLoCCgYuEQ=; b=OKZza07jH73jqqTTtUjhrwxfwtGbcGtDspk16I2rNzg2MdU5KtrWjQS+IixpJ5qEA5qy XwuZxXDSL8PoAgND74n4kQDzOtC+fMCPjhd3GFk+5AzLsTz2noj8h3E76ek90YT/g9yr IGwcbBmh5pZFnkTNmACK7vtab51uVjpd+0lTpR6zvNRv/NpM8IXNC4YjBSQtpWjdUe4u O5+qdiptmBoRWKOtvgnKo3lGzHmXD0q4OuS3g4uFw3Wfl71Bo3fqjNEh8Os9tX7ZaP1H NOFxvMki2tNb3C6RT4q0MFCEjfJoW1WFrTRVTS9GY9V7Nm4jQSo7//o7s3j475Q5tGZz Gg==
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 33c3anf8ng-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 11 Sep 2020 16:50:36 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 08BGkUeo100002; Fri, 11 Sep 2020 16:48:35 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3030.oracle.com with ESMTP id 33cmm3pynb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 11 Sep 2020 16:48:35 +0000
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 08BGmY7Q025645; Fri, 11 Sep 2020 16:48:35 GMT
Received: from anon-dhcp-152.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 Sep 2020 09:48:33 -0700
Content-Type: text/plain; charset=us-ascii
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: <159419140773.2153.2711644434582054796@ietfa.amsl.com>
Date: Fri, 11 Sep 2020 12:48:32 -0400
Cc: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-rpc-tls@ietf.org, nfsv4-chairs <nfsv4-chairs@ietf.org>, nfsv4@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <603C4E4C-FE41-4D9C-8ECA-38006353DAAC@oracle.com>
References: <159419140773.2153.2711644434582054796@ietfa.amsl.com>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9741 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 suspectscore=0 spamscore=0 mlxlogscore=999 adultscore=0 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009110136
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9741 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 priorityscore=1501 clxscore=1015 bulkscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=999 suspectscore=0 adultscore=0 mlxscore=0 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009110136
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/AkebTRViSlbJ95aUfDqdL6y9y0o>
Subject: Re: [nfsv4] Benjamin Kaduk'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: Fri, 11 Sep 2020 16:50:39 -0000

Hi Ben-

I'm nearly done with the new text. I need some clarification below.


> On Jul 8, 2020, at 2:56 AM, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-nfsv4-rpc-tls-08: Discuss
> 
> 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:
> ----------------------------------------------------------------------
> 
> I'm surprised that we don't make a normative reference to BCP 195's
> "Recommendations for Secure Use of Transport Layer Security (TLS) and
> Datagram Transport Layer Security (DTLS)" (we have only an informative
> reference from the security considerations).

Is there a specific change you'd like to see?


>   *  Host identity management and user identity management must be
>      enforced in the same security realm.  In certain environments,
>      different authorities might be responsible for provisioning client
>      systems versus provisioning new users.
> 
> I think this is only true from a certain point of view.  They have to be
> related, and (assuming Kerberos since non-Kerberos RPCSEC_GSS isn't really a
> thing) a cross-realm relationship would have to exist in at least one
> direction when client system and user provisioning are managed by separate
> kerberos realms, but the authorities in question do not need to be exactly
> the same.

I'm not clear what needs to change.


>   Encryption By Default:  Transport encryption can be enabled without
>      additional administrative tasks such as identifying client systems
>      to a trust authority, generating additional keying material, or
>      provisioning a secure network tunnel.
> 
> To clarify Roman's comment, it seems worth specifying that this is without
> additional *per-client* keying material.  Generating per-server keying
> material is clearly a minimum requirement.

The text was updated at Roman's request. It now reads:

   Encryption By Default:  Transport encryption can be enabled without
      additional administrative tasks such as identifying client systems
      to a trust authority and providing each with keying material.

Can you confirm this adequately addresses your comment?


> Section 4.1
> 
>   The mechanism described in the current document interoperates fully
>   with RPC implementations that do not support RPC-over-TLS.  Policy
>   settings on the RPC-over-TLS-enabled peer determine whether RPC
> 
> I'd consider joining the two sentences via ", subject to policy settings on
> the RPC-over-TLS-enabled peer that determine".

The text was updated at some point during IESG review. It now reads:

   The mechanism described in the current document interoperates fully
   with RPC implementations that do not support RPC-over-TLS.  When an
   RPC-over-TLS-enabled peer encounters a peer that does not support
   RPC-over-TLS, policy settings on the RPC-over-TLS-enabled peer
   determine whether RPC operation continues without the use of TLS, or
   RPC operation is not permitted.

Can you confirm this is adequate?


>   As soon as a client initializes a UDP socket for use with an RPC
>   server, it uses the mechanism described in Section 4.1 to discover
>   DTLS support for an RPC program on a particular port.  It then
>   negotiates a DTLS session.
> 
> We could probably normalize the wording between the TCP and UDP cases (e.g.,
> TCP says "typically, once a client completes the TCP handshake, it uses the
> mechanism [...]" but this uses descriptive text).  That would also let us
> decide whether or not to mention that (D)TLS usage is contingent on mutual
> support for STARTTLS.

The reason the TCP and UDP text diverge is because TCP is connection
oriented and UDP is not. The current UDP text is the result of some
earlier review comments in this area. Let me know if there is a
specific change you'd like to see here.

Also, I don't understand the last sentence of your comment. Can you
elucidate?


> Section 8.1
> 
> Isn't it codepoint squatting to claim auth flavor 7 before IANA has
> allocated it?  (This is usually a Discuss-level issue, but that part is too
> long already so I left it here.)

I agree it is slightly improper, but the authors were not aware of
IANA's authority over RPC authentication flavors until late in the
document's life cycle. It was a good faith oversight.

I believe we have IANA's permission at this point to use the value 7.

Is there a text change needed here?


--
Chuck Lever