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

Rick Macklem <rmacklem@uoguelph.ca> Wed, 22 January 2020 22:51 UTC

Return-Path: <rmacklem@uoguelph.ca>
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 94003120089 for <nfsv4@ietfa.amsl.com>; Wed, 22 Jan 2020 14:51:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 8Bw9JGL35UTF for <nfsv4@ietfa.amsl.com>; Wed, 22 Jan 2020 14:51:06 -0800 (PST)
Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670085.outbound.protection.outlook.com [40.107.67.85]) (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 C02BA12001A for <nfsv4@ietf.org>; Wed, 22 Jan 2020 14:51:06 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eQHCpg7of/kTZtLe3xro44Y4ncqW1tNRhl6u/qSVPuLXcFf19a1i/iwjNWYa5+od3ir7MokrHmzxGFu9hZQJMj4f241i5oWzX+qanoqQpp1dTUet/XrEQQHfVXkQ1vxBysvG1FzHIhBywsgdYSrCMiCIEYzzWLW7U1sqlMOSCdslCzKH4GhlsB8KiTx57uHZOHKFTrhuvaRxveLFl/LCMNxf6n/ZH8BJjWp97J6GMlJY5osGZi5LZqbU0Kh4G8YwgY39ih3NxdBfgfNzzhBgDRAnnYHQTeH5wnAjJPeuftWJ68IlY+d17jsr/XbelTfPKAqlbMgAzqow5nA6zTstDA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+RRpJyh3PH0LJac6tkfIUUqjyv1leb1LR+r4yhReEDw=; b=SshXMWHyvmUV+8aQwqGYxASvRK6ezchUlK4E3/1NcULjtphzVdR6h31VCLMEUVdRlKEe4U7t+z9toln4/mUhlvVT4HOwAamrXVt+tXSajiAByXL61qVoI5qyk9uu3oQTvooQ2iUqez8+r1T42Ni9fH0Ugzln7uJQ1AII2uVga1+9duDK60ID9FB6NzX3dCko4YEvyIzLjIS66C/0yka3n0/kFm+vcmYV40rfSyyRfKDV+1jxRARvZ5YUFL7Odiwl9m4sIdvuEnieXXRlz/ImlkUs/dMqjASaal8is8R/TYQy11Bfl88/qM+UUfHwEm5AptnO3haNJDwWyqu7h4+nXQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none
Received: from YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM (52.132.69.153) by YQBPR0101MB2290.CANPRD01.PROD.OUTLOOK.COM (52.132.73.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.23; Wed, 22 Jan 2020 22:51:04 +0000
Received: from YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM ([fe80::6588:45c3:4892:f98]) by YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM ([fe80::6588:45c3:4892:f98%7]) with mapi id 15.20.2665.017; Wed, 22 Jan 2020 22:51:04 +0000
From: Rick Macklem <rmacklem@uoguelph.ca>
To: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>
CC: Chuck Lever <chuck.lever@oracle.com>, NFSv4 <nfsv4@ietf.org>
Thread-Topic: [nfsv4] questions w.r.t RPC-over-TLS draft
Thread-Index: AQHVzye+eTXe64dubES650eWV4dxj6fzqLCAgAB8+P+AASJ9AIAAb0421fi4z6yqCNgrWA==
Date: Wed, 22 Jan 2020 22:51:04 +0000
Message-ID: <YQBPR0101MB14278E78602567233ADE90D1DD0C0@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM>
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>
In-Reply-To: <632009682.1567555.1579693972041.JavaMail.zimbra@desy.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7ffaf189-fe45-4620-ffc1-08d79f8d8fbe
x-ms-traffictypediagnostic: YQBPR0101MB2290:
x-microsoft-antispam-prvs: <YQBPR0101MB2290C118CDB8B6AF1D495AF2DD0C0@YQBPR0101MB2290.CANPRD01.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 029097202E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(346002)(376002)(39860400002)(396003)(189003)(199004)(5660300002)(76116006)(54906003)(55016002)(6916009)(966005)(9686003)(8676002)(66476007)(66946007)(6506007)(7696005)(786003)(316002)(66446008)(64756008)(2906002)(91956017)(66556008)(8936002)(26005)(33656002)(52536014)(86362001)(186003)(4326008)(81156014)(81166006)(71200400001)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:YQBPR0101MB2290; H:YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: s5p84+jDFJnHSgKNKi7A6oKwv8kK1JZ8i4B8Ws81uWzfFZkMoKxqP1d+InQMuvpMrnYltaU/IcYIGBaUJr+uqIFm86YKOUMXRws8/BQNKH1lCGWosliGeBvfAUyRrQ20AFr1txeQcU9A6aqXJwRK0ZISQHxHCDorFX9+Y8W08twEZKLQtajPEK6Om3jR8IBuWBfC/N6TxcS+iulkKSsrysknFAMzNlovx8yja+7/WxTig3gwymJtkPGikjG2AIhWk0UYwqpM6B+1WvXBCwGkZuawL9heHys15xy2z2fXmQiVgRNY6HHS42SmBa/cpfveeXFQfSlqbRhD/AeeDPV/EXx71iAb74KtmzpCchXCORD0JxIPYB2EdXKfBhAlnY3w2XVUCG+naxdkvgpq+VbvuGAkNWda/xDrvWfIJMCmagyTxWcQmGBT9TuEQWl94nO4edpjJqXvBC4n70LbPOdEklvNX0U94PYQiNF0WRBn29o=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: uoguelph.ca
X-MS-Exchange-CrossTenant-Network-Message-Id: 7ffaf189-fe45-4620-ffc1-08d79f8d8fbe
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2020 22:51:04.5839 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hRIgMoVjVkn4yZamMu6i5cQiNSKj0696DWdTTtbUxeBEnL+t3P6f6iXT+mIJsKGRB8npt1yem9/VHacMBdpdEg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB2290
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/mGs_tuHJtpKNQm45Fq5Cd8d8oO0>
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: Wed, 22 Jan 2020 22:51:09 -0000

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
if unencrypted (I think it calls them cleartext) TLS records can be mixed into encrypted ones.

rick

Tigran.

>
>>> (FreeBSD currently uses NULL RPCs with AUTH_NULL as a "ping" to figure out if
>>> the server is up, however it uses a separate TCP connection to do this, so it
>>> shouldn't
>>> matter if it allowed on the same connection.)
>>
>>The NULL with AUTH_TLS should be able to act as both announcing support
>>for RPC-over-TLS and a ping for a particular RPC Program.
> Agreed. However it comes back to whether or not is to me immediately followed by
> the first TLS handshake record.
> Yes -->can only be done once, just before the TLS handshake and, as such, other
>            NULL RPCs with AUTH_NULL before it might be useful.
> No-->means something else needs to be defined so that the server knows when to
>          switch from "receiving Sun RPC messages" to "receiving TLS handshake records".
> I think "yes" is appropriate and what Tigan has already assumed was the case.
>
> As already noted, I think the above wording (which does allow other NULL RPCs)
> is fine.
>
>>>>> I am also confused about what "sends a STARTTLS" actually means?
>>>>> (I'll admit I know nothing about TLS and can only find STARTTLS mentioned w.r.t.
>>>>> an SMTP email command.)
>>>>>
>>>>> Does this mean that the 8 bytes STARTTLS goes on the wire immediately after
>>>>> a NULL RPC with AUTH_TLS or does it mean the 8 bytes STARTTLS goes in a
>>>>> TCP RPC message (an 8byte message as indicated by the RPC over TCP record
>>>>> mark, which would normally be too small) or does "sends a STARTTLS" just saying
>>>>> that the TLS handshake should come immediately after the NULL RPC with AUTH_TLS?
>>>>
>>>>
>>>> "sends a STARTTLS" means "initiates a TLS session."
> Yes, but as noted above, something must go on the wire to indicate this.
> I think the NULL RPC with AUTH_TLS is fine for doing this, but if not, something
> else
> needs to be defined to do so.
>
>>>> That clarifies it. It might be even clearer if it said "initiates a TLS
>>>> handshake"?
>>> Alternately, defining the NULL RPC with authentication flavor AUTH_TLS as a
>>> STARTTLS
>>> command would do so as well.
>>>
>>> One slight problem here is that the above would seem to be TCP specific, since
>>> it assumes
>>> ordering, but is not in the TCP section. I know nothing about the UDP case and
>>> have no >>intention of implementing it, but it does seem that is TCP specific?
>>> (Would the UDP variant >>be >non-NULL RPC traffic from the same client
>>> IP address or do you just not worry about this for UDP?)
>>
>>Agreed, that language should probably be moved to Section 5.1.1.
> Yep.
>
> rick
>
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4