Re: [secdir] Secdir review of draft-ietf-nfsv4-rfc5666bis-10

Tom Talpey <ttalpey@microsoft.com> Fri, 24 February 2017 21:28 UTC

Return-Path: <ttalpey@microsoft.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CEC129515; Fri, 24 Feb 2017 13:28:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.889
X-Spam-Level:
X-Spam-Status: No, score=-3.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 WIBjXt9xFpTr; Fri, 24 Feb 2017 13:28:43 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0092.outbound.protection.outlook.com [104.47.36.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D93129513; Fri, 24 Feb 2017 13:28:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mqQCLpvBmCq/yPUSDGBoSohg+gQeBTAKak8ey82NqsI=; b=V/JucEAEPy2uKNU20WqfD4ptOA8kjdfdl7BLYCDlMQGSnPYScxXIQh7dPZK4cfxRtf+pNZ/rt+2MOjEPtEtXYzKndFd5Fy/hm5GCrOsWbKTGb5IDTN624R28s7TJ8EsqBr3MNWLIfbHpWvDwOJuDngDk5v/Kx91lH2+H2xjXd1A=
Received: from BN6PR03MB2449.namprd03.prod.outlook.com (10.168.223.15) by BN6PR03MB2452.namprd03.prod.outlook.com (10.168.223.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Fri, 24 Feb 2017 21:28:39 +0000
Received: from BN6PR03MB2449.namprd03.prod.outlook.com ([10.168.223.15]) by BN6PR03MB2449.namprd03.prod.outlook.com ([10.168.223.15]) with mapi id 15.01.0933.016; Fri, 24 Feb 2017 21:28:39 +0000
From: Tom Talpey <ttalpey@microsoft.com>
To: Chuck Lever <chuck.lever@oracle.com>, Vincent Roca <vincent.roca@inria.fr>
Thread-Topic: Secdir review of draft-ietf-nfsv4-rfc5666bis-10
Thread-Index: AQHSjp3mwI+h0fJJDU2WX5plDQmD9qF4gpGAgAAncYA=
Date: Fri, 24 Feb 2017 21:28:37 +0000
Message-ID: <BN6PR03MB2449FFB069D85C913D04EA26A0520@BN6PR03MB2449.namprd03.prod.outlook.com>
References: <B2BB177E-540B-4888-BD58-AB2BAF7AD6E6@inria.fr> <EB6E22D3-B8CF-4440-9B73-244EFCE98E13@oracle.com>
In-Reply-To: <EB6E22D3-B8CF-4440-9B73-244EFCE98E13@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: oracle.com; dkim=none (message not signed) header.d=none;oracle.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [24.218.182.144]
x-ms-office365-filtering-correlation-id: 6d540d58-536a-448b-2f08-08d45cfc1978
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2452;
x-microsoft-exchange-diagnostics: 1; BN6PR03MB2452; 7:LqoLODWs5fQYRschohh2T1cbeXHPjYuG7hbzylsEdpDQH8xfiWEHM3Zx0b/iP97GJKVE0lmDSq05lNKyYigCaD0NZe4kP4I7rEj7AbQHXLs0QjMYcfuSsdLCH63opB2oWqXgz0ZWMAtPRbs8IlcLKaW+ALQKZ+GdcOHv3LBDT6oOxc7yS4T4jYexkFACkFiAkZczrccjmLcxRLW3PPU04SYPrYekKbWcv/fUS3FWTg919AMgdCjn4q+GhAS51m4/CvxAU0pFnuHXQIBUimbuiKdEGd9+YsVpDFiJ1uzSjw99xzaeaE49y4cRaaEq6ZuOjYSRUzv+r/y/ckKBqOggRqS1twzUOz5fjU9TYnyz5NY=
x-microsoft-antispam-prvs: <BN6PR03MB2452472A69E885DC7229085BA0520@BN6PR03MB2452.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705)(146099531331640);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148)(6042181); SRVR:BN6PR03MB2452; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2452;
x-forefront-prvs: 0228DDDDD7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(13464003)(38730400002)(10290500002)(5005710100001)(53546006)(77096006)(8990500004)(8676002)(2950100002)(6506006)(74316002)(6436002)(54906002)(122556002)(9686003)(10090500001)(4326007)(33656002)(55016002)(86612001)(92566002)(3280700002)(25786008)(99286003)(6116002)(7696004)(3846002)(102836003)(53936002)(3660700001)(76176999)(230783001)(5660300001)(189998001)(54356999)(7736002)(305945005)(106116001)(6246003)(81166006)(229853002)(2906002)(66066001)(8936002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2452; H:BN6PR03MB2449.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2017 21:28:37.7118 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2452
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/1RLPb6OghEvtunopwBR0NEZsgRY>
Cc: IESG <iesg@ietf.org>, "draft-ietf-nfsv4-rfc5666bis.all@ietf.org" <draft-ietf-nfsv4-rfc5666bis.all@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-nfsv4-rfc5666bis-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Feb 2017 21:28:44 -0000

[eliding some lines for brevity]

> -----Original Message-----
> From: Chuck Lever [mailto:chuck.lever@oracle.com]
> Sent: Friday, February 24, 2017 1:58 PM
> To: Vincent Roca <vincent.roca@inria.fr>
> Cc: IESG <iesg@ietf.org>; secdir@ietf.org; draft-ietf-nfsv4-
> rfc5666bis.all@ietf.org
> Subject: Re: Secdir review of draft-ietf-nfsv4-rfc5666bis-10
> 
> 
> > On Feb 24, 2017, at 4:59 AM, Vincent Roca <vincent.roca@inria.fr> wrote:
> >
> > Hello,
> >
> > I have reviewed this document as part of the security directorate’s
> > ongoing effort to review all IETF documents being processed by the
> > IESG. These comments were written primarily for the benefit of the
> > security area directors.  Document editors and WG chairs should treat
> > these comments just like any other last call comments.
>... 
> Hi Vincent-
> 
> Thanks for your review.
> 
> I believe your questions are mostly rhetorical, so I will respond to those by
> saying the authors, shepherd, and AD will attempt to address these issues with
> the next document revision.
> 
> There is one remaining comment that IMO needs group discussion, below.
> 
> 
> > ** Privacy or confidentiality? Throughout section 8, authors mention
> "Privacy" inappropriately IMHO.
> > Privacy refers to PII (Personally identifiable information) which is different.
> For instance in section 8.2, when saying:
> >         "However, integrity and privacy services require significant movement of
> data on each endpoint host."
> > the authors really mean confidentiality (this is mentioned just above,
> > when saying that RPCSEC_GSS implements "per-message confidentiality").
> There are several mistakes of that kind throughout section 8.

Regarding "privacy", this term is used in the document because all the NFS RFC's use it in this way. While I agree with you that there is room for confusion, it would be even wider if we switched terminology here.

>...
> > ** Last sentence:
> > 	"To address attacks on RDMA protocols themselves, RDMA transport
> implementations should conform
> > 	to [RFC5042]."
> > "should" or "SHOULD"?
> 
> Lower case "should" is used here because this statement is IMO not an
> interoperability directive. I hope I correctly understand the intent of your
> question.
> 
> If there is a security requirement that this be changed to the RFC 2119 term,
> please let us know and that can be done.

I don't think SHOULD is appropriate here. This statement refers to other protocols, in particular lower layers then this document, and in the case of the relevant IETF RDMA protocols, RFC5042 is already a required conformance. Therefore the statement is informational here, and not an RFC2119 usage.

Tom.