Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls

Chuck Lever <chuck.lever@oracle.com> Fri, 10 April 2020 15:44 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 2957F3A0C83 for <nfsv4@ietfa.amsl.com>; Fri, 10 Apr 2020 08:44:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Level:
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 ylqxuN6Gf85x for <nfsv4@ietfa.amsl.com>; Fri, 10 Apr 2020 08:44:11 -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 CE12B3A0C80 for <nfsv4@ietf.org>; Fri, 10 Apr 2020 08:44:11 -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 03AFi6GZ065804; Fri, 10 Apr 2020 15:44:10 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=efYvntHEnW35Ea4pbmoEDQj2Mqw9u+Nfd090SNNKVu4=; b=WiZRGtXLwA7Nf2omvSWBjPkCg8NaXMDt07fQToLKTlpOVkDf7WrRibJQ/EqdNY4+rdYI Gs1mPEbS+Qjm58Ma0b9f4awi1e+qe86QznagbU1LzIDNkGE6F31/AyM4mO9NEvCo/bP2 tIPFGCfxT77RJ2bEJ2FqgG3bFwH+dZjk7304gzm6pxhth9z5LOCiqdp1DPLqb8wVPRGQ Snj/ByI/3jQsH9m90JbfcCLvDFCst7jGaAvSnUTGSnexyIBKlu9Dt/L6jRV91Z41pyQj X5EOmFZV1bx6ZmAkBVwVkdJv/6F/JMt7RxRKlTNppvroCq+1RgwfTayIwvurFlYxgI7/ TA==
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 3091m16y1s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 10 Apr 2020 15:44:10 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03AFbmge004614; Fri, 10 Apr 2020 15:44:09 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3020.oracle.com with ESMTP id 3091mcyd57-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 10 Apr 2020 15:44:09 +0000
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03AFi9Kj028475; Fri, 10 Apr 2020 15:44:09 GMT
Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Apr 2020 08:44:08 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <QB1PR01MB36492235E6EF60129A0329D7DDDE0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM>
Date: Fri, 10 Apr 2020 11:44:07 -0400
Cc: Trond Myklebust <trondmy@gmail.com>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A35B6E12-67BF-4275-BD7C-97FE991C49F9@oracle.com>
References: <VI1PR0702MB3775838FD12AB8A89392C17B95C90@VI1PR0702MB3775.eurprd07.prod.outlook.com> <FA2D661E-A787-4772-8F9D-A7594AE82F38@oracle.com> <CADaq8jciLWhL_FMmPcsdrVVS=9Gee8SYAsqi36H5v9iuNo7Pgw@mail.gmail.com> <E414F060-532B-4017-AC7E-5869884B2153@oracle.com> <e5796752c6204ffdd78503b1a9c9045cfd761e52.camel@gmail.com> <F9AC44CE-750E-416A-944D-E2382524020E@oracle.com> <19d2513b1093fc71223e361afca90d1a1ad6183a.camel@gmail.com> <35D9AEC0-7961-4C44-9715-26409D6182E4@oracle.com> <QB1PR01MB36492235E6EF60129A0329D7DDDE0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM>
To: Rick Macklem <rmacklem@uoguelph.ca>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9587 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 mlxscore=0 malwarescore=0 spamscore=0 adultscore=0 suspectscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004100130
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9587 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxlogscore=999 mlxscore=0 priorityscore=1501 phishscore=0 suspectscore=0 bulkscore=0 lowpriorityscore=0 impostorscore=0 malwarescore=0 clxscore=1015 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004100130
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/5TAgrLeB90RtCWJG4YSlO06LCUw>
Subject: Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls
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, 10 Apr 2020 15:44:13 -0000


> On Apr 10, 2020, at 11:33 AM, Rick Macklem <rmacklem@uoguelph.ca> wrote:
> 
> Chuck Lever wrote:
> [stuff snipped]
>> Then I started thinking about TCP.
>> 
>> Since we have implementations that use the same connection to transport
>> multiple RPC programs, we have to make a different statement. What should
>> that statement be?
>> 
>> I wondered again about whether it makes sense to permit or encourage
>> multiple TLS sessions on the same connection.
>> 
>> If you wanted to, how would you establish a second TLS session? Because
>> of the "no clear-text RPCs after a TLS session has been established"
>> stipulation, the client would have to perform a bunch of AUTH_TLS probes
>> _before_ sending any ClientHello messages.
>> 
>> (And in any event we probably want rpc-tls to discuss what should happen
>> if there is traffic on the connection between the AUTH_TLS probe and
>> the ClientHello message).
> I think that multiple AUTH_TLS probes before sending ClientHello
> is both difficult to implement and confusing.
> 
> The AUTH_TLS probe serves two purposes well.
> 1 - It establishes whether or not RPC-over-TLS is supported by the server.
> 2 - If supported, it triggers a TLS handshake for the first session.
> 
> If you do want multiple TLS sessions on the same TCP connection (I'll assume TLS
> allows this?), then I think a separate kind of AUTH_TLS Null RPC which is done
> within a TLS session would be a more appropriate way to establish it.
> (This one could have a non-NULL credential to differentiate it from the initial one.)

That sounds about right.


>> But it's likely that multiple TLS sessions makes sense only when there
>> are multiple certificates on the client side. So this is very likely
>> out of scope for rpc-tls. Then do we explicitly forbid the use of
>> multiple TLS sessions per connection for this iteration of RPC-on-TLS?
> Yes, I would agree with this.
> 
> However, I do not see why multiple RPC programs cannot be allowed on
> the same TCP connection using the same TLS session and I don't see that
> the RPC program number used for the AUTH_TLS probe need imply
> "only this program for this session".

Thanks Rick. I am tending to agree with this conclusion.


> Of course, this typically does not happen, since same TCP connection
> implies same server port# and FreeBSD does not do this at this time.
> So, as such, I really do not care whether or not a "only one RPC program
> per TCP connection" restriction exists.

--
Chuck Lever