Re: [nfsv4] questions w.r.t RPC-over-TLS draft

Benjamin Kaduk <kaduk@mit.edu> Fri, 24 January 2020 01:54 UTC

Return-Path: <kaduk@mit.edu>
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 0883A1200CD for <nfsv4@ietfa.amsl.com>; Thu, 23 Jan 2020 17:54:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 TrF0J7yWZa1h for <nfsv4@ietfa.amsl.com>; Thu, 23 Jan 2020 17:54:20 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 1A348120019 for <nfsv4@ietf.org>; Thu, 23 Jan 2020 17:54:19 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00O1s6tQ001801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Jan 2020 20:54:09 -0500
Date: Thu, 23 Jan 2020 17:54:06 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Rick Macklem <rmacklem@uoguelph.ca>
Cc: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>, NFSv4 <nfsv4@ietf.org>
Message-ID: <20200124015406.GF90660@kduck.mit.edu>
References: <YQBPR0101MB142761C64D6A842CB99EADC0DD320@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> <0E8060A0-B8DA-462E-915E-9121824A7A3D@oracle.com> <YQBPR0101MB1427364BAFED4564FD0FD67BDD320@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> <0FF8087F-E4C6-4ABB-8F92-6224724939FC@oracle.com> <YQBPR0101MB1427D05C02E7B056BFB59244DD0D0@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> <632009682.1567555.1579693972041.JavaMail.zimbra@desy.de> <YQBPR0101MB14278E78602567233ADE90D1DD0C0@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <YQBPR0101MB14278E78602567233ADE90D1DD0C0@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/l7de7rNRkbxBzXdtywlBv0JYiqw>
Subject: Re: [nfsv4] questions w.r.t RPC-over-TLS draft
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, 24 Jan 2020 01:54:22 -0000

On Wed, Jan 22, 2020 at 10:51:04PM +0000, Rick Macklem wrote:
> Mkrtchyan, Tigran wrote:
> [stuff snipped]
> >> Chuck Lever wrote:
> >>>It seems to me the new text clearly allows an unencrypted NULL RPC at any
> >>>time. I'm not sure that's even feasible, but it's an implementer's choice.
> >>I wrote:
> >> Yea. I'm not sure if this is feasible either (at least for TCP), but NULL RPCs
> >> seem
> >> harmless, so I think the current wording is ok, at least for reliable ordered
> >> transports
> >> like TCP.
> >
> >
> >I am pretty sure, that once TLS session is established, you can't sent any other
> >requests outside of it.
> Yea, the only case I can think of where it might be possible for TCP is after an
> SSL_shutdown is done on the socket. I also haven't looked at the RFC enough to figure out

"SSL_shutdown is done on the socket" translates (roughly) to TLS-speak as
"both endpoints send and receive "close_notify" alerts from the peer", and
in theory the protocol can support this but evidence of real-world
functionality is quite sparse.  (Many implementations do not really do
"close_notify" quite according to the spec, and trying to wait for it from
the peer is pretty dicey.)

> if unencrypted (I think it calls them cleartext) TLS records can be mixed into encrypted ones.

They can't.  (If there was a severe need a way could be found, e.g., with a
new record type, but there would be a lot of pushback on this.)

-Ben