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

Chuck Lever <chuck.lever@oracle.com> Tue, 15 September 2020 13:25 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 21AD93A0840; Tue, 15 Sep 2020 06:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.794
X-Spam-Level:
X-Spam-Status: No, score=-3.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 IOr0tkCY2cQN; Tue, 15 Sep 2020 06:25:43 -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 80B033A081F; Tue, 15 Sep 2020 06:25:43 -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 08FDMOsg193028; Tue, 15 Sep 2020 13:25:39 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2020-01-29; bh=6A2sghuahyLFzTAWmm15nhBtkya3aYwQFeJQi/VFIVA=; b=PeCIVq+Mpm4L2JPn/Iv0vfJG1GunGCqS+jRRcmEa+qK+g2+Mdj9bazt7xZeSmFVUbVit +y3Y/xeQOaGxLpV5A/CTp3/IQWgDzZIKe+xoKRsgIihOFPPgsxFcj/yWIKzfvM+70nq6 jJffXQTYDZ2S7eyH5Mj39CrMgUPq2ZPAAZi2ymGMVmQeydEYBYTujk/iSbg0KnxZUrro J4OXL15YtlBQaVfw1kGSbkWoG67h9HdLHd6tYLL3loqS2asyiv0vbRLp3X0C1ZddSW3j bwQfGtp90nKwY+LaPvj/4283++taMO1dGn5OVsHdWff/fEVpuQTYc965YEbXekfM+31w BQ==
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 33gnrqw085-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 15 Sep 2020 13:25:39 +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 08FDKj1S130329; Tue, 15 Sep 2020 13:25:39 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 33h88y8jxn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 15 Sep 2020 13:25:39 +0000
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 08FDPb5W013565; Tue, 15 Sep 2020 13:25:37 GMT
Received: from anon-dhcp-152.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 15 Sep 2020 13:25:37 +0000
From: Chuck Lever <chuck.lever@oracle.com>
Message-Id: <E902C2CD-CE09-4C4F-8D94-ABF1E763A6D9@oracle.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8401F13B-62D9-44FF-9E17-E295F90D488D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Tue, 15 Sep 2020 09:25:36 -0400
In-Reply-To: <CADaq8jeSWzBhYU8T7SGc7xXKdqo4k3YBnrH8ADeUi81h27j=yA@mail.gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-rpc-tls@ietf.org, nfsv4-chairs <nfsv4-chairs@ietf.org>, NFSv4 <nfsv4@ietf.org>
To: David Noveck <davenoveck@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>
References: <159419140773.2153.2711644434582054796@ietfa.amsl.com> <603C4E4C-FE41-4D9C-8ECA-38006353DAAC@oracle.com> <CADaq8jeSWzBhYU8T7SGc7xXKdqo4k3YBnrH8ADeUi81h27j=yA@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9744 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 adultscore=0 suspectscore=0 mlxscore=0 bulkscore=0 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009150112
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9744 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 lowpriorityscore=0 malwarescore=0 mlxscore=0 bulkscore=0 suspectscore=0 clxscore=1015 mlxlogscore=999 adultscore=0 priorityscore=1501 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009150112
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/RGB5eeNsgol4ZSZ4UBTR1fTZUzg>
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: Tue, 15 Sep 2020 13:25:45 -0000


> On Sep 14, 2020, at 6:46 PM, David Noveck <davenoveck@gmail.com> wrote:
> 
> 
> 
> On Fri, Sep 11, 2020, 12:50 PM Chuck Lever <chuck.lever@oracle.com <mailto:chuck.lever@oracle.com>> wrote:
> 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 <mailto:noreply@ietf.org>> wrote:
> >  
> 
> > 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 think everyone  accepts that.
> 
> I believe we have IANA's permission at this point to use the value 7.
> 
> It's best to ask them.  If they don't agree, we can ask for an early allocation.

Quoting from IANA review of draft-ietf-nfsv4-rpc-tls in late May:

(BEGIN IANA COMMENTS)

IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-nfsv4-rpc-tls-07. If any part of this review is inaccurate, please let us know. 

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the RPC Authentication Flavor Numbers registry on the Remote Procedure Call (RPC) Authentication Numbers registry page located at:

https://www.iana.org/assignments/rpc-authentication-numbers/ <https://www.iana.org/assignments/rpc-authentication-numbers/>

a single, new registration will be made as follows:

Identifier String: AUTH_TLS
Flavor Name: TLS
Value: [ TBD-at-Registration ]
Description: Signals the use of TLS to protect RPC messages on socket-based transports.
Reference: [ RFC-to-be ]

IANA notes that the authors have requested a value of 7 for this registration.


"Permission to use" was admittedly a little strong. But they are aware of our use of 7 and according to the above registry, it is still unassigned.

> 
> Is there a text change needed here?
> 
> There might be.

--
Chuck Lever