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

Chuck Lever <chuck.lever@oracle.com> Tue, 01 September 2020 17:12 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 E64E73A0B65; Tue, 1 Sep 2020 10:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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] 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 Kao2YBru_2lj; Tue, 1 Sep 2020 10:12:30 -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 A94BA3A0B64; Tue, 1 Sep 2020 10:12:30 -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 081H8qW2039714; Tue, 1 Sep 2020 17:12:30 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=9jT/+gn06PsuM53lu76GNfbMUUFYq6SMecup8g4ftwo=; b=M8A0QngLlpbgXwYKXrgPLIFQZu7/rBMNokMBFfRXaL1N6gWumNfDLVyTEsv5z3FF6xJZ Lh0uE11eFrlDy3/fI9EzZOrsy8FddWulglWQIl5gs4rUw6mRTu5j2Ans1zBWJLQx8uFf 6UkBc/nxB9npG/ZyXfpALKblzxQscIXSxknLsj/K6JxLhrAQ9j6EPwj8s5rd5t6CWrr5 vYHYouCqZlri2vfjZpt9/ybKB/NgfZGdTJ8N9I5/LqKOO3cfOXtb7Kvxa0tVLoyBaQDE dwDqAMgYh4ByS+SWSAXJw43b/DuukbGxDE2sHcGI2hyDqia0Qae2KRNYFfqsOK9uwtJN 9A==
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 337eeqwtax-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 01 Sep 2020 17:12:30 +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 081H1CGu157284; Tue, 1 Sep 2020 17:10:29 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 3380knjvbt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 01 Sep 2020 17:10:29 +0000
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 081HASBD027912; Tue, 1 Sep 2020 17:10:28 GMT
Received: from anon-dhcp-152.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Sep 2020 10:10:28 -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: <20200901160954.GU16914@kduck.mit.edu>
Date: Tue, 1 Sep 2020 13:10:26 -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: <4E308C6F-6909-43F3-8CE3-600E3D079721@oracle.com>
References: <159419140773.2153.2711644434582054796@ietfa.amsl.com> <FBB12872-16B8-427B-89F3-FCE363B4E2F7@oracle.com> <20200831204420.GN16914@kduck.mit.edu> <CC07164D-8B32-4212-8125-38968AC92975@oracle.com> <20200901160954.GU16914@kduck.mit.edu>
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=9731 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 adultscore=0 mlxscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009010142
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9731 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 priorityscore=1501 lowpriorityscore=0 malwarescore=0 adultscore=0 spamscore=0 mlxscore=0 phishscore=0 impostorscore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009010143
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/1gN7NymVCDme1A_NOv3oIGuJPOc>
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, 01 Sep 2020 17:12:33 -0000


> On Sep 1, 2020, at 12:09 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
> 
> On Tue, Sep 01, 2020 at 11:06:18AM -0400, Chuck Lever wrote:
>> 
>> 
>>> On Aug 31, 2020, at 4:44 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>>> 
>>> On Mon, Aug 31, 2020 at 11:06:51AM -0400, Chuck Lever wrote:
>>>> Hi-
>>>> 
>>>> I've now addressed Roman's DISCUSS/COMMENT position. For reference, the
>>>> current Editor's Copy with these changes can be found here:
>>> 
>>> Hmm, not quite -- the RFC 5487 ciphers are not compatible with TLS 1.3,
>>> since TLS 1.3 redefines what a ciphersuite is (which also means that TLS
>>> 1.3 provides native support for PSK handshakes), so you still need to
>>> update Section 5.2.2 of this draft to refer to RFC 8446, removing the 4279
>>> and 5487 references.
>> 
>> Whoops. A recent bad change needs to be reverted there.
>> 
>> NEW:
>> 
>> 5.2.2.  Pre-Shared Keys
>> 
>>   This mechanism is OPTIONAL to implement.  In this mode, the RPC peer
>>   is uniquely identified by keying material that has been shared out-
>>   of-band or by a previous TLS-protected connection (see Section 2.2 of
>>   [RFC8446]).  At least the following parameters of the TLS connection
>>   SHOULD be exposed to the RPC server:
>> 
>>   *  The IP address of the peer that presented the certificate
> 
> In PSK mode, there may not be a certificate (though there can be, in
> various scenarios).

And perhaps the IP address of the peer has changed since the PSK
was originally exchanged.


>>   *  TLS Identifier
> 
> Is this the PSK identifier or some other (TLS Exporter-generated?) value?

Not clear to me that we need to define a TLS Exporter.

I think the only use for the identity information is to authenticate
the peer. We're not trying to use the PSK material for anything else.

So we want something that indicates that "this peer is the same peer
we contacted when the PSK was originally exchanged."


--
Chuck Lever