Re: [mile] Working group last call for ROLIE

"Schmidt, Charles M." <cmschmidt@mitre.org> Mon, 24 April 2017 21:22 UTC

Return-Path: <cmschmidt@mitre.org>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D22113193F for <mile@ietfa.amsl.com>; Mon, 24 Apr 2017 14:22:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.onmicrosoft.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 SRRLURfto8OV for <mile@ietfa.amsl.com>; Mon, 24 Apr 2017 14:22:18 -0700 (PDT)
Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id DAEEB1294A6 for <mile@ietf.org>; Mon, 24 Apr 2017 14:22:17 -0700 (PDT)
Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 188CF6FC01D; Mon, 24 Apr 2017 17:22:28 -0400 (EDT)
Received: from imshyb02.MITRE.ORG (imshyb02.mitre.org [129.83.29.3]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 0B58A6FC021; Mon, 24 Apr 2017 17:22:28 -0400 (EDT)
Received: from imshyb01.MITRE.ORG (129.83.29.2) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Apr 2017 17:22:16 -0400
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Mon, 24 Apr 2017 17:22:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.onmicrosoft.com; s=selector1-mitre-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Lfn6CqwpGD6ZztvAbw9jnl/6vTJopIIgEiJlwjEVfU8=; b=HvLHzG6d8Dx6U6XWFQEIA26ncmLac1OR5EMFfXw2Y0dsNeS952ZvuR0UtVtu4rrGhjXfwdv5Gk3sJJxtB/czJ9P3qKwErPs91+yUReUqCZDfL2IIJjiBZShaDVnTFyz8cjUlMe84IDs8pPGrWGonpLEPGaH9SH59Bc0Y+Rmb4fg=
Received: from CY1PR09MB0889.namprd09.prod.outlook.com (10.163.43.27) by CY1PR09MB0892.namprd09.prod.outlook.com (10.163.43.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Mon, 24 Apr 2017 21:22:09 +0000
Received: from CY1PR09MB0889.namprd09.prod.outlook.com ([10.163.43.27]) by CY1PR09MB0889.namprd09.prod.outlook.com ([10.163.43.27]) with mapi id 15.01.1047.019; Mon, 24 Apr 2017 21:22:09 +0000
From: "Schmidt, Charles M." <cmschmidt@mitre.org>
To: "Banghart, Stephen A. (Fed)" <stephen.banghart@nist.gov>
CC: "mile@ietf.org" <mile@ietf.org>
Thread-Topic: Working group last call for ROLIE
Thread-Index: AQHSqBrX3wNPiZjeRUuG2OC1scqiSqHVDH4wgAAQRaCAABFqEA==
Date: Mon, 24 Apr 2017 21:22:09 +0000
Message-ID: <CY1PR09MB08891A6E382E51C82AC92E25AB1F0@CY1PR09MB0889.namprd09.prod.outlook.com>
References: <CC7AB8C2-66EC-4B75-9CFA-F9A1D7A9C46D@cisco.com> <CY1PR09MB0889F3426B92B044A59ED793AB1F0@CY1PR09MB0889.namprd09.prod.outlook.com> <DM5PR09MB1307E859ECDE8D64EC66A677F01F0@DM5PR09MB1307.namprd09.prod.outlook.com>
In-Reply-To: <DM5PR09MB1307E859ECDE8D64EC66A677F01F0@DM5PR09MB1307.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: nist.gov; dkim=none (message not signed) header.d=none;nist.gov; dmarc=none action=none header.from=mitre.org;
x-originating-ip: [192.160.51.89]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0892; 7:ur3fFxoKmATiVdgNJrcxAUif1GzBCOoOKZOa5ma8GK8/XL7/GGEx7bt954o6yqi6f8v4VSPvfXDMjJl6XqGYJjYiw9y4lnvYxFAMQdxZednvtHEVZO3PTMfw0eTkD3/Lz/RB2znVTreRJ/OXiVuRj+l0OClAQJek62fujt+ko3yDa6LC5bjYbpfJLvKYLk6iCcS9ooavdU4ec3CEKlGN49vNRjiM79+iXFy3qieByAFprLfhXHf3dyJoVayecF/1/lPTeLFzhOcrUNJTASzVXPG/b/liMtaOBZNd+OKf17ntrXSvRCuTlXCyiPTCvMSk4iXIr3perny06zVXRzhLrw==
x-ms-office365-filtering-correlation-id: 06d7f84c-66cb-4440-6cbf-08d48b57f794
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY1PR09MB0892;
x-microsoft-antispam-prvs: <CY1PR09MB08923CECB51F6E44A07710E9AB1F0@CY1PR09MB0892.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:CY1PR09MB0892; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0892;
x-forefront-prvs: 0287BBA78D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39860400002)(39850400002)(39400400002)(39410400002)(51914003)(8936002)(86362001)(54356999)(74316002)(8676002)(81166006)(76176999)(2900100001)(33656002)(77096006)(66066001)(4326008)(6506006)(7736002)(3660700001)(305945005)(50986999)(25786009)(3280700002)(8656002)(122556002)(2906002)(6436002)(6916009)(2950100002)(7696004)(53936002)(6116002)(5660300001)(6246003)(189998001)(229853002)(38730400002)(99286003)(55016002)(102836003)(110136004)(3846002)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR09MB0892; H:CY1PR09MB0889.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2017 21:22:09.7216 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0892
X-OriginatorOrg: mitre.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/llnodwoxzTVjs5kFcdeF60ffGxI>
Subject: Re: [mile] Working group last call for ROLIE
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Apr 2017 21:22:19 -0000

Hi Stephen,

Thanks for the response. I have one follow-up to your follow-up:

> > Section 5.1.1
> > - Bullet 1: "I'm confused by this recommendation. If a Workspace contained
> a
> > mix of public and private data, would it not be possible to hide the private
> > data in that case? What about the case where you have multiple levels of
> > access for private data - should each level have its own workspace? I'm
> > assuming ROLIE supports highly granular access controls, so the "separate
> > workspace for public and private data so that private data can be hidden"
> > seems like it fails to encompass the versatility that people will want to
> have."
> 
> We've provided this just as a recommendation because there are a couple
> way to handle the situation. You certainly could hide each collection
> independently, you could even hide entries individually. By moving the
> authentication check to the highest level available you avoid potential
> performance issues and reduce the attack surface.

This makes sense. I think my confusion was that it sounded to me like you were saying that people SHOULD follow this design choice because this was *the* way to control visibility of the content. Based on your response, it sounds like you are citing this as one way to effectively manage visibility, but it is not the only way. I wonder if it might be clearer if instead of saying "It is RECOMMENDED that public and private Collections be segregated into different Workspaces" the document could say, "One way of efficiently controlling visibility of continent is to have public and private Collections be segregated into different Workspaces." Maybe you could further drive home that ROLIE is not tied to this model by appending "ROLIE supports other ways of organizing Collections and because ROLIE supports fine-grained access control, owners can control visibility of content regardless of how Collections are organized." 

Does this make sense?

Thanks,
Charles