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

Chuck Lever <chuck.lever@oracle.com> Fri, 04 September 2020 15:22 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 935E23A0CEE; Fri, 4 Sep 2020 08:22:08 -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 lR4DO-KfB7Db; Fri, 4 Sep 2020 08:22:07 -0700 (PDT)
Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 615443A0CEA; Fri, 4 Sep 2020 08:22:07 -0700 (PDT)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 084FKktR021708; Fri, 4 Sep 2020 15:22:06 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=fl27q+Ka3qQNNtPNqdF6UGyyJtaM6sJifKo4cfZrqHs=; b=sZceUQioXWeKXtVhUmMWqffM/j/JHB/7rnM04f/rE4wVAGyM3EhSVkHeGkyNkezKxVSt gcLthscb+thhbB4EPI6gwBGH7tvrbKUpt3Tz84/rywECnvzi+QzL4LJpgnBJOSD8jx/u tYahFbi9rz+DSw+U+h83GhEl4H6RTCE0ktg+pZ95KgK0PQKwMmtrcdT5WsbBrF2Z2zl0 IbHvnzVNjHqSdluYhLfG97OnCH6zmc36gTJ/3BKh/R7OAo3s4kmcFgqgEag2SbwIzkhw Vf+lpdOioOjiHv+gbB3JNef8pNLBix3HSojbm/yZrA6CD4DlR0VmRyUkooTwc/zA6yS7 cg==
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 337eymq0q4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 04 Sep 2020 15:22:06 +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 084FJq0I119643; Fri, 4 Sep 2020 15:22:05 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 33b7v2s49b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 04 Sep 2020 15:22:05 +0000
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 084FM3XM000745; Fri, 4 Sep 2020 15:22:03 GMT
Received: from anon-dhcp-152.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 Sep 2020 08:22:03 -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: <4E308C6F-6909-43F3-8CE3-600E3D079721@oracle.com>
Date: Fri, 4 Sep 2020 11:22:02 -0400
Cc: draft-ietf-nfsv4-rpc-tls@ietf.org, The IESG <iesg@ietf.org>, nfsv4@ietf.org, nfsv4-chairs <nfsv4-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BD540C71-6235-4778-95E0-602F7D1C12CC@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> <4E308C6F-6909-43F3-8CE3-600E3D079721@oracle.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=9734 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 spamscore=0 mlxlogscore=999 phishscore=0 bulkscore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009040134
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9734 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 priorityscore=1501 phishscore=0 mlxlogscore=999 mlxscore=0 lowpriorityscore=0 clxscore=1015 spamscore=0 bulkscore=0 impostorscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009040134
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/0Vrsn5xMtYMq-Jl-TuIf0o1zPUA>
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, 04 Sep 2020 15:22:09 -0000


> On Sep 1, 2020, at 1:10 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
> 
> 
> 
>> 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."

This replacement for the Pre-Shared Key section might address
your comments here and in the COMMENT ballot position:

NEW:

5.2.2.  Pre-Shared Keys

   This mechanism is OPTIONAL to implement.  In this mode, the RPC peer
   can be uniquely identified by keying material that has been shared
   out-of-band (see Section 2.2 of [RFC8446]).  At least the following
   parameter of the TLS connection SHOULD be exposed at the RPC layer:

   *  PSK Identifier


--
Chuck Lever