From nobody Mon Mar 5 10:41:46 2018 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931231200B9; Mon, 5 Mar 2018 10:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 t_05jPiOeKlg; Mon, 5 Mar 2018 10:41:42 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0127.outbound.protection.outlook.com [104.47.33.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C2B12DA4C; Mon, 5 Mar 2018 10:41: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=NczXR0B4R1UhNS4h3npQFO85qQMgUIIIfJ2qw/YBvPg=; b=Py1Qx2DY3ts4cab8/igLXrlO5LbUkH8dbHGjag9xgDTlJEdydOAGVCbW/A0pdXWxnU09GunO9u4l9QZTdxZsFJnu2Y2uKEU6a3CUGj9VBRZIDYQOGv1nUUq3Yd9/Y4HY2Cq/Soy0qJHtqDIzGjfA52V8rk0DFopzq1fJFZfAzdM= Received: from CY4PR21MB0856.namprd21.prod.outlook.com (10.173.192.145) by CY4PR21MB0741.namprd21.prod.outlook.com (10.173.189.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.588.3; Mon, 5 Mar 2018 18:41:39 +0000 Received: from CY4PR21MB0856.namprd21.prod.outlook.com ([fe80::31df:7f8f:4b48:c145]) by CY4PR21MB0856.namprd21.prod.outlook.com ([fe80::31df:7f8f:4b48:c145%9]) with mapi id 15.20.0588.001; Mon, 5 Mar 2018 18:41:39 +0000 From: Dave Thaler To: Mingliang Pei CC: Kathleen Moriarty , "teep-chairs@ietf.org" , teep Thread-Topic: [EXT] [Teep] Milestones Thread-Index: AQHTpcTqajbVnq1mqUe7VvR7SjwtBqOkSS0AgB3NR2A= Date: Mon, 5 Mar 2018 18:41:39 +0000 Message-ID: References: <3CB3ECC3-1D5B-48FF-8699-FDD85F8EB5ED@symantec.com> In-Reply-To: <3CB3ECC3-1D5B-48FF-8699-FDD85F8EB5ED@symantec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-03-05T18:38:05.7333252Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:b::33d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0741; 7:+UmNd1q0H2mqyv+GQiVkKduQ9ybkkEDrAzeC3YLvgG0haoZbOVlX/g0SgPrCYBlGRnaHbT3qaw1wgxDXwmAzGwrU/vbktnLpqhJNs68/FVA2nYZMdlVLUmiO0JvNvLPXwO46gwHiEPhiI+nCN5KVRBwjhYI1RFaRWqOA/Tx0937+62ZATiDkssjS7hL8jYF0aCz/SXOwIIwQxV12P/oAHYkmBrfTNrv8LnsDVt7WyRSNhhhyad9q5/GddqCxktid; 20:NXzvkH3gHsUr+jnB9FWDykPC2wou/Z3SXOlsg2JGA36rM9MVbWJpV4rVWBt3fGRgka+kz+DEg+/G+hsjVV/hw2OpRVoHBHmqgPodr/Tk+3k3RhURhRAB7+Z8yXridpzijc2CeAp0J5iZfGlvFmkihyDSDZ2qZP7WtiAm2C0k4PE= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d9e4d06e-d785-4522-ebdb-08d582c8bbd0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603319)(7193020); SRVR:CY4PR21MB0741; x-ms-traffictypediagnostic: CY4PR21MB0741: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(258766100185102)(85827821059158)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(3231220)(944501244)(52105095)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0741; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0741; x-forefront-prvs: 06022AA85F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(39380400002)(376002)(366004)(346002)(13464003)(199004)(189003)(966005)(33656002)(54906003)(7736002)(305945005)(2900100001)(74316002)(6506007)(102836004)(53546011)(186003)(22452003)(46003)(14454004)(99286004)(59450400001)(5660300001)(6436002)(478600001)(55016002)(6306002)(9686003)(2906002)(106356001)(6116002)(3280700002)(3660700001)(316002)(10290500003)(68736007)(229853002)(39060400002)(4326008)(575784001)(10090500001)(105586002)(97736004)(81166006)(81156014)(2950100002)(8676002)(8936002)(25786009)(86362001)(6916009)(76176011)(86612001)(7696005)(6246003)(53936002)(8990500004)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0741; H:CY4PR21MB0856.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: tTPp7nRBBhXI2stijq75MMTQdcEurh8EFSrgEmucKhW/z9gd6Hrz4VcfBncfisbHthu2fGL+F2tCROwcHcqrSJajCWQfvqp8Ac/8HYC6FKxP617BJA1fcm+wJQrs4G1HiiW8VKGppcpl4D0WJZwt/2UHeiYz41pg7YxnXyXB48IaAh46TJI4X0MIvAVakY9ZNt/DmAU9JttOzDvAt+W1S6kNgUuotQ0rYTbopxOACqbeonOiUaRGQxBorw6B/kyJj3sN+q6cpgj6MkifFgLAuJfiWgLEJfXg1hQocivw6VSourRPlfdmQb8Fllb7WnbxSh8o6+n+9b8L03cep4MM8w== 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-Network-Message-Id: d9e4d06e-d785-4522-ebdb-08d582c8bbd0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2018 18:41:39.6238 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0741 Archived-At: Subject: Re: [Teep] [EXT] Milestones X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 18:41:45 -0000 SGkgTWluZywNCg0KVG9kYXkgaXMgdGhlIGRlYWRsaW5lIGZvciBkcmFmdCB1cGRhdGVzIGJlZm9y ZSBJRVRGLiAgV2lsbCB5b3UgYmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIE9UclA/DQoNCkRh dmUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1pbmdsaWFuZyBQZWkgW21h aWx0bzpNaW5nbGlhbmdfUGVpQHN5bWFudGVjLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1 YXJ5IDE0LCAyMDE4IDExOjMxIEFNDQpUbzogS2F0aGxlZW4gTW9yaWFydHkgPGthdGhsZWVuLm1v cmlhcnR5LmlldGZAZ21haWwuY29tPjsgdGVlcCA8dGVlcEBpZXRmLm9yZz47IHRlZXAtY2hhaXJz QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0VYVF0gW1RlZXBdIE1pbGVzdG9uZXMNCg0KSGkgS2F0 aGxlZW4sDQoNClRoZSBleGlzdGluZyBSRkMgZHJhZnQgT1RyUCBoYXMgYm90aCBhcmNoaXRlY3R1 cmUgZGlzY3Vzc2lvbiBhbmQgbWVzc2FnZSBwcm90b2NvbCBzZWN0aW9ucy4gSSBhbSB3b3JraW5n IG9uIHRvIHJlbW92ZSB0aGUgY2xpZW50IEFQSSBzZWN0aW9uIGFuZCB0cmFuc3BvcnQgc3VwcG9y dCBjaG9pY2UgYWNjb3JkaW5nIHRvIGZlZWRiYWNrcyBmcm9tIERhdmUgYW5kIG90aGVycyBpbiB0 aGlzIGdyb3VwLiBXZSBtYXkgbW92ZSBhcmNoaXRlY3R1cmUgZGlzY3Vzc2lvbiBpbnRvIGEgc2Vw YXJhdGUgYXJjaGl0ZWN0dXJlIGRvYyB3aXRoIGFkZGl0aW9uYWwgZWxhYm9yYXRpb25zIGFuZCBr ZWVwIG1lc3NhZ2UgcHJvdG9jb2xzIGluIHRoaXMuIFdlIGFsc28gaGF2ZSBhIHVzZSBjYXNlIFJG QyBkcmFmdCAoYnkgRGFwZW5nIExpdSBldGMuKS4gVGhlIHRocmVlIG1heSBiZWNvbWUgdGhlIGlu aXRpYWwgc3RhcnRpbmcgcG9pbnQuIEEgc2VwYXJhdGUgYXJjaGl0ZWN0dXJlIGRvYyBuZWVkcyBz b21lIHByZXBhcmF0aW9uIHdvcmsgdG8gaGl0IE1hciB0aW1lbGluZS4gSXQgY291bGQgYmUgZmVh c2libGUuIERvIHlvdSBtZWFuIHRoYXQgd2Ugc2hvdWxkIHByZXNlbnQgYW4gYXJjaGl0ZWN0dXJl IGRyYWZ0IGRvYyBkdXJpbmcgSUVURj8NCg0KVGhhbmtzLA0KDQpNaW5nDQoNCu+7v09uIDIvMTQv MTgsIDEwOjUyIEFNLCAiVEVFUCBvbiBiZWhhbGYgb2YgS2F0aGxlZW4gTW9yaWFydHkiIDx0ZWVw LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21h aWwuY29tPiB3cm90ZToNCg0KICAgIEhlbGxvLA0KICAgIA0KICAgIEkgdXNlZCB0aGUgY2hhcnRl ciB0byBsaXN0IGEgZmV3IG1pbGVzdG9uZXMsIGJ1dCBhbSB1bnN1cmUgb2YgdGhlDQogICAgdGFy Z2V0IGRhdGVzIGFuZCBpZiB0aGUgZXhpc3RpbmcgZHJhZnQgc2hvdWxkIGJlIGxpc3RlZCBhcyB0 aGUNCiAgICBzb2x1dGlvbiBkcmFmdC4NCiAgICANCiAgICBJZiB0aGUgY2hhaXJzIGNvdWxkIGd1 aWRlIHRoZSBkaXNjdXNzIGFuZCBsZXQgbWUga25vdyB0aGUgYXBwcm9wcmlhdGUNCiAgICBkYXRl cywgSSB3aWxsIHVwZGF0ZSB0aGVtIGFjY29yZGluZ2x5LiAgSWYgeW91J2QgbGlrZSB0byBzZXQg Y2FsZW5kYXINCiAgICBkYXRlcyBmb3IgaGFja2F0aG9uIHdvcmssIHdlIGNhbiBkbyB0aGF0IGFz IHdlbGwuDQogICAgDQogICAgSGVyZSdzIHdoYXQgSSBwdXQgZG93bjoNCiAgICBNYXIgMjAxOCBB ZG9wdCBhbiBBcmNoaXRlY3R1cmUgZG9jdW1lbnQgQ2hhbmdlZA0KICAgIE9jdCAyMDE4IEFkb3B0 IGEgc29sdXRpb24gZG9jdW1lbnQgQ2hhbmdlZA0KICAgIERlYyAyMDE4IEJlZ2luIFdHTEMgZm9y IEFyY2hpdGVjdHVyZSBkb2N1bWVudCBDaGFuZ2VkDQogICAgSnVsIDIwMTkgQmVnaW4gV0dMQyBm b3IgU29sdXRpb24gZG9jdW1lbnQgQ2hhbmdlZA0KICAgIA0KICAgIFRoYW5rIHlvdSENCiAgICAN CiAgICAtLSANCiAgICANCiAgICBCZXN0IHJlZ2FyZHMsDQogICAgS2F0aGxlZW4NCiAgICANCiAg ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFRF RVAgbWFpbGluZyBsaXN0DQogICAgVEVFUEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vbmEwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGY2xpY2t0aW1l LnN5bWFudGVjLmNvbSUyRmElMkYxJTJGWG1kQ1djbUxMc3pWWUVySy1kbGZ3SVdaLW1tbjc0c2s5 MFc4aWxnblpaNCUzRCUzRmQlM0Q2eV9mOEVOY2NsNEM5RGd2NVZMMEh3UVotVUhJUWFvZVcwTDFE dlllS0pMVFljbTh6bzR3NVZwUmJLY251UDBtTG1XX3MwZkx4aXJYRkpZdHp0Z09wU3c5dGsxR2tG X1oweDBsZWJkeDU3Z2JjZ3V4dHhiWjBWbG9hTk1zU0g5X3VEVmN4V3BnczRNU3BoX29wVHVpQ3J2 dFpCcTZQUW1QRTJmMUNMSEFDWmxxdG55Y1BaUnhOWFVFVDVRQ3F6SXd4bkhWZ3NCZzhOeEZJQjZ4 dkNnZ200dEtfVmJaNWgtOGtmTkpYUS14YWNEbVpucW1KRXZ6SV9ia3AzbVlNNzhFZVFhbUFGX2N3 TXFTQkMwbV9Kak9fdXpMMEJLZjNuajB4ZFRUQzVqZzNaN3pkY25TQlRnNWRycU95ZzhOLU1hS25C T19lQUxDazVjSXpSWjFJQ01ya1JCU2ZKV1lqXzNZZU1pTmswOThzekZtSUJyUHZ3S3ZwVHhRWnVI bjBnJTI1M0QlMjUzRCUyNnUlM0RodHRwcyUyNTNBJTI1MkYlMjUyRnd3dy5pZXRmLm9yZyUyNTJG bWFpbG1hbiUyNTJGbGlzdGluZm8lMjUyRnRlZXAmZGF0YT0wNCU3QzAxJTdDZHRoYWxlciU0MG1p Y3Jvc29mdC5jb20lN0NkYzQ1YjZiOTA1NzI0MTlmZWU3ZTA4ZDU3M2UxODMwOCU3QzcyZjk4OGJm ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY1NDIzMzQ3ODA0NzYzMDMlN0NV bmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklp TENKQlRpSTZJazFoYVd3aWZRJTNEJTNEJTdDLTEmc2RhdGE9WTh6Qk5BeEpUQ0R3a29RVGs5eFA2 TkNuQ0clMkJlbyUyRlZSZ1dwV1N0cWdBeVklM0QmcmVzZXJ2ZWQ9MA0KICAgIA0KDQo= From nobody Wed Mar 7 07:01:11 2018 Return-Path: X-Original-To: teep@ietf.org Delivered-To: teep@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 826861270A3; Wed, 7 Mar 2018 07:01:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: teep-chairs@ietf.org, teep@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152043486849.17731.2413058069180909082.idtracker@ietfa.amsl.com> Date: Wed, 07 Mar 2018 07:01:08 -0800 Archived-At: Subject: [Teep] Spencer Dawkins' No Objection on charter-ietf-teep-00-04: (with COMMENT) X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 15:01:09 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-teep-00-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-teep/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection to this charter, but do the milestones for the Solutions draft make sense? I'm reading Date Milestone Jul 2019 Begin WGLC for Solution document Jan 2019 Progress Architecture document to the IESG for publication Dec 2018 Begin WGLC for Architecture document Aug 2018 Progress Solution document to the IESG for publication Mar 2018 Adopt a solution document Mar 2018 Adopt an Architecture document as saying the draft goes to the IESG in Aug 2018 and enters WGLC in July 2019 ... From nobody Wed Mar 7 09:28:00 2018 Return-Path: X-Original-To: teep@ietf.org Delivered-To: teep@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FC31200C1; Wed, 7 Mar 2018 09:27:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: teep-chairs@ietf.org, teep@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152044367368.17669.17142974292596589090.idtracker@ietfa.amsl.com> Date: Wed, 07 Mar 2018 09:27:53 -0800 Archived-At: Subject: [Teep] Alissa Cooper's No Objection on charter-ietf-teep-00-04: (with COMMENT) X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 17:27:54 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-teep-00-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-teep/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "providing TEEs providing lifecycle management" --> something is wrong there "The group will produce the following deliverables. The first draft is" --> kind of implies that the deliverable is a draft rather than an RFC s/other relevant standards/other relevant standards groups/ From nobody Wed Mar 7 09:57:41 2018 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D044E120726; Wed, 7 Mar 2018 09:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=gmail.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 PJGLQ33SgxxJ; Wed, 7 Mar 2018 09:57:33 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB89120725; Wed, 7 Mar 2018 09:57:33 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id u84so3984037iod.9; Wed, 07 Mar 2018 09:57:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rG+nFeQXZfbstZHjFVdLLQPs0IXIcgLMWa+GsLUAj6A=; b=XsBDSgldV/FNA7gcUljojiPQD8XEj0Q371nLfwFlzk1AnGrVWjAx+9P1trji1oeK6F Rhnxi6XaODmksOeqOwm/bqb3y+sGoXgUE17fh9JNy2XIDSDcMStomflXy5Ddsf5BPQNS Lyk88EtP++f2jOdxfBydjTct75mj+bl6pnIJMnBWngMu+AqxFJWesDnCjI77T03Xlurc w1RQyTfo9CAodLdCLOBe1+QKzDfQ256xh5ctzSDwc8VHmteJW31Zo25FKmIbfTBbkmn0 dsK3iTN4UJhtt3QpP387BFxppO7FgSfsqV/alRrTKPWgd5th6P/NmSUaBwjbGW2Axc1v GnlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rG+nFeQXZfbstZHjFVdLLQPs0IXIcgLMWa+GsLUAj6A=; b=HCxkLULZvY6AeUByZXI8y01GKW2T9kE3bF7z8Gf2wwFA5sLFl9L0sX69nqD8UBZMpr lnuM6aiXrzrqvZXhVILep/Mfoo5M2C7RNsFrT2J9ZM370t5fek/EgZgUEcQm1Tw0rEaa /ctwXRHMUV50GwseR+fygzR2S+iy8U3cAP+ukY1s9NdSoJGpfumPceARdLS4xXbHoKyX U1D5nOfzAaLNX48rvRABGdJ3u4Ocwwpx4TWnP2hymKU3N19oEFAvOANveyCRAFfAP5DJ D6ZjE+mvHuSV8reL7lWEmA7jHQQsQMU6GuGP0U33EjDvYILugwayY18PydbTxdlgcF6H 2kEQ== X-Gm-Message-State: APf1xPD4UGfMad1VxdO9zwBF3dDB29h4J8qNTgkuLRFljbqc0B7p6iXR /GmhPgcWjITcB8HNxJ6Ip4JIN+OSX+lO1cDPrhQ= X-Google-Smtp-Source: AG47ELuLpc/f41Tl+kxGGVOPYGu3IIgG78eoooSi222KCYjyg5RQRh0B9J+8UmnJc/DcSDJydE3gEhXS5x1Aw++Dmi4= X-Received: by 10.107.102.13 with SMTP id a13mr27275904ioc.61.1520445452668; Wed, 07 Mar 2018 09:57:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.192.156.137 with HTTP; Wed, 7 Mar 2018 09:56:52 -0800 (PST) In-Reply-To: <152044367368.17669.17142974292596589090.idtracker@ietfa.amsl.com> References: <152044367368.17669.17142974292596589090.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Wed, 7 Mar 2018 12:56:52 -0500 Message-ID: To: Alissa Cooper Cc: The IESG , teep , teep-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Teep] Alissa Cooper's No Objection on charter-ietf-teep-00-04: (with COMMENT) X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 17:57:35 -0000 Hi Alissa, Thank you for your editorial suggestions. I made updates to address these. inline. On Wed, Mar 7, 2018 at 12:27 PM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > charter-ietf-teep-00-04: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-teep/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "providing TEEs providing lifecycle management" --> something is wrong there s/providing TEEs providing lifecycle management/providing TEEs with lifecycle management/ > > "The group will produce the following deliverables. The first draft is" --> > kind of implies that the deliverable is a draft rather than an RFC s/The first draft is/The first document is/ New sentence to remove second use of document: The first document is on architecture, describing the involved entities, their relationships, assumptions, the keying framework, and relevant use cases. > > s/other relevant standards/other relevant standards groups/ Done, thanks! > > -- Best regards, Kathleen From nobody Thu Mar 8 01:12:45 2018 Return-Path: X-Original-To: teep@ietf.org Delivered-To: teep@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B589C1205F0; Thu, 8 Mar 2018 01:12:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: teep-chairs@ietf.org, teep@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152050035872.21252.5883589579764321170.idtracker@ietfa.amsl.com> Date: Thu, 08 Mar 2018 01:12:38 -0800 Archived-At: Subject: [Teep] Benoit Claise's No Objection on charter-ietf-teep-00-05: (with COMMENT) X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 09:12:39 -0000 Benoit Claise has entered the following ballot position for charter-ietf-teep-00-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-teep/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection to the charter, but we should clarify two points. 1. I scratched my head: What does an "application layer protocol" mean in this context? This working group aims to develop an application layer protocol providing TEEs with lifecycle management and security domain management for trusted applications. What would the difference with? This working group aims to develop a management protocol providing TEEs with lifecycle management and security domain management for trusted applications. Or even? This working group aims to develop a protocol providing TEEs with lifecycle management and security domain management for trusted applications. 2. Second, a solution document that describes the above-described functionality that will be developed. A solution document? I believe it's too vague. I understand you want to specify a new protocol. You should clarify and adapt the milestones. Editorial: - Confused by the comma in the following sentence: For example, implementations of the TEE concept have been developed by ARM, and Intel using the TrustZone and the SGX technology, respectively. Do you want to say? For example, implementations of the TEE concept have been developed by ARM and Intel, using the TrustZone and the SGX technology, respectively. Or maybe better? For example, implementations of the TEE concept have been developed by ARM using the TrustZone and by Intel using the SGX technology. From nobody Thu Mar 8 07:00:58 2018 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB351241F8; Thu, 8 Mar 2018 07:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 tFSCNFEIscTM; Thu, 8 Mar 2018 07:00:42 -0800 (PST) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B35D120713; Thu, 8 Mar 2018 07:00:36 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id k135so7938982ite.2; Thu, 08 Mar 2018 07:00:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V8ShSqbsnq4FJKvWlGyBZurtVz/7qbnXFB5HYKZD/EA=; b=MtBXmzfrXqjqzM3j8JFWTjPhOv+5myfbWRktz8u/0Q1c5/sKSeVpJgbDJah91u2xkc ioPktFdJa1nnUmLuxf5t3ivpJE55cn4A0xx9IsJVhZ4/1IcN2qtiuNn6qUn52wAIf5x8 ClOgLEcKs2NuV9JCoNTepczMP+8FNP913nxNQa2ECwkH6pMgOuxeN48/nwpeRNuI+Kdr C6CCy+9FCUtwIKardPDFVD0jSUZ8GxbsYpDFkD/FOuXfohE3TlN53l/M/uw+rphN+E+0 af9y9obqXQsvSa3Kd7RYX1Hbe3EwBRNDLuaWl6ftMSgnluTHAPAUHeeZrJwRBixsXrAE oxvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V8ShSqbsnq4FJKvWlGyBZurtVz/7qbnXFB5HYKZD/EA=; b=UUAx7qoQixvpVVML6UUW6N0J1mZdC2L9kVYjYAyKRQYhDWgbGNj3+Sb26geszeGn60 8iG+rkjiJYOVi8cf5iOYhwDmuoHM5wEusjLe9pl5tGHGBmAwgEBWziAIuMBWpy8qsXiH k0lDOQ7l12lHyGKtnWHIcfgKY9dYZpP+Qut7N65miCuG0wXO+7mH1LXgmvLQ/YnqJ7OF xBEww8oW4dZTPQDOQkZv1Tns0reV+maAbLGWzkWY0n7hRe1RqNWS8JxJOMTHoOn6l5hQ PmqrJM5SRW7deZ7ZVrBY44sA4KH/6b35Pz1l4clTYvHiOdEjukmxNdT50CZYfllpIqBw Xtmg== X-Gm-Message-State: AElRT7GLbc2ORQEkdQQII7T/fSwK7myesq1mYFZq5JTJCd+kyqrTQ6k3 Q9zsRh3+eGtzMBcmIxNIqNYxJRDPC0kt/ljtzs4= X-Google-Smtp-Source: AG47ELt/wnQ8m2PWLIDoYVtbmMZ9KUU7uaKZ/Q/JVaHtMYyalX0KHW5ybpsppUlvDCgKNw7WSgZBTPathbvv6joW994= X-Received: by 10.36.115.13 with SMTP id y13mr27482294itb.130.1520521235217; Thu, 08 Mar 2018 07:00:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.192.156.137 with HTTP; Thu, 8 Mar 2018 06:59:54 -0800 (PST) In-Reply-To: <152050035872.21252.5883589579764321170.idtracker@ietfa.amsl.com> References: <152050035872.21252.5883589579764321170.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Thu, 8 Mar 2018 09:59:54 -0500 Message-ID: To: Benoit Claise Cc: The IESG , teep , teep-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Teep] Benoit Claise's No Objection on charter-ietf-teep-00-05: (with COMMENT) X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 15:00:50 -0000 Hi Benoit, Thank you for your comments. I'd like the chairs to chime in on the application layer protocol to see if they are okay with either of your suggestions. On Thu, Mar 8, 2018 at 4:12 AM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > charter-ietf-teep-00-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-teep/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > No objection to the charter, but we should clarify two points. > > 1. I scratched my head: What does an "application layer protocol" mean in this context? > > This working group aims to develop an application layer protocol providing TEEs > with lifecycle management and security domain management for trusted > applications. > > What would the difference with? > This working group aims to develop a management protocol providing TEEs > with lifecycle management and security domain management for trusted > applications. > > Or even? > This working group aims to develop a protocol providing TEEs > with lifecycle management and security domain management for trusted > applications. The last makes it more general, so I am sure this one is fine, but iuf there is a reason to keep application in there, I want to give the chairs a chance to respond. > > 2. > Second, a solution > document that describes the above-described functionality that will be > developed. > > A solution document? I believe it's too vague. > I understand you want to specify a new protocol. You should clarify and adapt the milestones. I modified the sentence as follows: Second, a solution document that includes the above-described functionality in a protocol will be developed. Does that help? Thanks for pointing out this issue. > > > Editorial: > - Confused by the comma in the following sentence: > > For example, implementations of the TEE > concept have been developed by ARM, and Intel using the TrustZone and the SGX > technology, respectively. > > Do you want to say? > For example, implementations of the TEE > concept have been developed by ARM and Intel, using the TrustZone and the SGX > technology, respectively. > > Or maybe better? > For example, implementations of the TEE > concept have been developed by ARM using the TrustZone and by Intel using the SGX > technology. > Thanks, I've updated using the first suggestion. > -- Best regards, Kathleen From nobody Thu Mar 8 07:53:21 2018 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC7C127058; Thu, 8 Mar 2018 07:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 xlHEh1iureyW; Thu, 8 Mar 2018 07:53:13 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0126.outbound.protection.outlook.com [104.47.34.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183F8124207; Thu, 8 Mar 2018 07:53:07 -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=AmtVMg4sDz+8BaiZDqi/7XjQr8luwhTQrP5i8BruRxM=; b=I2m5RilPAE8U9re8CuaJv0h/ce3ovDMyi3s5Bu1pqF0l1fnADX8rXEGoRxUlpQnNSUkjNpGBhCcVq5+PjQlMMJREpA9XRN22JbJ0br528xFmjx2WK2MFKjnUUqMnqdU5WZe+Hw3PuR76JF79Ntv8MMaitH6PoKL8+MOrtnNCcwU= Received: from CY4PR21MB0856.namprd21.prod.outlook.com (10.173.192.145) by CY4PR21MB0839.namprd21.prod.outlook.com (10.173.192.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.588.3; Thu, 8 Mar 2018 15:53:05 +0000 Received: from CY4PR21MB0856.namprd21.prod.outlook.com ([fe80::31df:7f8f:4b48:c145]) by CY4PR21MB0856.namprd21.prod.outlook.com ([fe80::31df:7f8f:4b48:c145%9]) with mapi id 15.20.0588.009; Thu, 8 Mar 2018 15:53:05 +0000 From: Dave Thaler To: Kathleen Moriarty , Benoit Claise CC: The IESG , teep , "teep-chairs@ietf.org" Thread-Topic: Benoit Claise's No Objection on charter-ietf-teep-00-05: (with COMMENT) Thread-Index: AQHTtr2cUe7dTy7TVk+wNqLx2y5n8KPGbsAAgAAOKkA= Date: Thu, 8 Mar 2018 15:53:05 +0000 Message-ID: References: <152050035872.21252.5883589579764321170.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-03-08T15:52:27.9303037Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [167.220.0.189] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0839; 7:HlrvH2tQQU97fhD3OosR/VPhtmTboZHYbUF6YdvUi/ylXXvU3lJvaQgXlKAm7RYoah2B2aw+B1GAG7AXBdWGGQObXwYBMIibTxvJ3JALa3SjlLe4197LeBF3isvA1tgQi12c8oAnXno0CuWgYROtMBWvyvZg2jSt7m40WKLfiBA+KhG7W46/zLYd0SMBr9wqj8wU7S8EhPF5OgNgiDrgXk+dL2cgoaFgYfF3YpNnAfYstZoyetMhIHRZQqh4R/7r; 20:M+DJcqBQUDFaqvEWDgrMPTJwGTFJzxjWqwM4HHM8ytxkQ0FkraABvM64XRp00m12UAo0An/H92s0CzNQQKRie2KEt0xZwXc2PA24APH7h1goAMHemlyV30bbnhjgN9BTXDpRoYMEXTZL1VTdb0UmpkSj3RbqcV9ssvVc/scEw/0= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8f824548-bfc3-4bad-6e00-08d5850cae91 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0839; x-ms-traffictypediagnostic: CY4PR21MB0839: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231220)(944501244)(52105095)(93006095)(93001095)(6055026)(61426038)(61427038)(6041288)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:CY4PR21MB0839; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0839; x-forefront-prvs: 060503E79B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(366004)(39380400002)(39860400002)(189003)(199004)(478600001)(33656002)(8990500004)(22452003)(39060400002)(10090500001)(4326008)(97736004)(105586002)(10290500003)(74316002)(305945005)(7736002)(106356001)(53936002)(6246003)(55016002)(9686003)(81156014)(25786009)(81166006)(8676002)(5660300001)(14454004)(86612001)(8936002)(6436002)(66066001)(6506007)(2900100001)(59450400001)(68736007)(3280700002)(76176011)(2906002)(186003)(229853002)(54906003)(3660700001)(316002)(110136005)(7696005)(3846002)(2950100002)(86362001)(6116002)(99286004)(5250100002)(102836004)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0839; H:CY4PR21MB0856.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: mLTFQAn1dG21tzG9S+3HPqgvEt5nTJSCLkAw2Oqy4EyhTlnIhq8BbcBwaaSO0ptYcEjEzavLzvXhLAzB0I4UiFk8ai+0frt1QCdz2oZHcGpnsVbRIz6bY7Wmn+1yfYfXu9F4jOAlL+f+XLFWQQtH3pWjYpxue+Ad73UuSfSpyceNA7y6fcPhz2Z868A6e2Kq3F2/KqMPW6F5RuzOSdNtbvkmkcLjKt+ebQEE5hlnYkw9g8PHwCrWzABR8epAorvMgDQCVIE5+QiHjV7LHUHsDBNMT8ZjNkcx/BeZp8GHkhEdyW9pfZ5QH9xFw7SvEjBowaL/c/qSo6GRQvM198Fgjg== 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-Network-Message-Id: 8f824548-bfc3-4bad-6e00-08d5850cae91 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2018 15:53:05.5473 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0839 Archived-At: Subject: Re: [Teep] Benoit Claise's No Objection on charter-ietf-teep-00-05: (with COMMENT) X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 15:53:15 -0000 QmVsb3cgd2l0aCBbRFRdDQoNCj4gMS4gSSBzY3JhdGNoZWQgbXkgaGVhZDogV2hhdCBkb2VzIGFu ICJhcHBsaWNhdGlvbiBsYXllciBwcm90b2NvbCIgbWVhbiBpbiB0aGlzIGNvbnRleHQ/DQo+DQo+ IFRoaXMgd29ya2luZyBncm91cCBhaW1zIHRvIGRldmVsb3AgYW4gYXBwbGljYXRpb24gbGF5ZXIg cHJvdG9jb2wgDQo+IHByb3ZpZGluZyBURUVzIHdpdGggbGlmZWN5Y2xlIG1hbmFnZW1lbnQgYW5k IHNlY3VyaXR5IGRvbWFpbiANCj4gbWFuYWdlbWVudCBmb3IgdHJ1c3RlZCBhcHBsaWNhdGlvbnMu DQo+DQo+IFdoYXQgd291bGQgdGhlIGRpZmZlcmVuY2Ugd2l0aD8NCj4gVGhpcyB3b3JraW5nIGdy b3VwIGFpbXMgdG8gZGV2ZWxvcCBhIG1hbmFnZW1lbnQgcHJvdG9jb2wgcHJvdmlkaW5nIA0KPiBU RUVzIHdpdGggbGlmZWN5Y2xlIG1hbmFnZW1lbnQgYW5kIHNlY3VyaXR5IGRvbWFpbiBtYW5hZ2Vt ZW50IGZvciANCj4gdHJ1c3RlZCBhcHBsaWNhdGlvbnMuDQo+DQo+IE9yIGV2ZW4/DQo+IFRoaXMg d29ya2luZyBncm91cCBhaW1zIHRvIGRldmVsb3AgYSBwcm90b2NvbCBwcm92aWRpbmcgVEVFcyB3 aXRoIA0KPiBsaWZlY3ljbGUgbWFuYWdlbWVudCBhbmQgc2VjdXJpdHkgZG9tYWluIG1hbmFnZW1l bnQgZm9yIHRydXN0ZWQgDQo+IGFwcGxpY2F0aW9ucy4NCg0KVGhlIGxhc3QgbWFrZXMgaXQgbW9y ZSBnZW5lcmFsLCBzbyBJIGFtIHN1cmUgdGhpcyBvbmUgaXMgZmluZSwgYnV0IGl1ZiB0aGVyZSBp cyBhIHJlYXNvbiB0byBrZWVwIGFwcGxpY2F0aW9uIGluIHRoZXJlLCBJIHdhbnQgdG8gZ2l2ZSB0 aGUgY2hhaXJzIGEgY2hhbmNlIHRvIHJlc3BvbmQuDQoNCltEVF0gQWdyZWUgdGhlIGxhc3Qgb25l IGlzIGZpbmUuDQoNCj4NCj4gMi4NCj4gU2Vjb25kLCBhIHNvbHV0aW9uDQo+IGRvY3VtZW50IHRo YXQgZGVzY3JpYmVzIHRoZSBhYm92ZS1kZXNjcmliZWQgZnVuY3Rpb25hbGl0eSB0aGF0IHdpbGwg YmUgDQo+IGRldmVsb3BlZC4NCj4NCj4gQSBzb2x1dGlvbiBkb2N1bWVudD8gSSBiZWxpZXZlIGl0 J3MgdG9vIHZhZ3VlLg0KPiBJIHVuZGVyc3RhbmQgeW91IHdhbnQgdG8gc3BlY2lmeSBhIG5ldyBw cm90b2NvbC4gWW91IHNob3VsZCBjbGFyaWZ5IGFuZCBhZGFwdCB0aGUgbWlsZXN0b25lcy4NCg0K SSBtb2RpZmllZCB0aGUgc2VudGVuY2UgYXMgZm9sbG93czoNClNlY29uZCwgYSBzb2x1dGlvbiBk b2N1bWVudCB0aGF0IGluY2x1ZGVzIHRoZSBhYm92ZS1kZXNjcmliZWQgZnVuY3Rpb25hbGl0eSBp biBhIHByb3RvY29sIHdpbGwgYmUgZGV2ZWxvcGVkLg0KDQpbRFRdIEZpbmUuDQoNCkRvZXMgdGhh dCBoZWxwPyAgVGhhbmtzIGZvciBwb2ludGluZyBvdXQgdGhpcyBpc3N1ZS4NCj4NCj4NCj4gRWRp dG9yaWFsOg0KPiAtIENvbmZ1c2VkIGJ5IHRoZSBjb21tYSBpbiB0aGUgZm9sbG93aW5nIHNlbnRl bmNlOg0KPg0KPiBGb3IgZXhhbXBsZSwgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBURUUgY29uY2Vw dCBoYXZlIGJlZW4gZGV2ZWxvcGVkIGJ5IA0KPiBBUk0sIGFuZCBJbnRlbCB1c2luZyB0aGUgVHJ1 c3Rab25lIGFuZCB0aGUgU0dYIHRlY2hub2xvZ3ksIA0KPiByZXNwZWN0aXZlbHkuDQo+DQo+IERv IHlvdSB3YW50IHRvIHNheT8NCj4gRm9yIGV4YW1wbGUsIGltcGxlbWVudGF0aW9ucyBvZiB0aGUg VEVFIGNvbmNlcHQgaGF2ZSBiZWVuIGRldmVsb3BlZCBieSANCj4gQVJNIGFuZCBJbnRlbCwgdXNp bmcgdGhlIFRydXN0Wm9uZSBhbmQgdGhlIFNHWCB0ZWNobm9sb2d5LCANCj4gcmVzcGVjdGl2ZWx5 Lg0KPg0KPiBPciBtYXliZSBiZXR0ZXI/DQo+IEZvciBleGFtcGxlLCBpbXBsZW1lbnRhdGlvbnMg b2YgdGhlIFRFRSBjb25jZXB0IGhhdmUgYmVlbiBkZXZlbG9wZWQgYnkgDQo+IEFSTSB1c2luZyB0 aGUgVHJ1c3Rab25lIGFuZCBieSBJbnRlbCB1c2luZyB0aGUgU0dYIHRlY2hub2xvZ3kuDQo+DQpU aGFua3MsIEkndmUgdXBkYXRlZCB1c2luZyB0aGUgZmlyc3Qgc3VnZ2VzdGlvbi4NCg0KW0RUXSBG aW5lLg0KDQpEYXZlDQoNCg== From nobody Thu Mar 8 08:02:46 2018 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23689127078; Thu, 8 Mar 2018 08:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 m7jlbS7H3Vf2; Thu, 8 Mar 2018 08:02:44 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 081C8124207; Thu, 8 Mar 2018 08:02:44 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id v194so8511736itb.0; Thu, 08 Mar 2018 08:02:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Dn80syM+jMv8qCfHeKjiFLc5g+HHWnXg8eOMvwyXd/M=; b=hLTyWnO5W31tl2jDBJ9RAWbxM5EtXwxeiWZu5TaRCLr4zHvxg+gtLCRKTwUBihU+cj QYa9AfB1CZjDCd3RIc0KXpp9cKqAPa15Ol04pxopKmmOWy6HKgW3LvtstbOIfSn+WjIo E7AIfrXMsJBuyUqq7ZI9ABj5hKtFs9lvqacxPiVy/qKEbbUD7XQnZQmQHjVweLJTbn3h vlqgg7cU8aNYXjn0pHZiCgiccnCd+6jcfTTDjJjI1pZs++RSxCpwwd/M+PRZt5oy7LOD 392Z0IPHubm3ZYPcVwRaKrYol4K3dBDDLS41qitTM3QmkG7bMdQk0/qGkrZpBr0QASvM lKOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Dn80syM+jMv8qCfHeKjiFLc5g+HHWnXg8eOMvwyXd/M=; b=fxMO++tj+sWFVUQBguay2deeRWNY+fwitKHoA2MLgTrHmW2lLVf2vkq0cojwP3lyxj G8X28CZgeFIJiXJaB7Nl+OSqGiyD7zRxIR04WZaZrzdvfcgkOVq7mOxMsjJkW+G4VrfO 8DGd7fDWIri6MUxiHZA1uv3DruyrjC+ltM5ErobJpdqNhi0gPhIRYkiFQXAA4xB+fMSy Xsh4mt8KU2tzuSbrVvRRge4nvVb07KxA/XLi1hnGXWANqm4VYssRwBV0NQbaNKKHG1B+ vOpNLA9p/VsRHxyc3mQwOAPCUg4BUcMr2QmeYzEN01/AHvic5CkuNxPNQquQy9N8/mjw 9EPQ== X-Gm-Message-State: AElRT7HzO8eSdt3iF4rmTFl+PC1UwQvT1a8oIqU6MyLkcm4GD6SJO49k adGeBlDAf0DTSJkko3Wq0ynJvjj0lo8caiYBldQ= X-Google-Smtp-Source: AG47ELsd4oo7jIQTudf8akBYOG/QBnbEBGGe4euGGZtD7OvqAQfIKPEuOVx8/MceQPZrEuHnAUG+M6x8uTFZ9RQJbD0= X-Received: by 10.36.60.138 with SMTP id m132mr29557922ita.132.1520524963351; Thu, 08 Mar 2018 08:02:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.192.156.137 with HTTP; Thu, 8 Mar 2018 08:02:03 -0800 (PST) In-Reply-To: References: <152050035872.21252.5883589579764321170.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Thu, 8 Mar 2018 11:02:03 -0500 Message-ID: To: Dave Thaler Cc: Benoit Claise , The IESG , teep , "teep-chairs@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Teep] Benoit Claise's No Objection on charter-ietf-teep-00-05: (with COMMENT) X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 16:02:45 -0000 Thanks Dave and Benoit, updates have been made in the current revision and the charter was approved on the call in the last minute. Best regards, Kathleen On Thu, Mar 8, 2018 at 10:53 AM, Dave Thaler wrote: > Below with [DT] > >> 1. I scratched my head: What does an "application layer protocol" mean in this context? >> >> This working group aims to develop an application layer protocol >> providing TEEs with lifecycle management and security domain >> management for trusted applications. >> >> What would the difference with? >> This working group aims to develop a management protocol providing >> TEEs with lifecycle management and security domain management for >> trusted applications. >> >> Or even? >> This working group aims to develop a protocol providing TEEs with >> lifecycle management and security domain management for trusted >> applications. > > The last makes it more general, so I am sure this one is fine, but iuf there is a reason to keep application in there, I want to give the chairs a chance to respond. > > [DT] Agree the last one is fine. > >> >> 2. >> Second, a solution >> document that describes the above-described functionality that will be >> developed. >> >> A solution document? I believe it's too vague. >> I understand you want to specify a new protocol. You should clarify and adapt the milestones. > > I modified the sentence as follows: > Second, a solution document that includes the above-described functionality in a protocol will be developed. > > [DT] Fine. > > Does that help? Thanks for pointing out this issue. >> >> >> Editorial: >> - Confused by the comma in the following sentence: >> >> For example, implementations of the TEE concept have been developed by >> ARM, and Intel using the TrustZone and the SGX technology, >> respectively. >> >> Do you want to say? >> For example, implementations of the TEE concept have been developed by >> ARM and Intel, using the TrustZone and the SGX technology, >> respectively. >> >> Or maybe better? >> For example, implementations of the TEE concept have been developed by >> ARM using the TrustZone and by Intel using the SGX technology. >> > Thanks, I've updated using the first suggestion. > > [DT] Fine. > > Dave > -- Best regards, Kathleen From nobody Fri Mar 9 09:31:12 2018 Return-Path: X-Original-To: teep@ietf.org Delivered-To: teep@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A80A6127241; Fri, 9 Mar 2018 09:31:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , teep@ietf.org, teep-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152061666468.11099.11941319180392439480.idtracker@ietfa.amsl.com> Date: Fri, 09 Mar 2018 09:31:04 -0800 Archived-At: Subject: [Teep] WG Action: Formed Trusted Execution Environment Provisioning (teep) X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2018 17:31:05 -0000 A new IETF WG has been formed in the Security Area. For additional information, please contact the Area Directors or the WG Chairs. Trusted Execution Environment Provisioning (teep) ----------------------------------------------------------------------- Current status: BOF WG Chairs: Nancy Cam-Winget Dave Thaler Assigned Area Director: Kathleen Moriarty Security Area Directors: Kathleen Moriarty Eric Rescorla Mailing list: Address: teep@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/teep Archive: https://mailarchive.ietf.org/arch/browse/teep/ Group page: https://datatracker.ietf.org/group/teep/ Charter: https://datatracker.ietf.org/doc/charter-ietf-teep/ The Trusted Execution Environment (TEE) is a secure area of a processor. The TEE provides security features such as isolated execution and integrity of Trusted Applications, along with provisions for maintaining the confidentiality of their assets. In general terms, the TEE offers an execution space that provides a higher level of security than a "rich" operating system and more functionality than a secure element. For example, implementations of the TEE concept have been developed by ARM and Intel, using the TrustZone and the SGX technology, respectively. To programmatically install, update, and delete applications in a TEE, the Trusted Execution Environment Provisioning protocol runs between a service within the TEE on a given device, a relay application or service access point on the device's network stack and a server-side infrastructure that interacts with and optionally maintains the applications. Some tasks are security sensitive and the server side requires information about the device characteristics in the form of attestation and the device-side may require information about the server. Privacy considerations have to be taken into account with authentication features and attestation. This working group aims to develop an a protocol providing TEEs with lifecycle management and security domain management for trusted applications. A security domain allows a service provider's applications to be isolated so that one security domain cannot be influenced by another domain, unless the domain exposes an API to allow inter-domain interactions. The solution approach must take a wide range of TEE and relevant technologies into account and will focus on the use of public key cryptography. The group will produce the following deliverables. The first document is on architecture, describing the involved entities, their relationships, assumptions, the keying framework, and relevant use cases. Second, a solution document that includes the above-described functionality in a protocol will be developed. The choice of encoding format(s) will be decided in the working group. The group may document several attestation technologies considering the different hardware capabilities, performance, privacy, and operational properties. The group will maintain a close relationship with the IETF SUIT working group, GlobalPlatform, Trusted Computing Group, and other relevant standards groups to ensure interoperability, compatibility, and proper use of existing TEE-relevant application layer interfaces. Milestones: Mar 2018 - Adopt an Architecture document Mar 2018 - Adopt a solution document Aug 2018 - Progress Solution document to the IESG for publication Dec 2018 - Begin WGLC for Architecture document Jan 2019 - Progress Architecture document to the IESG for publication Jul 2019 - Begin WGLC for Solution document From nobody Sun Mar 11 20:14:23 2018 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C38124234 for ; Sun, 11 Mar 2018 20:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 EIDDSIfZwmd0 for ; Sun, 11 Mar 2018 20:14:20 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEF91200A0 for ; Sun, 11 Mar 2018 20:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3484; q=dns/txt; s=iport; t=1520824460; x=1522034060; h=from:to:subject:date:message-id:mime-version; bh=qR1R3+mmQhyA6krSYU0Y8ssnZzs6ad2+kcjNWyf8wec=; b=Cp909Gzn0jmhCHQs2c6nDqhjxerpOYO43rMSPkinApgtmP1wLKbXxsFR xKpvV/YdeqhMjCQ7O5Ztq2mdjeZy71PkcES9h627WT1PRUtQSOppkVibA vSbIc56IE9QA2xRHJg8VqYF+QsdKJscPpeBGvE4lMiKif73bCvlAHccVB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BbAQAj8KVa/4cNJK1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJadmZvMoNGih+NcIFbgT+PEIUighUKhUGCdyE0GAECAQE?= =?us-ascii?q?BAQEBAmscC0IOAYR2BmgBDD4CBDAnBIRHZKpjgiaEb4NrghqFNYIugzwpDIJ?= =?us-ascii?q?JAYUtgyswgjIEmlYJAoFQjxGBY4Q1iEmRIQIREwGBKwEeOIFScBVkAYIZhEa?= =?us-ascii?q?JEYNPgRgBAQE?= X-IronPort-AV: E=Sophos;i="5.47,459,1515456000"; d="scan'208,217";a="366237374" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Mar 2018 03:14:19 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w2C3EJKL014484 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 12 Mar 2018 03:14:19 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 11 Mar 2018 23:14:18 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Sun, 11 Mar 2018 23:14:18 -0400 From: "Nancy Cam-Winget (ncamwing)" To: "teep@ietf.org" Thread-Topic: Call for agenda items Thread-Index: AQHTubA1/sObUrNkU02YhK92yK1bhg== Date: Mon, 12 Mar 2018 03:14:18 +0000 Message-ID: <7F0F9B61-CC63-42CD-9093-C1D92C367DBD@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.121.58] Content-Type: multipart/alternative; boundary="_000_7F0F9B61CC6342CD9093C1D92C367DBDciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Teep] Call for agenda items X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 03:14:22 -0000 --_000_7F0F9B61CC6342CD9093C1D92C367DBDciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIFRFRVAgV29ya2luZyBncm91cCB3aWxsIG1lZXQgTWFyIDIwIDEzOjMwLTE1OjMwIChTZXNz aW9uIElJKSBpbiBMb25kb24gKEJhbG1vcmFsIHJvb20pLg0KDQpQbGVhc2UgbGV0IG1lIGtub3cg aWYgeW91IGhhdmUgc29tZXRoaW5nIHRvIHByZXNlbnQgYXQgdGhlIG1lZXRpbmcuDQoNClRoYW5r cywgTmFuY3kNCg0KDQo= --_000_7F0F9B61CC6342CD9093C1D92C367DBDciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5UaGUgVEVFUCBXb3JraW5nIGdyb3VwIHdpbGwgbWVldCBNYXIgMjAgMTM6MzAt MTU6MzAgKFNlc3Npb24gSUkpIGluIExvbmRvbiAoQmFsbW9yYWwgcm9vbSkuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91 IGhhdmUgc29tZXRoaW5nIHRvIHByZXNlbnQgYXQgdGhlIG1lZXRpbmcuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFua3MsIE5hbmN5PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7F0F9B61CC6342CD9093C1D92C367DBDciscocom_-- From nobody Sun Mar 11 23:51:29 2018 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D76C124BAC for ; Sun, 11 Mar 2018 23:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=armh.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 GrdWYxL4GhpV for ; Sun, 11 Mar 2018 23:51:24 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0065.outbound.protection.outlook.com [104.47.0.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A1A1241F5 for ; Sun, 11 Mar 2018 23:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mZGSYMG/G0BY/EorvEveNhVzcfiZ2Fhju59Zi4OtlgY=; b=AOogBnnsfGWT+8BcPB2oN18hTevqD7hbgu4maRKug4f48bSbd+I4WBLeTM964fWsMlCms69q3YidRlMqcZnHoWTWPw3XimgfGByAK8PXw0/4hxjDV/hi1swFQR64/Dqic953c/smJMten8AdqFpCVzHwBp04jf7wCA2UTm+yIrU= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1904.eurprd08.prod.outlook.com (10.173.73.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.567.14; Mon, 12 Mar 2018 06:51:21 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::783f:d09c:fea6:f83d]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::783f:d09c:fea6:f83d%17]) with mapi id 15.20.0548.021; Mon, 12 Mar 2018 06:51:21 +0000 From: Hannes Tschofenig To: teep Thread-Topic: [Teep] WG Action: Formed Trusted Execution Environment Provisioning (teep) Thread-Index: AQHTt8xqSUcuVjttv0OfP6VT2/kjFqPMLRVw Date: Mon, 12 Mar 2018 06:51:20 +0000 Message-ID: References: <152061666468.11099.11941319180392439480.idtracker@ietfa.amsl.com> In-Reply-To: <152061666468.11099.11941319180392439480.idtracker@ietfa.amsl.com> 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=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.194.210] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1904; 7:RPi1zcxp2+7DMRS1bk7Mlzv/yFrwKs6aBjAqm3jcu4CmnW65sWqQGizI8Lcs/dKXLGJm4aiCkxksqUnfeMz5ZGI6RjUIzbqxuDgP0Xrw5LG1ZBOfWaY4UvOwZte0eE9eWpFf5MN6aixIL/9hFYx0wl0DC/JbRhfVfRl2/Z5eBcUk2yv+yFI0JMTYnCvJbY9pPjOM/QXKWAnotEirdg5VbzmD8A0nXF6+OEdup3HuFVQc1IZW13mXxuLMgN91niwT x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 42ca0411-8b1f-4594-7794-08d587e5a9f4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1904; x-ms-traffictypediagnostic: VI1PR0801MB1904: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(278428928389397)(89211679590171)(120809045254105)(192374486261705)(85827821059158)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231220)(944501244)(52105095)(10201501046)(6055026)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:VI1PR0801MB1904; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1904; x-forefront-prvs: 06098A2863 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39380400002)(346002)(39850400004)(366004)(376002)(189003)(13464003)(45074003)(199004)(40434004)(305945005)(6506007)(5250100002)(3660700001)(7696005)(72206003)(966005)(86362001)(25786009)(9686003)(6306002)(8936002)(2900100001)(26005)(6436002)(186003)(53936002)(74316002)(5890100001)(5660300001)(59450400001)(2473003)(7736002)(53546011)(55016002)(102836004)(8676002)(6116002)(3846002)(68736007)(81166006)(76176011)(66066001)(14454004)(6916009)(33656002)(229853002)(97736004)(81156014)(105586002)(99286004)(316002)(2906002)(106356001)(2950100002)(478600001)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1904; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 3DFRn0qaQ4Trur/WBfn1wHab4uNSOsoIoVPlBanhRgI0KGVv+NAr0Fz3thE/sPlzrOQq3eaNXqKm9hxzrutChwgGzcrsPk81Z7cODESQI7Xrpo2qR8acxmHUIUIMiiYYkslrG3tuGti5oZQwQ8ZLw9gQk5iG8vGfAe3h2JR+3ixBgZfb+PYff/ZK/Q0w21hcmEdfYWymSa81V/2Nf9/02rd1vHqSG6h74Chp/LrYe1/7UNcPUq47G58wmFW0uPp88QMFlCYXmxHKaKmFa64Z1OCaHT3XCs1WIt5AvyP3XgUyGnt2x3jVUwySguItdhRjEjoD95HruSVQlI9PvNPGLA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 42ca0411-8b1f-4594-7794-08d587e5a9f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2018 06:51:20.9862 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1904 Archived-At: Subject: [Teep] FW: WG Action: Formed Trusted Execution Environment Provisioning (teep) X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 06:51:27 -0000 Thanks to the chairs and the ADs for the hard work. It required many emails= , discussions and presentations during the last year to get to this stage. Ciao Hannes -----Original Message----- From: TEEP [mailto:teep-bounces@ietf.org] On Behalf Of The IESG Sent: 09 March 2018 18:31 To: IETF-Announce Cc: teep@ietf.org; The IESG; teep-chairs@ietf.org Subject: [Teep] WG Action: Formed Trusted Execution Environment Provisionin= g (teep) A new IETF WG has been formed in the Security Area. For additional informat= ion, please contact the Area Directors or the WG Chairs. Trusted Execution Environment Provisioning (teep) ----------------------------------------------------------------------- Current status: BOF WG Chairs: Nancy Cam-Winget Dave Thaler Assigned Area Director: Kathleen Moriarty Security Area Directors: Kathleen Moriarty Eric Rescorla Mailing list: Address: teep@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/teep Archive: https://mailarchive.ietf.org/arch/browse/teep/ Group page: https://datatracker.ietf.org/group/teep/ Charter: https://datatracker.ietf.org/doc/charter-ietf-teep/ The Trusted Execution Environment (TEE) is a secure area of a processor. Th= e TEE provides security features such as isolated execution and integrity o= f Trusted Applications, along with provisions for maintaining the confident= iality of their assets. In general terms, the TEE offers an execution space= that provides a higher level of security than a "rich" operating system and more functionality than a secure element. For example,= implementations of the TEE concept have been developed by ARM and Intel, u= sing the TrustZone and the SGX technology, respectively. To programmatically install, update, and delete applications in a TEE, the = Trusted Execution Environment Provisioning protocol runs between a service = within the TEE on a given device, a relay application or service access poi= nt on the device's network stack and a server-side infrastructure that inte= racts with and optionally maintains the applications. Some tasks are securi= ty sensitive and the server side requires information about the device char= acteristics in the form of attestation and the device-side may require info= rmation about the server. Privacy considerations have to be taken into account with authentication fe= atures and attestation. This working group aims to develop an a protocol providing TEEs with lifecy= cle management and security domain management for trusted applications. A security domain allows a service provider's applications to be isolated s= o that one security domain cannot be influenced by another domain, unless t= he domain exposes an API to allow inter-domain interactions. The solution approach must take a wide range of TEE and relevant technologi= es into account and will focus on the use of public key cryptography. The group will produce the following deliverables. The first document is on= architecture, describing the involved entities, their relationships, assum= ptions, the keying framework, and relevant use cases. Second, a solution do= cument that includes the above-described functionality in a protocol will b= e developed. The choice of encoding format(s) will be decided in the workin= g group. The group may document several attestation technologies considerin= g the different hardware capabilities, performance, privacy, and operationa= l properties. The group will maintain a close relationship with the IETF SUIT working gro= up, GlobalPlatform, Trusted Computing Group, and other relevant standards g= roups to ensure interoperability, compatibility, and proper use of existing= TEE-relevant application layer interfaces. Milestones: Mar 2018 - Adopt an Architecture document Mar 2018 - Adopt a solution document Aug 2018 - Progress Solution document to the IESG for publication Dec 2018 - Begin WGLC for Architecture document Jan 2019 - Progress Architecture document to the IESG for publication Jul 2019 - Begin WGLC for Solution document _______________________________________________ TEEP mailing list TEEP@ietf.org https://www.ietf.org/mailman/listinfo/teep IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Mon Mar 12 11:56:55 2018 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E671126C3D for ; Mon, 12 Mar 2018 11:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symantec.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 HrZM_BOdZs1R for ; Mon, 12 Mar 2018 11:56:51 -0700 (PDT) Received: from tussmtoutape02.symantec.com (tussmtoutape02.symantec.com [155.64.38.232]) (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 648961241F8 for ; Mon, 12 Mar 2018 11:56:31 -0700 (PDT) Received: from tussmtmtaapi01.symc.symantec.com (tus3-f5-symc-ext-prd-snat5.net.symantec.com [10.44.130.5]) by tussmtoutape02.symantec.com (Symantec Messaging Gateway) with SMTP id EC.08.06850.E5DC6AA5; Mon, 12 Mar 2018 18:56:30 +0000 (GMT) X-AuditID: 0a2c7e32-681329e000001ac2-cd-5aa6cd5ef40f Received: from TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (tus3-f5-symc-ext-prd-snat4.net.symantec.com [10.44.130.4]) by tussmtmtaapi01.symc.symantec.com (Symantec Messaging Gateway) with SMTP id 7D.33.07071.E5DC6AA5; Mon, 12 Mar 2018 18:56:30 +0000 (GMT) Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) by TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 12 Mar 2018 11:56:29 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.128.4) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1365.1 via Frontend Transport; Mon, 12 Mar 2018 11:56:29 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symantec.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fw6CxvOndv2QVRgrcAW0eFlkYnHzCc1+l/tkE7vXhN4=; b=lOTUZDg83F8K9xDa2mE/McFszy54/D6bEaE/VF1Z00UYMFISFXqd7GAZSSOD3QsiEWSM/o7VOer0iWH58Sf8acwBvQSA/Zx3xoo8Pjzn7PU4HGTAVhb3/F1eNf7Q1yBBM5ZhqRBM1Ksedp1JLd7rjtYxPTmGC6UzxRne3Aj25m0= Received: from CY4PR1601MB1126.namprd16.prod.outlook.com (10.172.117.12) by CY4PR1601MB1319.namprd16.prod.outlook.com (10.172.118.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Mon, 12 Mar 2018 18:56:28 +0000 Received: from CY4PR1601MB1126.namprd16.prod.outlook.com ([fe80::31a9:6426:30d2:cc1a]) by CY4PR1601MB1126.namprd16.prod.outlook.com ([fe80::31a9:6426:30d2:cc1a%18]) with mapi id 15.20.0548.021; Mon, 12 Mar 2018 18:56:28 +0000 From: Mingliang Pei To: Hannes Tschofenig , teep Thread-Topic: [EXT] [Teep] FW: WG Action: Formed Trusted Execution Environment Provisioning (teep) Thread-Index: AQHTuc6R1ALBAccwgUyiN0rsGXCJiqPMfq4A Date: Mon, 12 Mar 2018 18:56:28 +0000 Message-ID: References: <152061666468.11099.11941319180392439480.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Mingliang_Pei@symantec.com; x-originating-ip: [155.64.23.48] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR1601MB1319; 7:bPojtr+Ux/lAFvMVre4ElXYC4lyMjUXbDjI3BApShXYjhiqf2XoB0+gRskxQtQozKtqlQWxj1qekxEKpxv08I4F/mXHJisH4tmaCAHWZNxKEqCsum0/PBevq2oS/GHdLTBvNWc1Z3yBObOOxqjl04N1xAEest9iCs2NNln5hilDjNUHpUilPi2EhXZFgI0sLMbBKgHvtJy6ESRkqlrw7LLhfr2JGZe/KG1HzdEhMdk9yvrCuEkTKpVBYBWLmoGvM x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2193543c-830e-47c8-70d4-08d5884af638 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY4PR1601MB1319; x-ms-traffictypediagnostic: CY4PR1601MB1319: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(180628864354917)(278428928389397)(89211679590171)(192374486261705)(258766100185102)(85827821059158)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231220)(944501244)(52105095)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:CY4PR1601MB1319; BCL:0; PCL:0; RULEID:; SRVR:CY4PR1601MB1319; x-forefront-prvs: 06098A2863 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39380400002)(39860400002)(346002)(376002)(366004)(51914003)(45074003)(40434004)(199004)(189003)(13464003)(6506007)(59450400001)(2900100001)(5880100001)(5890100001)(110136005)(36756003)(97736004)(105586002)(33656002)(102836004)(26005)(6512007)(6486002)(80792005)(6306002)(8936002)(186003)(6246003)(66066001)(6436002)(99286004)(53936002)(53546011)(58126008)(5250100002)(966005)(14454004)(83716003)(478600001)(7736002)(229853002)(305945005)(72206003)(8676002)(5660300001)(3280700002)(3846002)(6116002)(82746002)(316002)(10290500003)(2950100002)(3660700001)(106356001)(76176011)(86362001)(81156014)(25786009)(68736007)(81166006)(2906002)(575784001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1319; H:CY4PR1601MB1126.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: symantec.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4QqONPqU2f4mO93IMcfTMxn/Vv38LgChfXVu+KpB7uaWk/4/eHZi78TbMLYJXIlKxRugQCvfR/ph2YjrTXwY87D2DPRFVBME/JPaEWQ9/dPOjlIseZ+R7rmbIcBpFRTJUiJ3qj3bp+VVBjudXsyE1o49urtuwyhskJiZyHjxT4AAD6+TipgH9SODJuDUxRHWUZpD4eAyblTtUsDqFIGckkN+3kC2zDyk6vSGzbB/XW7gY0jPmABlvhYavM7hqMxH8q76Y0n9EQdmGsme7JU6Pw2OcxWpv0LVgI4A2RRsOKXXTujNQ2ANa6bMCGIFOuhLq4CZ6oHGGjjE+X+Jqux1mg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <76C2F02B654A5D498B4677A9B7A0833C@namprd16.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2193543c-830e-47c8-70d4-08d5884af638 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2018 18:56:28.1394 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1319 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTcRTH+d27uevFxc/l42AIuugPa84lWYaaEqUmaSIRMsi8zEtaTmWb ogkmZmmOMKWYGmjm3EBHZrTyhYI9rKUVmUE+IqdQgqbOVEyxdncN+ufwOd/vgfPgUKSkQehH ZeXoWE0Oky11owW0rEwYnDZiUiqqlxXhX+psRHjr1hoZQ8RbGi0o3mjcIJIJJR2ZwWZnFbCa kGPpdGbZ+DtRXn964XJ9D1GKStOqEEUBPgTlW3urEE1JsAPBrHVFUIXcXfrbl7Ui3lhH0D2z TfDJCwRjP207zg8Ev1aeIS4RYAcBevtrxDuNBCxX9rrxyXcEjiEj4jq6YQV8mMzhmnjhONis sYg4eTdWwZC9kJczwH5d75K9cCiMtSRwsgDvg2lrE+JYjKPBuDm5M0Qrgs9LU6653TED5oeb LkbYB9ZtFoJjEvvC+GwTwe+Gwdj3nuTZG+ZmtoUce2M5rOp5Rvg8bJR/Q/yNAqD9GsuX+8PH Jr1rRcBPCahdtO3cSw7WmgXEcyLcfNUh4otsCAwTViFvyKB65a4bz7nQNvZAeBuFNfw3X4Oz H4mDoKMnhJfjoW9ihOQ5EO7op0UNrv094U39rOA+ErahAF2+VqvW5ebrmDxWESrXFqlVXGCc /6KSq3LVj5HrY0pCu5Dj0elBhCkk9RAP95qUEiFT4KwcRECRUi9xc7dTEmcwRVdYTe4FTX42 qx1EeyiB1Fc8LzYoJfgio2Mvs2weq/nnEpS7XymKMeZE3kv6YypINadE1i+f6aRTRBW7rp4c pSMGPOrD1mrLFuxZseZbUSWZA7IgUVdewhS9+twchwLPPmkp9j7uo23u9w9WGy4VH6i4YbDL JKvzZbFLv9fORURVnoqG5MXOVHYy9sTRxHaZafTTV2nM8GGit7yODjCkJx2Z81yQCrSZzMH9 pEbL/AXHW8CULQMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURzGO3d37joSjmvqHyu0QZRlczMDiTAjKAmLqA/VwOVlu6jk5tym 6IfAt6K2rBQrHail08DWhMQ0J4rztYWlkpLTwrfeX3WZiWbt7vqhL4ff/3keOM//cCieKJ8f SqVpjYxeS6dL/ISkMLKA3KMcrFfIysd3xo6Xu4jYutVfvHgiwVZlQwlW6zJxklAID6iZ9LRs Rh8VlyxMLXA/F+g6knPmK9qIPJSnNCF/CnAMPOstFZiQkBLhJQRPZtcIbuhBMPrNte58QPDT 04LYgcQLBJhnBhDnVBEwf8Xhxw3vESz0W70ORflhGQxNatlLxPgorJTYBKy8CaugfyaHk9Uw c8nsk8U4GkZrj7EyibfDdHM1YjkAHwTryuR6iToEYz9ek6zhj2m4b1/xMcLBsOSyESzzcAi4 56oJbjcM1vYXPI6D4OPsGp/lICyFRTPHCCfBctGUrzHgcHhQyHDxrTBSbfatCPgxAaXfXSRn SKG55Cvi+Dhc7WsUcCEXgjsTzXzOiIQbnlt+HGdAw2gNnwt1InC8dK8PlTywf2lCN5Hc8l9z i7cJD0dAY1sUJydA+8Qgj+NtUGaeFlh8LxMITyvmyLuI34DCjVkGg8aoMdK0Lk0mlxpyNSr2 oL0/RiVVZWgeId+fOQytqGM10YkwhSQbA2SF9QoRn872Jp1oM0VKQgI6kzIVIpxCG5kLDKNj 9Of1WemMwYkIyj80D9X+LbvaPbH/d/uh+LDYgX0p1Fj5bsui9Z3HZIq2w+cu9/VzQRGt+oe5 8hNd92KWehR0ouNyU+ablrCLuSOhxXGvdEekgqFoeaRg7/DbLWqHs8/e/Wnstm36mlhM5fcq TxVXBtdoN4AS0WeRfmphR6D6zPCfqtP9I8NFOg/ukpCGVFq+i6c30P8AvVO6NhQDAAA= X-CFilter-Loop: TUS04 Archived-At: Subject: Re: [Teep] [EXT] FW: WG Action: Formed Trusted Execution Environment Provisioning (teep) X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 18:56:54 -0000 SSB3b3VsZCBhbHNvIGxpa2UgdG8gc2VuZCBteSBjb25ncmF0dWxhdGlvbiBhbmQgdGhhbmtzIGZv ciB0aGUgY2hhaXJzIGFuZCB0aGUgQURzIGFzIHdlbGwgYXMgbWFueSBwZW9wbGUgaW4gdGhpcyBn cm91cCB0byBnZXQgdG8gdGhpcyBncmVhdCBtaWxlc3RvbmUuIFdlIGFyZSBhY3RpdmVseSB3b3Jr aW5nIG9uIHJldmlzaW5nIFJGQyBkcmFmdHMgYW5kIGxvb2tpbmcgZm9yd2FyZCB0byB3b3JraW5n IHdpdGggYWxsIGluIHRoZSBXRy4gQmVzdCwNCg0KTWluZw0KDQrvu79PbiAzLzExLzE4LCAxMTo1 MSBQTSwgIlRFRVAgb24gYmVoYWxmIG9mIEhhbm5lcyBUc2Nob2ZlbmlnIiA8dGVlcC1ib3VuY2Vz QGlldGYub3JnIG9uIGJlaGFsZiBvZiBIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPiB3cm90ZToN Cg0KICAgIFRoYW5rcyB0byB0aGUgY2hhaXJzIGFuZCB0aGUgQURzIGZvciB0aGUgaGFyZCB3b3Jr LiBJdCByZXF1aXJlZCBtYW55IGVtYWlscywgZGlzY3Vzc2lvbnMgYW5kIHByZXNlbnRhdGlvbnMg ZHVyaW5nIHRoZSBsYXN0IHllYXIgdG8gZ2V0IHRvIHRoaXMgc3RhZ2UuDQogICAgDQogICAgQ2lh bw0KICAgIEhhbm5lcw0KICAgIA0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQogICAgRnJvbTogVEVFUCBbbWFpbHRvOnRlZXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIFRoZSBJRVNHDQogICAgU2VudDogMDkgTWFyY2ggMjAxOCAxODozMQ0KICAgIFRvOiBJRVRG LUFubm91bmNlDQogICAgQ2M6IHRlZXBAaWV0Zi5vcmc7IFRoZSBJRVNHOyB0ZWVwLWNoYWlyc0Bp ZXRmLm9yZw0KICAgIFN1YmplY3Q6IFtUZWVwXSBXRyBBY3Rpb246IEZvcm1lZCBUcnVzdGVkIEV4 ZWN1dGlvbiBFbnZpcm9ubWVudCBQcm92aXNpb25pbmcgKHRlZXApDQogICAgDQogICAgQSBuZXcg SUVURiBXRyBoYXMgYmVlbiBmb3JtZWQgaW4gdGhlIFNlY3VyaXR5IEFyZWEuIEZvciBhZGRpdGlv bmFsIGluZm9ybWF0aW9uLCBwbGVhc2UgY29udGFjdCB0aGUgQXJlYSBEaXJlY3RvcnMgb3IgdGhl IFdHIENoYWlycy4NCiAgICANCiAgICBUcnVzdGVkIEV4ZWN1dGlvbiBFbnZpcm9ubWVudCBQcm92 aXNpb25pbmcgKHRlZXApDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBDdXJyZW50IHN0YXR1czog Qk9GIFdHDQogICAgDQogICAgQ2hhaXJzOg0KICAgICAgTmFuY3kgQ2FtLVdpbmdldCA8bmNhbXdp bmdAY2lzY28uY29tPg0KICAgICAgRGF2ZSBUaGFsZXIgPGR0aGFsZXJAbWljcm9zb2Z0LmNvbT4N CiAgICANCiAgICBBc3NpZ25lZCBBcmVhIERpcmVjdG9yOg0KICAgICAgS2F0aGxlZW4gTW9yaWFy dHkgPEthdGhsZWVuLk1vcmlhcnR5LmlldGZAZ21haWwuY29tPg0KICAgIA0KICAgIFNlY3VyaXR5 IEFyZWEgRGlyZWN0b3JzOg0KICAgICAgS2F0aGxlZW4gTW9yaWFydHkgPEthdGhsZWVuLk1vcmlh cnR5LmlldGZAZ21haWwuY29tPg0KICAgICAgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPg0K ICAgIA0KICAgIE1haWxpbmcgbGlzdDoNCiAgICAgIEFkZHJlc3M6IHRlZXBAaWV0Zi5vcmcNCiAg ICAgIFRvIHN1YnNjcmliZTogaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tL2EvMS9KcHFX UWtxV012MEVLUk9oenpfYkN4WENhQkI0WVVyS05nSmZvNHZyUkw0PT9kPWFVMnA1YmxXX3VrbGNV aWNRX25aYWVFbWh5QjZmN3hoZkpqYlhMMEZXQWdKRGhqYWd5bUJsYzlzZUNrNHFRS1B4cl9jZi0y SHluTUgtNzFOQjNuOEVmc1JIYTkxYmtza29Rc1Q4azJXUUJIMXRORUNnbXVTeWRRTTdZOFZtdWZw a3k0ZDJpamRDMzlaMTUyV1lHTGlPS0liMDZBRzh6dTZjRG9DRDg3NmhHdGhkc2o4MXV1NFlUelBG d3VtdE5PaGNhUW9hNVI2Ukd0YXYzY3EtcHNrNlFjYXBmQVlRX29RV3ZmWVlsSXdsRFVKZGJBNTZq aHQwaWxuUkVDZjllbHVZSDN2ZnhFV3hlWmhWTHY2ektMeHh4aHdNZ3NmN0VpLWRFd1ViRlF0VS01 OXNua2FlNC05NllHMGpmMEJ3c2tZeEdBZ3I0cEFUb0FhdDVNQW9sejRQLUNtOUpjVkRYbzF2UXA3 TXJhekJmak8zZG8zdVoydEhiTVVqTTNHX3dVQ0UxeEFSVUVoanAxdFI5c21pbFFwT0pTM3JLMU9w QUE4ZEZoejJubEtuSnpUanlxcVZFaXRMN3JuWXlsM20weWhsNUYyWUFIQy1hbFBuQjBHS29RUEw1 TFpJaGVDVlcxTTI3TSUzRCZ1PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUy Rmxpc3RpbmZvJTJGdGVlcA0KICAgICAgQXJjaGl2ZTogaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50 ZWMuY29tL2EvMS9MQlVnbmlfNzJLOGM2Z09sQzlDVXhPbkV5SnVKYldJVFZ0NWpxa2dvekpBPT9k PWFVMnA1YmxXX3VrbGNVaWNRX25aYWVFbWh5QjZmN3hoZkpqYlhMMEZXQWdKRGhqYWd5bUJsYzlz ZUNrNHFRS1B4cl9jZi0ySHluTUgtNzFOQjNuOEVmc1JIYTkxYmtza29Rc1Q4azJXUUJIMXRORUNn bXVTeWRRTTdZOFZtdWZwa3k0ZDJpamRDMzlaMTUyV1lHTGlPS0liMDZBRzh6dTZjRG9DRDg3NmhH dGhkc2o4MXV1NFlUelBGd3VtdE5PaGNhUW9hNVI2Ukd0YXYzY3EtcHNrNlFjYXBmQVlRX29RV3Zm WVlsSXdsRFVKZGJBNTZqaHQwaWxuUkVDZjllbHVZSDN2ZnhFV3hlWmhWTHY2ektMeHh4aHdNZ3Nm N0VpLWRFd1ViRlF0VS01OXNua2FlNC05NllHMGpmMEJ3c2tZeEdBZ3I0cEFUb0FhdDVNQW9sejRQ LUNtOUpjVkRYbzF2UXA3TXJhekJmak8zZG8zdVoydEhiTVVqTTNHX3dVQ0UxeEFSVUVoanAxdFI5 c21pbFFwT0pTM3JLMU9wQUE4ZEZoejJubEtuSnpUanlxcVZFaXRMN3JuWXlsM20weWhsNUYyWUFI Qy1hbFBuQjBHS29RUEw1TFpJaGVDVlcxTTI3TSUzRCZ1PWh0dHBzJTNBJTJGJTJGbWFpbGFyY2hp dmUuaWV0Zi5vcmclMkZhcmNoJTJGYnJvd3NlJTJGdGVlcCUyRg0KICAgIA0KICAgIEdyb3VwIHBh Z2U6IGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS9hLzEvSi00azZFeEtVNGlRSF9RbzBs Vm11Ynh5OC0wU0VHcDZIMXd4bnEwVGJfbz0/ZD1hVTJwNWJsV191a2xjVWljUV9uWmFlRW1oeUI2 Zjd4aGZKamJYTDBGV0FnSkRoamFneW1CbGM5c2VDazRxUUtQeHJfY2YtMkh5bk1ILTcxTkIzbjhF ZnNSSGE5MWJrc2tvUXNUOGsyV1FCSDF0TkVDZ211U3lkUU03WThWbXVmcGt5NGQyaWpkQzM5WjE1 MldZR0xpT0tJYjA2QUc4enU2Y0RvQ0Q4NzZoR3RoZHNqODF1dTRZVHpQRnd1bXROT2hjYVFvYTVS NlJHdGF2M2NxLXBzazZRY2FwZkFZUV9vUVd2ZllZbEl3bERVSmRiQTU2amh0MGlsblJFQ2Y5ZWx1 WUgzdmZ4RVd4ZVpoVkx2NnpLTHh4eGh3TWdzZjdFaS1kRXdVYkZRdFUtNTlzbmthZTQtOTZZRzBq ZjBCd3NrWXhHQWdyNHBBVG9BYXQ1TUFvbHo0UC1DbTlKY1ZEWG8xdlFwN01yYXpCZmpPM2RvM3Va MnRIYk1Vak0zR193VUNFMXhBUlVFaGpwMXRSOXNtaWxRcE9KUzNySzFPcEFBOGRGaHoybmxLbkp6 VGp5cXFWRWl0TDdybll5bDNtMHlobDVGMllBSEMtYWxQbkIwR0tvUVBMNUxaSWhlQ1ZXMU0yN00l M0QmdT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZ3JvdXAlMkZ0ZWVwJTJG DQogICAgDQogICAgQ2hhcnRlcjogaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tL2EvMS90 blIzU3dFTUtGMVdpTldxaVNDM214V2Nkc2xYbl9EM2ZIZEF3Z052T05NPT9kPWFVMnA1YmxXX3Vr bGNVaWNRX25aYWVFbWh5QjZmN3hoZkpqYlhMMEZXQWdKRGhqYWd5bUJsYzlzZUNrNHFRS1B4cl9j Zi0ySHluTUgtNzFOQjNuOEVmc1JIYTkxYmtza29Rc1Q4azJXUUJIMXRORUNnbXVTeWRRTTdZOFZt dWZwa3k0ZDJpamRDMzlaMTUyV1lHTGlPS0liMDZBRzh6dTZjRG9DRDg3NmhHdGhkc2o4MXV1NFlU elBGd3VtdE5PaGNhUW9hNVI2Ukd0YXYzY3EtcHNrNlFjYXBmQVlRX29RV3ZmWVlsSXdsRFVKZGJB NTZqaHQwaWxuUkVDZjllbHVZSDN2ZnhFV3hlWmhWTHY2ektMeHh4aHdNZ3NmN0VpLWRFd1ViRlF0 VS01OXNua2FlNC05NllHMGpmMEJ3c2tZeEdBZ3I0cEFUb0FhdDVNQW9sejRQLUNtOUpjVkRYbzF2 UXA3TXJhekJmak8zZG8zdVoydEhiTVVqTTNHX3dVQ0UxeEFSVUVoanAxdFI5c21pbFFwT0pTM3JL MU9wQUE4ZEZoejJubEtuSnpUanlxcVZFaXRMN3JuWXlsM20weWhsNUYyWUFIQy1hbFBuQjBHS29R UEw1TFpJaGVDVlcxTTI3TSUzRCZ1PWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmcl MkZkb2MlMkZjaGFydGVyLWlldGYtdGVlcCUyRg0KICAgIA0KICAgIFRoZSBUcnVzdGVkIEV4ZWN1 dGlvbiBFbnZpcm9ubWVudCAoVEVFKSBpcyBhIHNlY3VyZSBhcmVhIG9mIGEgcHJvY2Vzc29yLiBU aGUgVEVFIHByb3ZpZGVzIHNlY3VyaXR5IGZlYXR1cmVzIHN1Y2ggYXMgaXNvbGF0ZWQgZXhlY3V0 aW9uIGFuZCBpbnRlZ3JpdHkgb2YgVHJ1c3RlZCBBcHBsaWNhdGlvbnMsIGFsb25nIHdpdGggcHJv dmlzaW9ucyBmb3IgbWFpbnRhaW5pbmcgdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGVpciBhc3Nl dHMuIEluIGdlbmVyYWwgdGVybXMsIHRoZSBURUUgb2ZmZXJzIGFuIGV4ZWN1dGlvbiBzcGFjZSB0 aGF0IHByb3ZpZGVzIGEgaGlnaGVyIGxldmVsIG9mIHNlY3VyaXR5IHRoYW4gYSAicmljaCINCiAg ICBvcGVyYXRpbmcgc3lzdGVtIGFuZCBtb3JlIGZ1bmN0aW9uYWxpdHkgdGhhbiBhIHNlY3VyZSBl bGVtZW50LiBGb3IgZXhhbXBsZSwgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBURUUgY29uY2VwdCBo YXZlIGJlZW4gZGV2ZWxvcGVkIGJ5IEFSTSBhbmQgSW50ZWwsIHVzaW5nIHRoZSBUcnVzdFpvbmUg YW5kIHRoZSBTR1ggdGVjaG5vbG9neSwgcmVzcGVjdGl2ZWx5Lg0KICAgIA0KICAgIFRvIHByb2dy YW1tYXRpY2FsbHkgaW5zdGFsbCwgdXBkYXRlLCBhbmQgZGVsZXRlIGFwcGxpY2F0aW9ucyBpbiBh IFRFRSwgdGhlIFRydXN0ZWQgRXhlY3V0aW9uIEVudmlyb25tZW50IFByb3Zpc2lvbmluZyBwcm90 b2NvbCBydW5zIGJldHdlZW4gYSBzZXJ2aWNlIHdpdGhpbiB0aGUgVEVFIG9uIGEgZ2l2ZW4gZGV2 aWNlLCBhIHJlbGF5IGFwcGxpY2F0aW9uIG9yIHNlcnZpY2UgYWNjZXNzIHBvaW50IG9uIHRoZSBk ZXZpY2UncyBuZXR3b3JrIHN0YWNrIGFuZCBhIHNlcnZlci1zaWRlIGluZnJhc3RydWN0dXJlIHRo YXQgaW50ZXJhY3RzIHdpdGggYW5kIG9wdGlvbmFsbHkgbWFpbnRhaW5zIHRoZSBhcHBsaWNhdGlv bnMuIFNvbWUgdGFza3MgYXJlIHNlY3VyaXR5IHNlbnNpdGl2ZSBhbmQgdGhlIHNlcnZlciBzaWRl IHJlcXVpcmVzIGluZm9ybWF0aW9uIGFib3V0IHRoZSBkZXZpY2UgY2hhcmFjdGVyaXN0aWNzIGlu IHRoZSBmb3JtIG9mIGF0dGVzdGF0aW9uIGFuZCB0aGUgZGV2aWNlLXNpZGUgbWF5IHJlcXVpcmUg aW5mb3JtYXRpb24gYWJvdXQgdGhlIHNlcnZlci4NCiAgICANCiAgICBQcml2YWN5IGNvbnNpZGVy YXRpb25zIGhhdmUgdG8gYmUgdGFrZW4gaW50byBhY2NvdW50IHdpdGggYXV0aGVudGljYXRpb24g ZmVhdHVyZXMgYW5kIGF0dGVzdGF0aW9uLg0KICAgIA0KICAgIFRoaXMgd29ya2luZyBncm91cCBh aW1zIHRvIGRldmVsb3AgYW4gYSBwcm90b2NvbCBwcm92aWRpbmcgVEVFcyB3aXRoIGxpZmVjeWNs ZSBtYW5hZ2VtZW50IGFuZCBzZWN1cml0eSBkb21haW4gbWFuYWdlbWVudCBmb3IgdHJ1c3RlZCBh cHBsaWNhdGlvbnMuDQogICAgDQogICAgQSBzZWN1cml0eSBkb21haW4gYWxsb3dzIGEgc2Vydmlj ZSBwcm92aWRlcidzIGFwcGxpY2F0aW9ucyB0byBiZSBpc29sYXRlZCBzbyB0aGF0IG9uZSBzZWN1 cml0eSBkb21haW4gY2Fubm90IGJlIGluZmx1ZW5jZWQgYnkgYW5vdGhlciBkb21haW4sIHVubGVz cyB0aGUgZG9tYWluIGV4cG9zZXMgYW4gQVBJIHRvIGFsbG93IGludGVyLWRvbWFpbiBpbnRlcmFj dGlvbnMuDQogICAgDQogICAgVGhlIHNvbHV0aW9uIGFwcHJvYWNoIG11c3QgdGFrZSBhIHdpZGUg cmFuZ2Ugb2YgVEVFIGFuZCByZWxldmFudCB0ZWNobm9sb2dpZXMgaW50byBhY2NvdW50IGFuZCB3 aWxsIGZvY3VzIG9uIHRoZSB1c2Ugb2YgcHVibGljIGtleSBjcnlwdG9ncmFwaHkuDQogICAgDQog ICAgVGhlIGdyb3VwIHdpbGwgcHJvZHVjZSB0aGUgZm9sbG93aW5nIGRlbGl2ZXJhYmxlcy4gVGhl IGZpcnN0IGRvY3VtZW50IGlzIG9uIGFyY2hpdGVjdHVyZSwgZGVzY3JpYmluZyB0aGUgaW52b2x2 ZWQgZW50aXRpZXMsIHRoZWlyIHJlbGF0aW9uc2hpcHMsIGFzc3VtcHRpb25zLCB0aGUga2V5aW5n IGZyYW1ld29yaywgYW5kIHJlbGV2YW50IHVzZSBjYXNlcy4gU2Vjb25kLCBhIHNvbHV0aW9uIGRv Y3VtZW50IHRoYXQgaW5jbHVkZXMgdGhlIGFib3ZlLWRlc2NyaWJlZCBmdW5jdGlvbmFsaXR5IGlu IGEgcHJvdG9jb2wgd2lsbCBiZSBkZXZlbG9wZWQuIFRoZSBjaG9pY2Ugb2YgZW5jb2RpbmcgZm9y bWF0KHMpIHdpbGwgYmUgZGVjaWRlZCBpbiB0aGUgd29ya2luZyBncm91cC4gVGhlIGdyb3VwIG1h eSBkb2N1bWVudCBzZXZlcmFsIGF0dGVzdGF0aW9uIHRlY2hub2xvZ2llcyBjb25zaWRlcmluZyB0 aGUgZGlmZmVyZW50IGhhcmR3YXJlIGNhcGFiaWxpdGllcywgcGVyZm9ybWFuY2UsIHByaXZhY3ks IGFuZCBvcGVyYXRpb25hbCBwcm9wZXJ0aWVzLg0KICAgIA0KICAgIFRoZSBncm91cCB3aWxsIG1h aW50YWluIGEgY2xvc2UgcmVsYXRpb25zaGlwIHdpdGggdGhlIElFVEYgU1VJVCB3b3JraW5nIGdy b3VwLCBHbG9iYWxQbGF0Zm9ybSwgVHJ1c3RlZCBDb21wdXRpbmcgR3JvdXAsIGFuZCBvdGhlciBy ZWxldmFudCBzdGFuZGFyZHMgZ3JvdXBzIHRvIGVuc3VyZSBpbnRlcm9wZXJhYmlsaXR5LCBjb21w YXRpYmlsaXR5LCBhbmQgcHJvcGVyIHVzZSBvZiBleGlzdGluZyBURUUtcmVsZXZhbnQgYXBwbGlj YXRpb24gbGF5ZXIgaW50ZXJmYWNlcy4NCiAgICANCiAgICBNaWxlc3RvbmVzOg0KICAgIA0KICAg ICAgTWFyIDIwMTggLSBBZG9wdCBhbiBBcmNoaXRlY3R1cmUgZG9jdW1lbnQNCiAgICANCiAgICAg IE1hciAyMDE4IC0gQWRvcHQgYSBzb2x1dGlvbiBkb2N1bWVudA0KICAgIA0KICAgICAgQXVnIDIw MTggLSBQcm9ncmVzcyBTb2x1dGlvbiBkb2N1bWVudCB0byB0aGUgSUVTRyBmb3IgcHVibGljYXRp b24NCiAgICANCiAgICAgIERlYyAyMDE4IC0gQmVnaW4gV0dMQyBmb3IgQXJjaGl0ZWN0dXJlIGRv Y3VtZW50DQogICAgDQogICAgICBKYW4gMjAxOSAtIFByb2dyZXNzIEFyY2hpdGVjdHVyZSBkb2N1 bWVudCB0byB0aGUgSUVTRyBmb3IgcHVibGljYXRpb24NCiAgICANCiAgICAgIEp1bCAyMDE5IC0g QmVnaW4gV0dMQyBmb3IgU29sdXRpb24gZG9jdW1lbnQNCiAgICANCiAgICANCiAgICBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFRFRVAgbWFpbGlu ZyBsaXN0DQogICAgVEVFUEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVj LmNvbS9hLzEvSnBxV1FrcVdNdjBFS1JPaHp6X2JDeFhDYUJCNFlVcktOZ0pmbzR2clJMND0/ZD1h VTJwNWJsV191a2xjVWljUV9uWmFlRW1oeUI2Zjd4aGZKamJYTDBGV0FnSkRoamFneW1CbGM5c2VD azRxUUtQeHJfY2YtMkh5bk1ILTcxTkIzbjhFZnNSSGE5MWJrc2tvUXNUOGsyV1FCSDF0TkVDZ211 U3lkUU03WThWbXVmcGt5NGQyaWpkQzM5WjE1MldZR0xpT0tJYjA2QUc4enU2Y0RvQ0Q4NzZoR3Ro ZHNqODF1dTRZVHpQRnd1bXROT2hjYVFvYTVSNlJHdGF2M2NxLXBzazZRY2FwZkFZUV9vUVd2ZllZ bEl3bERVSmRiQTU2amh0MGlsblJFQ2Y5ZWx1WUgzdmZ4RVd4ZVpoVkx2NnpLTHh4eGh3TWdzZjdF aS1kRXdVYkZRdFUtNTlzbmthZTQtOTZZRzBqZjBCd3NrWXhHQWdyNHBBVG9BYXQ1TUFvbHo0UC1D bTlKY1ZEWG8xdlFwN01yYXpCZmpPM2RvM3VaMnRIYk1Vak0zR193VUNFMXhBUlVFaGpwMXRSOXNt aWxRcE9KUzNySzFPcEFBOGRGaHoybmxLbkp6VGp5cXFWRWl0TDdybll5bDNtMHlobDVGMllBSEMt YWxQbkIwR0tvUVBMNUxaSWhlQ1ZXMU0yN00lM0QmdT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9y ZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnRlZXANCiAgICBJTVBPUlRBTlQgTk9USUNFOiBUaGUg Y29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRp YWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8g bm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9y IGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVk aXVtLiBUaGFuayB5b3UuDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCiAgICBURUVQIG1haWxpbmcgbGlzdA0KICAgIFRFRVBAaWV0Zi5v cmcNCiAgICBodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vYS8xL0pwcVdRa3FXTXYwRUtS T2h6el9iQ3hYQ2FCQjRZVXJLTmdKZm80dnJSTDQ9P2Q9YVUycDVibFdfdWtsY1VpY1FfblphZUVt aHlCNmY3eGhmSmpiWEwwRldBZ0pEaGphZ3ltQmxjOXNlQ2s0cVFLUHhyX2NmLTJIeW5NSC03MU5C M244RWZzUkhhOTFia3Nrb1FzVDhrMldRQkgxdE5FQ2dtdVN5ZFFNN1k4Vm11ZnBreTRkMmlqZEMz OVoxNTJXWUdMaU9LSWIwNkFHOHp1NmNEb0NEODc2aEd0aGRzajgxdXU0WVR6UEZ3dW10Tk9oY2FR b2E1UjZSR3RhdjNjcS1wc2s2UWNhcGZBWVFfb1FXdmZZWWxJd2xEVUpkYkE1NmpodDBpbG5SRUNm OWVsdVlIM3ZmeEVXeGVaaFZMdjZ6S0x4eHhod01nc2Y3RWktZEV3VWJGUXRVLTU5c25rYWU0LTk2 WUcwamYwQndza1l4R0FncjRwQVRvQWF0NU1Bb2x6NFAtQ205SmNWRFhvMXZRcDdNcmF6QmZqTzNk bzN1WjJ0SGJNVWpNM0dfd1VDRTF4QVJVRWhqcDF0UjlzbWlsUXBPSlMzcksxT3BBQThkRmh6Mm5s S25KelRqeXFxVkVpdEw3cm5ZeWwzbTB5aGw1RjJZQUhDLWFsUG5CMEdLb1FQTDVMWkloZUNWVzFN MjdNJTNEJnU9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8l MkZ0ZWVwDQogICAgDQoNCg== From nobody Fri Mar 16 12:38:19 2018 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C4E124D37; Fri, 16 Mar 2018 12:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 dBqbGutEGwOk; Fri, 16 Mar 2018 12:38:16 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0101.outbound.protection.outlook.com [104.47.42.101]) (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 A9451124217; Fri, 16 Mar 2018 12:38:16 -0700 (PDT) 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=JB1qs1rQVr4O4x7JyK85SJp+a/3oYrWJkS3tPWEjUu0=; b=BGZj7bI2NBqNu0k7Pf6gMR+wueCS3oVtSDSs4/JsE6S9jZf5gfFWvTpD/TxDO+8ewS0MbcSEUKe3n4sADeQJJq+l4ac0igFdsX/ae+v5mlPgHb6Arm+D0LcjHw3xB5xkMvlOBOHvoh8/tqm8kJTllURLH3F1vmtNszbbfO7cUpE= Received: from MWHPR21MB0781.namprd21.prod.outlook.com (10.173.51.147) by MWHPR21MB0830.namprd21.prod.outlook.com (10.173.51.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.631.0; Fri, 16 Mar 2018 19:38:15 +0000 Received: from MWHPR21MB0781.namprd21.prod.outlook.com ([fe80::3c54:d4fb:fc4a:a549]) by MWHPR21MB0781.namprd21.prod.outlook.com ([fe80::3c54:d4fb:fc4a:a549%7]) with mapi id 15.20.0609.007; Fri, 16 Mar 2018 19:38:15 +0000 From: Dave Thaler To: teep CC: "teep-chairs@ietf.org" Thread-Topic: IETF 101 agenda requests Thread-Index: AdO9Xdcov18dMzNFTtSIcGlRK17eig== Date: Fri, 16 Mar 2018 19:38:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-03-16T19:38:13.1928488Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [73.59.106.235] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0830; 7:1L5GRyxI7AD/Ch6Bzs7khdLhZS4K/Vg0phakiNzlehVa9C8CqnyVJKIw+zepzayi4VNfRMmh4SFc7SJ2vPNp708QIH7I97kAYm4C+ecUIe3E9jveytNKGQY8HO0B4xbwumiTf80jMns4fg59kS03031HSLYxmbACvLEffR5iwAPd4hZosORJ0WqfWuFwR+wsfM+TQXW0EORVDpChuW74FP9lXcuuc82fDjJwi9ztrx+Hx7qUidxhPtKUNmEgYd5q; 20:xwIXOuqpn4XGA+krLk4Jz/bNhkT9AhjJrTAy+V0pYAu9ifEmg2shNu2gnJYg0e7FFveg+t7vhQZgrMzO3GiC191MfpfE1WYWBNOd8kSVKeI030KhelRen/KC7hQBo4D4sA63wTUwEmuIWo8Zy8yLRaaIaKiw0zBLmjtHWHexu4g= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 395d14ae-607f-4e39-ee06-08d58b757634 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:MWHPR21MB0830; x-ms-traffictypediagnostic: MWHPR21MB0830: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501281)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041310)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:MWHPR21MB0830; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0830; x-forefront-prvs: 0613912E23 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(39860400002)(366004)(346002)(376002)(189003)(199004)(7116003)(5660300001)(2906002)(7696005)(8990500004)(7736002)(102836004)(74316002)(6436002)(81156014)(3660700001)(8936002)(8676002)(478600001)(6506007)(3280700002)(316002)(10090500001)(106356001)(81166006)(97736004)(22452003)(68736007)(99286004)(3846002)(2900100001)(790700001)(6116002)(105586002)(5250100002)(66066001)(450100002)(4326008)(53936002)(6306002)(54896002)(14454004)(86362001)(55016002)(186003)(9686003)(10290500003)(26005)(33656002)(86612001)(25786009)(6916009); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0830; H:MWHPR21MB0781.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 0ILgmLyQjOzSXols6orcCGS1lU6psUg29edHSLFrS99AjFPc/Bnb5a2B5pnbRdDgyTGlyyPzn/iNe3zF366ZoV3g6s0i1BA808r/aYGrJBswfxeF2ENOU+Y5tjcP9OYrElmQomE0miAqumeYl3cDRrOQcj5OaJ8D4E98xCnaqC1vcPPI0zwbZVRe8mO2M7FOHZHKHaCdQGZ6FZX22sh+DlzUZyISP8Kd6ftP+HDuROa2VxxqhsAVL1QJh9s4UVkascoy3Y5FRxLZx7Q/7UpfS4lfKQ6AMEIWpyEAO6F4ATpAZLcsz/lYwqcrbOjRG/einRpj3P4bIIB3yio4IZ1/Aw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB078111616FCDCF87134B0FC0A3D70MWHPR21MB0781namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 395d14ae-607f-4e39-ee06-08d58b757634 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2018 19:38:15.2026 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0830 Archived-At: Subject: [Teep] IETF 101 agenda requests X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 19:38:19 -0000 --_000_MWHPR21MB078111616FCDCF87134B0FC0A3D70MWHPR21MB0781namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please send your requests for time on the TEEP WG agenda for IETF 101 as so= on as possible, to teep-chairs@ietf.org. Priority will be given to topics that have already had mailing discussion a= nd are targeted for items listed in charter milestones. Please also send slides by Sunday March 18th. Thanks, Dave --_000_MWHPR21MB078111616FCDCF87134B0FC0A3D70MWHPR21MB0781namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please send your requests for time on the TEEP WG ag= enda for IETF 101 as soon as possible, to teep-chairs@ietf.org.<= /p>

Priority will be given to topics that have already h= ad mailing discussion and are targeted for items listed in charter mileston= es.

 

Please also send slides by Sunday March 18th.

 

Thanks,

Dave

--_000_MWHPR21MB078111616FCDCF87134B0FC0A3D70MWHPR21MB0781namp_-- From nobody Thu Mar 22 02:26:54 2018 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A6D126C19; Thu, 22 Mar 2018 02:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=btFQPahx; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=dnqXLhhG 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 nFEv2KejDUgZ; Thu, 22 Mar 2018 02:26:50 -0700 (PDT) Received: from esa1.dell-outbound.iphmx.com (esa1.dell-outbound.iphmx.com [68.232.153.90]) (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 4470A126BF0; Thu, 22 Mar 2018 02:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1521710298; x=1553246298; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lszjpwGeXzxSIdQSNVR2EycE0RXJZkjpwrggG/Fcwfg=; b=btFQPahxRQUNjccYsVtASlUUFbUA+BwlXqTzVV6XucuoD4ZelVfvdA4i nZyRo7Rs3bHVcgUMv+hrsXPxzhc2s2xMFMinJwm8Xh8qUT7j17qwTs8NS XEM+vvJnI8KXuO8IZMa5IQMlBItqCwj81zHuzFBeaJpPIqdo/WLdVG/Gt A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2G4AABadbNah8qZ6ERdGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJJIiMEfg5wKAqYXYFygRCSVxSBNT0LLIRZAoNfITYWAQIBAQEBAQE?= =?us-ascii?q?CAQIQAQEBCgsJCCgjDII4JAEOSyEIMgEBAQEBAQEBAQEBAQEBAQEBARcCPRMCG?= =?us-ascii?q?AEBAQQtEy4LAQ8CAQgOAwEDAQELHQcyFAMGCAEBBAENBQiEImQBrTeCd4VKgXM?= =?us-ascii?q?IhSsEgRQMVRyBU0CBDIMGgUGCdhklNIJ7giSHI5BeCAKQKIN0h1aPZQIEAgQFA?= =?us-ascii?q?hSBJSMBggNwgxKCL4EFAQeCQ4pQb486gRYBAQ?= X-IPAS-Result: =?us-ascii?q?A2G4AABadbNah8qZ6ERdGgEBAQEBAgEBAQEIAQEBAYJJIiM?= =?us-ascii?q?Efg5wKAqYXYFygRCSVxSBNT0LLIRZAoNfITYWAQIBAQEBAQECAQIQAQEBCgsJC?= =?us-ascii?q?CgjDII4JAEOSyEIMgEBAQEBAQEBAQEBAQEBAQEBARcCPRMCGAEBAQQtEy4LAQ8?= =?us-ascii?q?CAQgOAwEDAQELHQcyFAMGCAEBBAENBQiEImQBrTeCd4VKgXMIhSsEgRQMVRyBU?= =?us-ascii?q?0CBDIMGgUGCdhklNIJ7giSHI5BeCAKQKIN0h1aPZQIEAgQFAhSBJSMBggNwgxK?= =?us-ascii?q?CL4EFAQeCQ4pQb486gRYBAQ?= Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2018 04:18:17 -0500 From: "faibish, sorin" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2018 15:21:45 +0600 Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w2M9Qkf8030954 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 22 Mar 2018 05:26:47 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com w2M9Qkf8030954 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1521710808; bh=WY4VN3yMT44mcLg9LH77G1W9Dxg=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=dnqXLhhGHAirHlfAyiKC7Gg0NVYmwTrIIPmCGX0xRzr5JvY+XNPDQI+vNBwYExIFk zLhq8iv+401zPJ5HLppKkdkHXCdVciIqCAgNELNyweiBXjDaWLoiOUvB89nzgr78li Ui+p1wdZqK2l7bEU4xSik2BU7lEt2wg2fumhauxo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com w2M9Qkf8030954 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd56.lss.emc.com (RSA Interceptor); Thu, 22 Mar 2018 05:25:47 -0400 Received: from MXHUB301.corp.emc.com (MXHUB301.corp.emc.com [10.146.3.27]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w2M9QNEL014686 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Thu, 22 Mar 2018 05:26:23 -0400 Received: from MX304CL01.corp.emc.com ([fe80::2d21:ebf8:dc15:2b07]) by MXHUB301.corp.emc.com ([10.146.3.27]) with mapi id 14.03.0382.000; Thu, 22 Mar 2018 05:26:22 -0400 To: Dave Thaler , teep CC: "teep-chairs@ietf.org" Thread-Topic: IETF 101 agenda requests Thread-Index: AdO9Xdcov18dMzNFTtSIcGlRK17eigEYdluQ Date: Thu, 22 Mar 2018 09:26:22 +0000 Message-ID: <2313358402DBCC4DB2F2DC03CB08BBFEFF050A@MX304CL01.corp.emc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.252.72.88] Content-Type: multipart/alternative; boundary="_000_2313358402DBCC4DB2F2DC03CB08BBFEFF050AMX304CL01corpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [Teep] IETF 101 agenda requests X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 09:26:52 -0000 --_000_2313358402DBCC4DB2F2DC03CB08BBFEFF050AMX304CL01corpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New proposed usecase for TEEP WG. Most recently the frequency and intensity of DDoS attacks from IoT devices = increased with attacks almost every day. The reason of the proliferation of= DDoS attacks from IoT devices is a result of the lower and maybe inexisten= t security protection of cheap IoT devices that have no security features i= mplemented as this would increase the cost of such devices using any securi= ty HW. In the current charter of TEEP there sre 3 usecases and I would like= to add the protectioin against DDoS of IoT as a new usecase: 1. Payment 2. IoT to allow authorized code access 3. Confidential cloud computing All the above usecases are only addressing the safety of the operation/exec= ution of code on the devices. My new usecase is addressing the outgoing dat= a/communication between the IoT device and the cloud provider that is colle= cting the data from the device. As it is implemented right now there is no = protocol allowing protection against malicious data packets that are sent b= y the device by the SW running inside the protected area that passed all th= e security requirements of all the security players: Developers, chip vendor, OEM vendor and TAM that are responsible for: - IoT Device - Trusted Application - Rich Application author - TEE chip vendor - Device OEM We want to focus the new usecase on IoT devices lacking rich execution envi= ronment that are mostly innocent generators of DDoS traffic that was implem= ented in the trusted SW or in the device HW during the design allowing back= doors for the DDoS attackers. TEE should have provisioning for preventing u= ndesired packets to be broadcasted to the network. As these devices use ine= xpensive HW they have no protection against the outgoing traffic even if it= is encrypted, or perhaps although it is encrypted, to prevent malicious da= ta packets to be broadcasted. Moreover there is also a need to protect against signaling sent to the devi= ce by attackers that controls the attack timing and duration using legitima= te data packets. One way TEEP protocol can protect against this type of att= acks is to use a "Security Provider" entity that will detect such attacks a= nd send signals to the IoT device to stop the broadcast of packets using a = front door specially designed for this purpose and supported by the TEEP pr= otocol. This new actor was discussed during the last meeting in London and = it was not decided to add such an entity. I would like to recommend to incl= ude such an entity and provision it in the architecture design. This can be the entity that can judge the transmission of malicious packets= that will start or be a part of a DDoS attack triggered by an innocent le= gitimate SW, be it trusted and legit. So my proposal is to include the new player Security Provider as well as pr= ovisioning TEEP to allow front door signals sent to the TEE of the IoT to a= llow stopping DDoS attacks. ./Sorin From: TEEP [mailto:teep-bounces@ietf.org] On Behalf Of Dave Thaler Sent: Friday, March 16, 2018 3:38 PM To: teep Cc: teep-chairs@ietf.org Subject: [Teep] IETF 101 agenda requests Please send your requests for time on the TEEP WG agenda for IETF 101 as so= on as possible, to teep-chairs@ietf.org. Priority will be given to topics that have already had mailing discussion a= nd are targeted for items listed in charter milestones. Please also send slides by Sunday March 18th. Thanks, Dave --_000_2313358402DBCC4DB2F2DC03CB08BBFEFF050AMX304CL01corpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

New proposed usecase for TEEP WG.

 

Most recently the frequency and intensity of DDoS attacks from IoT d= evices increased with attacks almost every day. The reason of the prolifera= tion of DDoS attacks from IoT devices is a result of the lower and maybe inexistent security protection of cheap IoT devices= that have no security features implemented as this would increase the cost= of such devices using any security HW. In the current charter of TEEP ther= e sre 3 usecases and I would like to add the protectioin against DDoS of IoT as a new usecase:

1.     &= nbsp; Payment

2.     &= nbsp; IoT to allow authorized code access

3.     &= nbsp; Confidential cloud computing

 

All the above usecases are only addressing the safety of the operati= on/execution of code on the devices. My new usecase is addressing the outgo= ing data/communication between the IoT device and the cloud provider that is collecting the data from the device. As it = is implemented right now there is no protocol allowing protection against m= alicious data packets that are sent by the device by the SW running inside = the protected area that passed all the security requirements of all the security players:

Developers, chip vendor, OEM vendor and TAM that are= responsible for:

-       = ;   IoT Device

-       = ;   Trusted Application

-       = ;   Rich Application author

-       = ;   TEE chip vendor

-       = ;   Device OEM

 

We want to focus the new usecase on IoT devices l= acking rich execution environment that are mostly innocent generators of DD= oS traffic that was implemented in the trusted SW or in the device HW durin= g the design allowing backdoors for the DDoS attackers. TEE should have provisioning for preventing undesired = packets to be broadcasted to the network. As these devices use inexpensive = HW they have no protection against the outgoing traffic even if it is encry= pted, or perhaps although it is encrypted, to prevent malicious data packets to be broadcasted.=

 

Moreover there is also a need to protect against = signaling sent to the device by attackers that controls the attack timing a= nd duration using legitimate data packets. One way TEEP protocol can protec= t against this type of attacks is to use a “Security Provider” entity that will detect such atta= cks and send signals to the IoT device to stop the broadcast of packets usi= ng a front door specially designed for this purpose and supported by the TE= EP protocol. This new actor was discussed during the last meeting in London and it was not decided to add such an entity. I= would like to recommend to include such an entity and provision it in the = architecture design.

 

This can be the entity that can judge the transmi= ssion of malicious packets that will start or be a part of a DDoS attack&nb= sp; triggered by an innocent legitimate SW, be it trusted and legit.

 

So my proposal is to include the new player Secur= ity Provider as well as provisioning TEEP to allow front door signals sent = to the TEE of the IoT to allow stopping DDoS attacks.

 

./Sorin

 

From: TEEP [mailto:teep-bounces@ietf= .org] On Behalf Of Dave Thaler
Sent: Friday, March 16, 2018 3:38 PM
To: teep <teep@ietf.org>
Cc: teep-chairs@ietf.org
Subject: [Teep] IETF 101 agenda requests

 

Please send your requests for time on the TEEP WG ag= enda for IETF 101 as soon as possible, to teep-chairs@ietf.org.

Priority will be given to topics that have already h= ad mailing discussion and are targeted for items listed in charter mileston= es.

 

Please also send slides by Sunday March 18th.

 

Thanks,

Dave

--_000_2313358402DBCC4DB2F2DC03CB08BBFEFF050AMX304CL01corpemcc_-- From nobody Fri Mar 23 05:39:49 2018 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273D812D887; Fri, 23 Mar 2018 05:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9o77zNhba3EO; Fri, 23 Mar 2018 05:39:38 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 AC0BF12D940; Fri, 23 Mar 2018 05:39:33 -0700 (PDT) X-AuditID: 12074425-453ff70000003dfb-34-5ab4f582fd0e Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id CE.05.15867.385F4BA5; Fri, 23 Mar 2018 08:39:31 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w2NCdTZs015068; Fri, 23 Mar 2018 08:39:30 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w2NCdPum021612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Mar 2018 08:39:28 -0400 Date: Fri, 23 Mar 2018 07:39:25 -0500 From: Benjamin Kaduk To: "faibish, sorin" Cc: Dave Thaler , teep , "teep-chairs@ietf.org" Message-ID: <20180323123925.GD25919@kduck.kaduk.org> References: <2313358402DBCC4DB2F2DC03CB08BBFEFF050A@MX304CL01.corp.emc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2313358402DBCC4DB2F2DC03CB08BBFEFF050A@MX304CL01.corp.emc.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IR4hTV1m3+uiXKoGuFkcWlFUdYLQ5tXcti 8WXGHxaLpX++MTuweEyaOYPZY8mSn0werTv+sgcwR3HZpKTmZJalFunbJXBlfG9cxVbQw1bR fOsKawPje5YuRg4OCQETidkPeLsYuTiEBBYzSSz4tIYRwtnIKNG4ZyIrhHOVSeLrsZvsXYyc HCwCqhINt68ygthsAioSDd2XmUFsEQFdiW0XzjKB2MwCpRLLbtxhBbGFBXQkps6cAWbzAm17 tvgHC4gtJDCPUWLfPC+IuKDEyZlPWCB6tSRu/HvJBHIds4C0xPJ/HCBhTgEfiY8XToOViAoo S+ztO8Q+gVFgFpLuWUi6ZyF0L2BkXsUom5JbpZubmJlTnJqsW5ycmJeXWqRroZebWaKXmlK6 iREUwuwuqjsY5/z1OsQowMGoxMM749DmKCHWxLLiytxDjJIcTEqivJnHt0QJ8SXlp1RmJBZn xBeV5qQWH2KU4GBWEuG1eAmU401JrKxKLcqHSUlzsCiJ83qYaEcJCaQnlqRmp6YWpBbBZGU4 OJQkeO9/AWoULEpNT61Iy8wpQUgzcXCCDOcBGr4FpIa3uCAxtzgzHSJ/itGYo23lkzZmjhsv XrcxC7Hk5eelSonzVoOUCoCUZpTmwU0DpSGJ7P01rxjFgZ4T5r0BUsUDTGFw814BrWICWuUz BWxVSSJCSqqBcabihqU7VbfFvxXtnj75d3bvastg67qHTFMsZr9P8FtWvcv2T5XDdTeudvu2 TaHxHBI+qxMlFhy8GOJv8XC38gUmgw1186Sutf8VuuNRHF4ws9PrG+de/xsTLO1DpgQLTPl/ 90O8TmaMx86z0c9ZP8eq15d+SGg13PbYypLFquJyUXOtedpqJZbijERDLeai4kQAUxSJ4R4D AAA= Archived-At: Subject: Re: [Teep] IETF 101 agenda requests X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 12:39:48 -0000 Hi Sorin, On Thu, Mar 22, 2018 at 09:26:22AM +0000, faibish, sorin wrote: > New proposed usecase for TEEP WG. > > Most recently the frequency and intensity of DDoS attacks from IoT devices increased with attacks almost every day. The reason of the proliferation of DDoS attacks from IoT devices is a result of the lower and maybe inexistent security protection of cheap IoT devices that have no security features implemented as this would increase the cost of such devices using any security HW. In the current charter of TEEP there sre 3 usecases and I would like to add the protectioin against DDoS of IoT as a new usecase: On a quick read of the charter, I don't see how this topic would be in scope -- am I missing something that would allow it? Thanks, Ben From nobody Mon Mar 26 16:12:53 2018 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABDB1277BB; Mon, 26 Mar 2018 16:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=pSLQcFEs; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=NQQCdouj 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 84HDipzv2Z19; Mon, 26 Mar 2018 16:12:50 -0700 (PDT) Received: from esa1.dell-outbound.iphmx.com (esa1.dell-outbound.iphmx.com [68.232.153.90]) (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 B9A11126C25; Mon, 26 Mar 2018 16:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1522105399; x=1553641399; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=obxj3eWG3oT9+MnzYWG7O6rBDLkMjfP25G7qrwJsYlo=; b=pSLQcFEss05ViYIf8gFqGyfQRng8ka4rTXCQx00v+eUTDpl5T4yPrRVk 1eWRSzgcQU7bxPNFeyLYJm2KgEnzd9csjQna14UqnKVzn2jUs0nGwbv0t vUyzFJpt12SB+wOn8lh4oMU1azj/CJdpDDXRPuo9/cVBf30N6Yx7S/NEG M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GUAABVfblah8mZ6ERdDgwBAQEBAQIBA?= =?us-ascii?q?QEBCAEBAQGCbyMEfg5wKAqYZIF0dRyUGj0LHg6EWQKDfSE4FAECAQEBAQEBAgE?= =?us-ascii?q?CEAEBAQoLCQgoIwyCOCQBDkshCDIBAQEBAQEBAQEBAQEBAQEBAQEXAj0BEgIYA?= =?us-ascii?q?QEBBDoGOQELBAIBCBEEAQEBChQJBzIUCQgBAQQOBQgThHMBDq5ygneFTIIPAwW?= =?us-ascii?q?FPoEUDHqBVECBDIJTNIFBgVICA4Fdgy+CJJdCCAKFUIoPhjKEV4kThjwCBAIEB?= =?us-ascii?q?QIUgSUzgWAMCHCDEoIvgQUBCIJChROFBDpvjmOBFwEB?= X-IPAS-Result: =?us-ascii?q?A2GUAABVfblah8mZ6ERdDgwBAQEBAQIBAQEBCAEBAQGCbyM?= =?us-ascii?q?Efg5wKAqYZIF0dRyUGj0LHg6EWQKDfSE4FAECAQEBAQEBAgECEAEBAQoLCQgoI?= =?us-ascii?q?wyCOCQBDkshCDIBAQEBAQEBAQEBAQEBAQEBAQEXAj0BEgIYAQEBBDoGOQELBAI?= =?us-ascii?q?BCBEEAQEBChQJBzIUCQgBAQQOBQgThHMBDq5ygneFTIIPAwWFPoEUDHqBVECBD?= =?us-ascii?q?IJTNIFBgVICA4Fdgy+CJJdCCAKFUIoPhjKEV4kThjwCBAIEBQIUgSUzgWAMCHC?= =?us-ascii?q?DEoIvgQUBCIJChROFBDpvjmOBFwEB?= Received: from esa1.dell-outbound2.iphmx.com ([68.232.153.201]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Mar 2018 18:03:18 -0500 From: "faibish, sorin" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa1.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2018 05:03:15 +0600 Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w2QNCjoM018876 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Mar 2018 19:12:48 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com w2QNCjoM018876 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1522105968; bh=93HR0XVgMc9W7QTH2FywOVQVRaM=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=NQQCdoujqOmJ7CL8QuXpTjkwJmZk5NqQsqn++ih5fEIZrMv79oXtzdDYWw6Ea/Eqe Xp6NOrwoZzxD4sWJa7Gkiy6hO2CxPZGtsXMjfX1j6VyLzJxrlrTprE+y47vgg5jwSj hvgTQEZMB8Wydo7GUNqQz1qbOdGHr7E/Hn/IxRvg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com w2QNCjoM018876 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd55.lss.emc.com (RSA Interceptor); Mon, 26 Mar 2018 19:12:37 -0400 Received: from MXHUB320.corp.emc.com (MXHUB320.corp.emc.com [10.146.3.98]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w2QNCZ9B000357 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 26 Mar 2018 19:12:38 -0400 Received: from MX304CL01.corp.emc.com ([fe80::2d21:ebf8:dc15:2b07]) by MXHUB320.corp.emc.com ([10.146.3.98]) with mapi id 14.03.0382.000; Mon, 26 Mar 2018 19:12:37 -0400 To: Benjamin Kaduk CC: Dave Thaler , teep , "teep-chairs@ietf.org" Thread-Topic: [Teep] IETF 101 agenda requests Thread-Index: AdO9Xdcov18dMzNFTtSIcGlRK17eigEYdluQAEF0EYAApIpjUA== Date: Mon, 26 Mar 2018 23:12:37 +0000 Message-ID: <2313358402DBCC4DB2F2DC03CB08BBFE0100C5FE@MX304CL01.corp.emc.com> References: <2313358402DBCC4DB2F2DC03CB08BBFEFF050A@MX304CL01.corp.emc.com> <20180323123925.GD25919@kduck.kaduk.org> In-Reply-To: <20180323123925.GD25919@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.252.59.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [Teep] IETF 101 agenda requests X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2018 23:12:53 -0000 We discussed the DDoS in Singapore and we had a presentation on the DDoS: https://datatracker.ietf.org/meeting/100/materials/slides-100-saag-inter-do= main-ddos-mitigations-potentials-challenges-and-solutions-min-suk-kang/ So, I would like to include this usecase as a target for the WG. I will wri= te a draft related to this usecase. Thanks ./Sorin=20 -----Original Message----- From: Benjamin Kaduk [mailto:kaduk@mit.edu]=20 Sent: Friday, March 23, 2018 8:39 AM To: faibish, sorin Cc: Dave Thaler ; teep ; teep-chairs@= ietf.org Subject: Re: [Teep] IETF 101 agenda requests Hi Sorin, On Thu, Mar 22, 2018 at 09:26:22AM +0000, faibish, sorin wrote: > New proposed usecase for TEEP WG. >=20 > Most recently the frequency and intensity of DDoS attacks from IoT device= s increased with attacks almost every day. The reason of the proliferation = of DDoS attacks from IoT devices is a result of the lower and maybe inexist= ent security protection of cheap IoT devices that have no security features= implemented as this would increase the cost of such devices using any secu= rity HW. In the current charter of TEEP there sre 3 usecases and I would li= ke to add the protectioin against DDoS of IoT as a new usecase: On a quick read of the charter, I don't see how this topic would be in scop= e -- am I missing something that would allow it? Thanks, Ben From nobody Mon Mar 26 18:33:15 2018 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CED128D2E; Mon, 26 Mar 2018 18:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 D4Ng2LANTgSf; Mon, 26 Mar 2018 18:33:12 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 2D602126DC2; Mon, 26 Mar 2018 18:33:12 -0700 (PDT) X-AuditID: 12074423-e51ff700000027e6-39-5ab99f5450d4 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 62.F4.10214.55F99BA5; Mon, 26 Mar 2018 21:33:10 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w2R1X5Oo012197; Mon, 26 Mar 2018 21:33:06 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w2R1X1Lt023104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Mar 2018 21:33:03 -0400 Date: Mon, 26 Mar 2018 20:33:01 -0500 From: Benjamin Kaduk To: "faibish, sorin" Cc: teep , Dave Thaler , "teep-chairs@ietf.org" Message-ID: <20180327013301.GN44086@kduck.kaduk.org> References: <2313358402DBCC4DB2F2DC03CB08BBFEFF050A@MX304CL01.corp.emc.com> <20180323123925.GD25919@kduck.kaduk.org> <2313358402DBCC4DB2F2DC03CB08BBFE0100C5FE@MX304CL01.corp.emc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2313358402DBCC4DB2F2DC03CB08BBFE0100C5FE@MX304CL01.corp.emc.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42IRYrdT0Q2bvzPK4GCTusWlFUdYLQ5tXcti 8WXGHxaLpX++MTuweEyaOYPZY8mSn0werTv+sgcwR3HZpKTmZJalFunbJXBlvOtvYS94z1fR 8+IWYwPjFJ4uRk4OCQETiWXrljB2MXJxCAksZpLY+PYBO4SzkVHi2NdPzBDOVSaJR2+uM4K0 sAioSuzt72ECsdkEVCQaui8zg9giAroS2y6cBYszC5RK7Nx8DywuLKAjMXXmDFYQmxdo3fE9 K6CG9jJJfL53hQUiIShxcuYTFohmLYkb/14CDeIAsqUllv/jAAlzCvhJvP3zkw3EFhVQltjb d4h9AqPALCTds5B0z0LoXsDIvIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXTC83s0QvNaV0EyM4 jF2UdzC+7PM+xCjAwajEw+vAtjNKiDWxrLgy9xCjJAeTkihvlTxQiC8pP6UyI7E4I76oNCe1 +BCjBAezkggv3/wdUUK8KYmVValF+TApaQ4WJXFeDxPtKCGB9MSS1OzU1ILUIpisDAeHkgRv yTygoYJFqempFWmZOSUIaSYOTpDhPEDDC0BqeIsLEnOLM9Mh8qcYdTluvHjdxizEkpeflyol zmsMUiQAUpRRmgc3B5R+JLL317xiFAd6S5jXFKSKB5i64Ca9AlrCBLRkWxPIB8UliQgpqQZG hisRquuUv9o0f1+5raz6vvyXfYsNl9976X/o+f1kYdGjfxqUPA7why04deDlF3H7S3eOJq2X CizX8GFe/fu0QaxG6J/5Cr5sDqqhSx6cUNkT4qO8jHfRhXW3z8+ViWpnEbTMfOvQZbTEsZ8r /lh1rlvL6/mS66e7PGhw4op9LRfZ7mL8du9bJZbijERDLeai4kQA6q9YThoDAAA= Archived-At: Subject: Re: [Teep] IETF 101 agenda requests X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 01:33:14 -0000 On Mon, Mar 26, 2018 at 11:12:37PM +0000, faibish, sorin wrote: > We discussed the DDoS in Singapore and we had a presentation on the DDoS: > https://datatracker.ietf.org/meeting/100/materials/slides-100-saag-inter-domain-ddos-mitigations-potentials-challenges-and-solutions-min-suk-kang/ > > So, I would like to include this usecase as a target for the WG. I will write a draft related to this usecase. Thanks Wanting it to be a target and writing a draft are both orthogonal to the question of whether the work is in-charter. (Rechartering to include it would of course be possible, through the normal procedure...) -Ben > ../Sorin > > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > Sent: Friday, March 23, 2018 8:39 AM > To: faibish, sorin > Cc: Dave Thaler ; teep ; teep-chairs@ietf.org > Subject: Re: [Teep] IETF 101 agenda requests > > Hi Sorin, > > On Thu, Mar 22, 2018 at 09:26:22AM +0000, faibish, sorin wrote: > > New proposed usecase for TEEP WG. > > > > Most recently the frequency and intensity of DDoS attacks from IoT devices increased with attacks almost every day. The reason of the proliferation of DDoS attacks from IoT devices is a result of the lower and maybe inexistent security protection of cheap IoT devices that have no security features implemented as this would increase the cost of such devices using any security HW. In the current charter of TEEP there sre 3 usecases and I would like to add the protectioin against DDoS of IoT as a new usecase: > > On a quick read of the charter, I don't see how this topic would be in scope -- am I missing something that would allow it? > > Thanks, > > Ben > > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > https://www.ietf.org/mailman/listinfo/teep From nobody Tue Mar 27 08:43:59 2018 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91CE12DA6A; Tue, 27 Mar 2018 08:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 w4I7d21rWg86; Tue, 27 Mar 2018 08:43:55 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 C540612DA51; Tue, 27 Mar 2018 08:43:55 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2018 08:43:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,367,1517904000"; d="scan'208";a="27962163" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga008.fm.intel.com with ESMTP; 27 Mar 2018 08:43:54 -0700 Received: from fmsmsx115.amr.corp.intel.com (10.18.116.19) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 27 Mar 2018 08:43:54 -0700 Received: from crsmsx101.amr.corp.intel.com (172.18.63.136) by fmsmsx115.amr.corp.intel.com (10.18.116.19) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 27 Mar 2018 08:43:54 -0700 Received: from crsmsx102.amr.corp.intel.com ([169.254.2.248]) by CRSMSX101.amr.corp.intel.com ([169.254.1.143]) with mapi id 14.03.0319.002; Tue, 27 Mar 2018 09:43:52 -0600 From: "Wheeler, David M" To: Benjamin Kaduk , "faibish, sorin" CC: teep , Dave Thaler , "teep-chairs@ietf.org" Thread-Topic: [Teep] IETF 101 agenda requests Thread-Index: AdO9Xdcov18dMzNFTtSIcGlRK17eigEYdluQAEWk84AArP0PgAAE50aAABCON7A= Date: Tue, 27 Mar 2018 15:43:52 +0000 Message-ID: <0627F5240443D2498FAA65332EE46C84367A64B7@CRSMSX102.amr.corp.intel.com> References: <2313358402DBCC4DB2F2DC03CB08BBFEFF050A@MX304CL01.corp.emc.com> <20180323123925.GD25919@kduck.kaduk.org> <2313358402DBCC4DB2F2DC03CB08BBFE0100C5FE@MX304CL01.corp.emc.com> <20180327013301.GN44086@kduck.kaduk.org> In-Reply-To: <20180327013301.GN44086@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTJiNmZiMjktZjQwYy00Y2U4LWI3ZmQtODk3Y2M0YmU5ZmViIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6Ind5UURCdCtSMTFOVVByM3pQbFlCbXJMR0VOdFFPT2ZkNFlVQlBrZjlnVVk9In0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [172.18.205.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Teep] IETF 101 agenda requests X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 15:43:58 -0000 Ben, I agree with you regarding the question of charter, however, I think (pleas= e correct if I misunderstand) what Sorin is proposing is to use the DDoS ex= ample as a use case to evaluate if OTrP has considered the appropriate rela= tionships and entities within the protocol that would allow the proposed DD= oS solution to be implemented. Our charter does state that "the solution approach must take a wide range o= f TEE and relevant technologies" and the architecture document includes "re= levant use cases." Since the DDoS proposal includes an implementation where= a TEE application implements a set of filtering policies, I believe it is = relevant. I think it is a very interesting use case, since it expands beyond a simple= Device-User to Service-Provider situation, and creates a more complex inte= raction for the application - especially the interaction of the trusted app= lication to aspects of the device itself (i.e. filtering outgoing packets).= Is our policy for accepting TEE applications rich enough (or at least exte= nsible enough) to enable a device/user to implement controls on what applic= ations are allowed to do, perhaps even based on the service provider instal= ling those applications. I believe it is in our best interest to evaluate it, and the implications o= f such TEE applications. We can still come to the conclusion that some aspe= cts of supporting such a use case may be out-of-scope, but it will give us = concrete information to point to regarding what is exactly out-of-scope, wh= y it breeches our scope, and perhaps direct future additions/expansions to = the protocol. Thanks, Dave Wheeler -----Original Message----- From: TEEP [mailto:teep-bounces@ietf.org] On Behalf Of Benjamin Kaduk Sent: Monday, March 26, 2018 6:33 PM To: faibish, sorin Cc: teep ; Dave Thaler ; teep-chairs@= ietf.org Subject: Re: [Teep] IETF 101 agenda requests On Mon, Mar 26, 2018 at 11:12:37PM +0000, faibish, sorin wrote: > We discussed the DDoS in Singapore and we had a presentation on the DDoS: > https://datatracker.ietf.org/meeting/100/materials/slides-100-saag-int > er-domain-ddos-mitigations-potentials-challenges-and-solutions-min-suk > -kang/ >=20 > So, I would like to include this usecase as a target for the WG. I=20 > will write a draft related to this usecase. Thanks Wanting it to be a target and writing a draft are both orthogonal to the qu= estion of whether the work is in-charter. (Rechartering to include it woul= d of course be possible, through the normal procedure...) -Ben > ../Sorin >=20 > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > Sent: Friday, March 23, 2018 8:39 AM > To: faibish, sorin > Cc: Dave Thaler ; teep ;=20 > teep-chairs@ietf.org > Subject: Re: [Teep] IETF 101 agenda requests >=20 > Hi Sorin, >=20 > On Thu, Mar 22, 2018 at 09:26:22AM +0000, faibish, sorin wrote: > > New proposed usecase for TEEP WG. > >=20 > > Most recently the frequency and intensity of DDoS attacks from IoT devi= ces increased with attacks almost every day. The reason of the proliferatio= n of DDoS attacks from IoT devices is a result of the lower and maybe inexi= stent security protection of cheap IoT devices that have no security featur= es implemented as this would increase the cost of such devices using any se= curity HW. In the current charter of TEEP there sre 3 usecases and I would = like to add the protectioin against DDoS of IoT as a new usecase: >=20 > On a quick read of the charter, I don't see how this topic would be in sc= ope -- am I missing something that would allow it? >=20 > Thanks, >=20 > Ben >=20 > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > https://www.ietf.org/mailman/listinfo/teep _______________________________________________ TEEP mailing list TEEP@ietf.org https://www.ietf.org/mailman/listinfo/teep From nobody Tue Mar 27 09:33:48 2018 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B47012D77A; Tue, 27 Mar 2018 09:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 PyPfpLvf3KSA; Tue, 27 Mar 2018 09:33:43 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0123.outbound.protection.outlook.com [104.47.40.123]) (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 9D1FA127863; Tue, 27 Mar 2018 09:33:43 -0700 (PDT) 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=PNRcUQfVQKfPFEXS1+VqAcxqTXpl/9NQdYWGlXfcwhc=; b=FOyJS0D5jrye1naRcZmyoBVZG/le1NcUwDFdmQobb0bsuDK+A+ei5zrwZkdPUuCm1YAh6Ta1Nwjg6zgLgdCJVv9cjEvul6rt8cGn+aywfUo8InaJbCIumWzP+9ufgGiodVfwoCxrb3NZeJHKllmCsU3IUA3YN8D93sKTg4B1gEw= Received: from CY4PR21MB0774.namprd21.prod.outlook.com (10.173.192.20) by CY4PR21MB0151.namprd21.prod.outlook.com (10.173.189.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.0; Tue, 27 Mar 2018 16:33:41 +0000 Received: from CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::41f5:f274:8793:f7b1]) by CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::41f5:f274:8793:f7b1%8]) with mapi id 15.20.0653.002; Tue, 27 Mar 2018 16:33:41 +0000 From: Dave Thaler To: "Wheeler, David M" , Benjamin Kaduk , "faibish, sorin" CC: teep , "teep-chairs@ietf.org" Thread-Topic: [Teep] IETF 101 agenda requests Thread-Index: AdO9Xdcov18dMzNFTtSIcGlRK17eigEYdluQADkSTYAArP0PgAAE50aAAB23MQAAAJWuwA== Date: Tue, 27 Mar 2018 16:33:41 +0000 Message-ID: References: <2313358402DBCC4DB2F2DC03CB08BBFEFF050A@MX304CL01.corp.emc.com> <20180323123925.GD25919@kduck.kaduk.org> <2313358402DBCC4DB2F2DC03CB08BBFE0100C5FE@MX304CL01.corp.emc.com> <20180327013301.GN44086@kduck.kaduk.org> <0627F5240443D2498FAA65332EE46C84367A64B7@CRSMSX102.amr.corp.intel.com> In-Reply-To: <0627F5240443D2498FAA65332EE46C84367A64B7@CRSMSX102.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-03-27T16:33:40.2818318Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [73.59.106.235] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0151; 7:i6Rk0kOvXBfkzTkR+PkOnDEQW+J5ydtcggSmanZmHdmo0628s9CQKRfJNYmyLlzVOPLJsq19aeeOZiXhLFTHV9biblkVQ8DQmpmSP7OMaxYkvyjT2n9KGVyz1+4DIrq8AB5lBHm9v4NqKIYALT8GHHUg6bke4rN5dmQmQ7XB1Pg6q9Z7Miyxf3oHcgW0Mt4GdIuUCW9w+PnyPFrkw3D/Ug+mCdW0L2rQOTq6jfhsLc4sfXeDOmNauRpUK9+kfW2a; 20:h3I0C/LPydzwfyMZM4z9VISjbMUUD9INKUV3+DsMbZN+Qj7DkgwJlcpOrziY0u3skH4vPGDP/1aPMEFsOVeOkYK7toCmNhmBHdOYi8R0D0MvCGDoRZTsj46VdXfTcyb2MHN9WXHsWO4fiwVLzj4QasfaK7Tdjuosb+uy+DgtHE8= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 30d44dab-4a7b-4708-fbbe-08d594008038 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY4PR21MB0151; x-ms-traffictypediagnostic: CY4PR21MB0151: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(278428928389397)(89211679590171)(192374486261705)(189930954265078)(219752817060721)(240460790083961)(56004941905204)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041310)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR21MB0151; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0151; x-forefront-prvs: 0624A2429E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(376002)(39860400002)(396003)(346002)(189003)(199004)(13464003)(3846002)(53936002)(6116002)(105586002)(102836004)(5660300001)(106356001)(7696005)(33656002)(86612001)(81166006)(25786009)(561944003)(2906002)(59450400001)(81156014)(8676002)(4326008)(3280700002)(6506007)(76176011)(97736004)(53546011)(10290500003)(6246003)(3660700001)(8936002)(486005)(22452003)(446003)(6436002)(11346002)(229853002)(99286004)(486005)(10090500001)(476003)(9686003)(6306002)(74316002)(316002)(110136005)(66066001)(5250100002)(478600001)(966005)(14454004)(54906003)(8990500004)(8666007)(305945005)(93886005)(55016002)(7736002)(186003)(2171002)(86362001)(68736007)(575784001)(26005)(2900100001)(6346003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0151; H:CY4PR21MB0774.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-microsoft-antispam-message-info: QStSUffKeo9LUycpDSDibdNmWKH+zOowitqLFIg+722iw6WXxD13nBCaQpAuW0lalCUdIvAYFxnfY/GVkZCjNJ++qFlT/WrMkpiC37+sUc7NJrRJae374toBE0QBisdYMneXzrxKe8Dx/4zSN9RSdetil/XtOtm5Jl5aWtQkt0FpwA2E4pt/W9GMCTSvZKu02PqwqXp2GYw35pHw7KN8GUluuotwxnVA5oxBa+hATwCJCMcGAU4ROAN7oz0Q16QdnarAtSzeyQ1kttKvULJ6Wf2R5tnTwoLrj3QOCA9bk2yZDJ5Pz3SmBMXBZbJYICQSDlP0gb9N+X769EJRtNn3+g== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 30d44dab-4a7b-4708-fbbe-08d594008038 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2018 16:33:41.3450 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0151 Archived-At: Subject: Re: [Teep] IETF 101 agenda requests X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 16:33:47 -0000 On slide 6 of the "Problem Statement" slides there were three use cases for= Trusted Applications (as opposed to use cases for OTrP or TEEP per se), of which one was IoT.=20 The Mirai botnet attack used the REE (not a TEE) of devices to conduct atta= cks against an external entity. Since TEEP is about TEE provisioning, not REE provisioning, TEEP is not directly = applicable to controlling how/whether malware can be installed in the REE. I think what David's saying is that a provisioned TEE application could hav= e functionality to detect/mitigate something malicious that it detects an REE app is doing. That's true, just like the = TEE application could do anything else (compute pi, etc.) but we shouldn't try to enumerate every operation that a= TEE application might try to do, just=20 things that introduce requirements on OTrP. In the "TEEP Use Cases" slides for IETF 101, these are use cases for OTrP (= as opposed to use cases for Trusted Apps in general). In the discussion around slide 6, we agreed that Rich Apps are largely orth= ogonal because they don't introduce new requirements on the OTrP protocol. I think Ben's saying this is simil= arly orthogonal. For it to not be orthogonal, one would have to argue how/why it affects the= OTrP protocol itself. If there is such an argument, that would be a good way to continue this discussion. If not,= or if we don't know if there is, then it's orthogonal until such an argument is provided. Dave -----Original Message----- From: Wheeler, David M =20 Sent: Tuesday, March 27, 2018 8:44 AM To: Benjamin Kaduk ; faibish, sorin Cc: teep ; Dave Thaler ; teep-chairs@= ietf.org Subject: RE: [Teep] IETF 101 agenda requests Ben, I agree with you regarding the question of charter, however, I think (pleas= e correct if I misunderstand) what Sorin is proposing is to use the DDoS ex= ample as a use case to evaluate if OTrP has considered the appropriate rela= tionships and entities within the protocol that would allow the proposed DD= oS solution to be implemented. Our charter does state that "the solution approach must take a wide range o= f TEE and relevant technologies" and the architecture document includes "re= levant use cases." Since the DDoS proposal includes an implementation where= a TEE application implements a set of filtering policies, I believe it is = relevant. I think it is a very interesting use case, since it expands beyond a simple= Device-User to Service-Provider situation, and creates a more complex inte= raction for the application - especially the interaction of the trusted app= lication to aspects of the device itself (i.e. filtering outgoing packets).= Is our policy for accepting TEE applications rich enough (or at least exte= nsible enough) to enable a device/user to implement controls on what applic= ations are allowed to do, perhaps even based on the service provider instal= ling those applications. I believe it is in our best interest to evaluate it, and the implications o= f such TEE applications. We can still come to the conclusion that some aspe= cts of supporting such a use case may be out-of-scope, but it will give us = concrete information to point to regarding what is exactly out-of-scope, wh= y it breeches our scope, and perhaps direct future additions/expansions to = the protocol. Thanks, Dave Wheeler -----Original Message----- From: TEEP [mailto:teep-bounces@ietf.org] On Behalf Of Benjamin Kaduk Sent: Monday, March 26, 2018 6:33 PM To: faibish, sorin Cc: teep ; Dave Thaler ; teep-chairs@= ietf.org Subject: Re: [Teep] IETF 101 agenda requests On Mon, Mar 26, 2018 at 11:12:37PM +0000, faibish, sorin wrote: > We discussed the DDoS in Singapore and we had a presentation on the DDoS: > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat > racker.ietf.org%2Fmeeting%2F100%2Fmaterials%2Fslides-100-saag-int&data > =3D02%7C01%7Cdthaler%40microsoft.com%7C105f96f6b0744e2a276408d593f98cc2% > 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636577622384270342&sdata=3D > 32qt5mT4aXYjJ9gZW%2BFRegXm4GbM%2FWlOpwh6XmnJ84I%3D&reserved=3D0 > er-domain-ddos-mitigations-potentials-challenges-and-solutions-min-suk > -kang/ >=20 > So, I would like to include this usecase as a target for the WG. I=20 > will write a draft related to this usecase. Thanks Wanting it to be a target and writing a draft are both orthogonal to the qu= estion of whether the work is in-charter. (Rechartering to include it woul= d of course be possible, through the normal procedure...) -Ben > ../Sorin >=20 > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > Sent: Friday, March 23, 2018 8:39 AM > To: faibish, sorin > Cc: Dave Thaler ; teep ;=20 > teep-chairs@ietf.org > Subject: Re: [Teep] IETF 101 agenda requests >=20 > Hi Sorin, >=20 > On Thu, Mar 22, 2018 at 09:26:22AM +0000, faibish, sorin wrote: > > New proposed usecase for TEEP WG. > >=20 > > Most recently the frequency and intensity of DDoS attacks from IoT devi= ces increased with attacks almost every day. The reason of the proliferatio= n of DDoS attacks from IoT devices is a result of the lower and maybe inexi= stent security protection of cheap IoT devices that have no security featur= es implemented as this would increase the cost of such devices using any se= curity HW. In the current charter of TEEP there sre 3 usecases and I would = like to add the protectioin against DDoS of IoT as a new usecase: >=20 > On a quick read of the charter, I don't see how this topic would be in sc= ope -- am I missing something that would allow it? >=20 > Thanks, >=20 > Ben >=20 > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i > etf.org%2Fmailman%2Flistinfo%2Fteep&data=3D02%7C01%7Cdthaler%40microsoft > .com%7C105f96f6b0744e2a276408d593f98cc2%7C72f988bf86f141af91ab2d7cd011 > db47%7C1%7C0%7C636577622384270342&sdata=3D1F4dZBFAumiRdEl7G4FYn0bO9VSzFy > k%2BSkxW6cCfesw%3D&reserved=3D0 _______________________________________________ TEEP mailing list TEEP@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fteep&data=3D02%7C01%7Cdthaler%40microsoft.com%7= C105f96f6b0744e2a276408d593f98cc2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C= 0%7C636577622384270342&sdata=3D1F4dZBFAumiRdEl7G4FYn0bO9VSzFyk%2BSkxW6cCfes= w%3D&reserved=3D0 From nobody Tue Mar 27 10:37:22 2018 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7667F12D887; Tue, 27 Mar 2018 10:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 LwbdQUNN74Os; Tue, 27 Mar 2018 10:37:18 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (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 70E8812D7F7; Tue, 27 Mar 2018 10:37:18 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2018 10:37:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,367,1517904000"; d="scan'208";a="45753767" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga002.jf.intel.com with ESMTP; 27 Mar 2018 10:37:17 -0700 Received: from fmsmsx101.amr.corp.intel.com (10.18.124.199) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 27 Mar 2018 10:37:17 -0700 Received: from crsmsx152.amr.corp.intel.com (172.18.7.35) by fmsmsx101.amr.corp.intel.com (10.18.124.199) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 27 Mar 2018 10:37:16 -0700 Received: from crsmsx102.amr.corp.intel.com ([169.254.2.248]) by CRSMSX152.amr.corp.intel.com ([169.254.5.72]) with mapi id 14.03.0319.002; Tue, 27 Mar 2018 11:37:15 -0600 From: "Wheeler, David M" To: Dave Thaler , Benjamin Kaduk , "faibish, sorin" CC: teep , "teep-chairs@ietf.org" Thread-Topic: [Teep] IETF 101 agenda requests Thread-Index: AdO9Xdcov18dMzNFTtSIcGlRK17eigEYdluQAEWk84AArP0PgAAE50aAABCON7AADuZggAALj1sQ Date: Tue, 27 Mar 2018 17:37:14 +0000 Message-ID: <0627F5240443D2498FAA65332EE46C84367A6598@CRSMSX102.amr.corp.intel.com> References: <2313358402DBCC4DB2F2DC03CB08BBFEFF050A@MX304CL01.corp.emc.com> <20180323123925.GD25919@kduck.kaduk.org> <2313358402DBCC4DB2F2DC03CB08BBFE0100C5FE@MX304CL01.corp.emc.com> <20180327013301.GN44086@kduck.kaduk.org> <0627F5240443D2498FAA65332EE46C84367A64B7@CRSMSX102.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNmRlM2RhZGItZWNkOC00Y2E2LWI0ODMtZDI0ZmI4ZTU0NmJhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IkV2TFYydVFFV1lPZXFYdGp6T0ZaZktiMFlzRVpDTEp2TlBVZG9qTzhYWjA9In0= dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [172.18.205.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Teep] IETF 101 agenda requests X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 17:37:22 -0000 > For it to not be orthogonal, one would have to argue how/why it affects t= he OTrP protocol itself. =20 OK, let me try to present the argument :) A TEE application, when provisioned into a device, will require certain res= ources of the device. These resources will definitely include storage, RAM, and possibly some mea= sure of CPU time. OTrP //should// have some policy hooks that allow a device/device user/owne= r to define what are acceptable limits of resource consumption for a TEE ap= plication. For example, as long as a TEE app consumes less than 100MB RAM, = it is OK to install (perhaps because I only have 250MB allocated to the TEE= , and I don't want ALL the memory consumed by one app). This policy should be attached to the TEE application at install time, be i= nterpreted by the OTrP Agent, and be evaluated as an intersection of the ap= plication characteristics along with the device/platform/TEE policy. Now, once these simple TEE app characteristics (memory, storage, CPU time) = are considered, there are other characteristics that a TEE app might want/n= eed access to. Here are some examples: - device monotonic counter: some platforms have limits as to how often the = MC can be updated, and the entire life of the MC, based on flash wear level= ing. Restricting how a TEE app can use a MC is a policy decision for the de= vice/TEE - secure key store: there may be limits to the number of keys that can be s= tored within the TEE in a replay protected non-volatile secure storage area= . Access to this might be based on a TEE policy - other trusted HW devices: some devices on the platform may solely be acce= ssible inside the TEE, others might be configurable to be in the TEE or out= side. And access to these devices might need to be restricted. For example,= access to certain FW flash areas for secure update, access to the Safety I= sland on certain industrial parts, and of course access to the network, esp= ecially in a promiscuous mode. Additionally, I might configure my device so that //certain// service provi= ders are trusted to a level where they get access to //all// these types of= special resources (I trust those service providers) and other service prov= iders do not get any such access, or very limited access. One might argue, = how can you enforce this? The TEE manifest that includes the characteristic= s and requirements could lie - yes, but then they would be found out, becau= se their app is signed, and they would be banned by the TSM. So, now back to our proposed use case: For the DDoS application to work, it must be able to get access to the lowe= st packet level of the network stack, and be able to process packets at lin= e speed. This requirement has significant draws on the capability of the TE= E - available access to the network device, amount of memory consumed for p= acket buffers, amount of processing to keep up with packets, ... Some TEEs may not even be //able// to provide such services. Other TEEs may= restrict it. OTrP should be able to convey, during install, the rich set of application = requirements the TEE app needs to properly run, and this should be able to = be interpreted against the policy and capabilities of the TEE as interprete= d by the OTrP agent (or equivalent manager in the TEE).=20 For this reason, I like this use case, because it represents a non-trivial = application (not just an App computing pi), with interesting and complex re= quirements on the HW, environment, and other policy (like privacy - do I wa= nt an app that sees ALL of my network traffic and possibly be able to evalu= ate my network flows?)=20 How should OTrP handle the communication of TEE Application requirements? W= hat policy language is built into the protocol? Does the policy language in= clude some privacy atoms, as well as TEE resource atoms? What other charact= eristics can be / should be represented by the policy language? What are th= e limits of policy interpretation by the OTrP agent? These, I believe are v= aluable questions to consider. Perhaps we get to the point that it is too c= omplex for our first version, but I would like us to have the conversation = and consider it. And then, at least, have some insight to where such a desc= riptive policy language might intersect with the protocol (at some point). Thanks, - Dave Wheeler -----Original Message----- From: Dave Thaler [mailto:dthaler@microsoft.com]=20 Sent: Tuesday, March 27, 2018 9:34 AM To: Wheeler, David M ; Benjamin Kaduk ; faibish, sorin Cc: teep ; teep-chairs@ietf.org Subject: RE: [Teep] IETF 101 agenda requests On slide 6 of the "Problem Statement" slides there were three use cases for= Trusted Applications (as opposed to use cases for OTrP or TEEP per se), of= which one was IoT.=20 The Mirai botnet attack used the REE (not a TEE) of devices to conduct atta= cks against an external entity. Since TEEP is about TEE provisioning, not = REE provisioning, TEEP is not directly applicable to controlling how/whethe= r malware can be installed in the REE. I think what David's saying is that a provisioned TEE application could hav= e functionality to detect/mitigate something malicious that it detects an R= EE app is doing. That's true, just like the TEE application could do anyth= ing else (compute pi, etc.) but we shouldn't try to enumerate every operati= on that a TEE application might try to do, just things that introduce requi= rements on OTrP. In the "TEEP Use Cases" slides for IETF 101, these are use cases for OTrP (= as opposed to use cases for Trusted Apps in general). In the discussion around slide 6, we agreed that Rich Apps are largely orth= ogonal because they don't introduce new requirements on the OTrP protocol. I think Ben's saying this is simil= arly orthogonal. For it to not be orthogonal, one would have to argue how/why it affects the= OTrP protocol itself. If there is such an argument, that would be a good = way to continue this discussion. If not, or if we don't know if there is, = then it's orthogonal until such an argument is provided. Dave -----Original Message----- From: Wheeler, David M Sent: Tuesday, March 27, 2018 8:44 AM To: Benjamin Kaduk ; faibish, sorin Cc: teep ; Dave Thaler ; teep-chairs@= ietf.org Subject: RE: [Teep] IETF 101 agenda requests Ben, I agree with you regarding the question of charter, however, I think (pleas= e correct if I misunderstand) what Sorin is proposing is to use the DDoS ex= ample as a use case to evaluate if OTrP has considered the appropriate rela= tionships and entities within the protocol that would allow the proposed DD= oS solution to be implemented. Our charter does state that "the solution approach must take a wide range o= f TEE and relevant technologies" and the architecture document includes "re= levant use cases." Since the DDoS proposal includes an implementation where= a TEE application implements a set of filtering policies, I believe it is = relevant. I think it is a very interesting use case, since it expands beyond a simple= Device-User to Service-Provider situation, and creates a more complex inte= raction for the application - especially the interaction of the trusted app= lication to aspects of the device itself (i.e. filtering outgoing packets).= Is our policy for accepting TEE applications rich enough (or at least exte= nsible enough) to enable a device/user to implement controls on what applic= ations are allowed to do, perhaps even based on the service provider instal= ling those applications. I believe it is in our best interest to evaluate it, and the implications o= f such TEE applications. We can still come to the conclusion that some aspe= cts of supporting such a use case may be out-of-scope, but it will give us = concrete information to point to regarding what is exactly out-of-scope, wh= y it breeches our scope, and perhaps direct future additions/expansions to = the protocol. Thanks, Dave Wheeler -----Original Message----- From: TEEP [mailto:teep-bounces@ietf.org] On Behalf Of Benjamin Kaduk Sent: Monday, March 26, 2018 6:33 PM To: faibish, sorin Cc: teep ; Dave Thaler ; teep-chairs@= ietf.org Subject: Re: [Teep] IETF 101 agenda requests On Mon, Mar 26, 2018 at 11:12:37PM +0000, faibish, sorin wrote: > We discussed the DDoS in Singapore and we had a presentation on the DDoS: > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat > racker.ietf.org%2Fmeeting%2F100%2Fmaterials%2Fslides-100-saag-int&data > =3D02%7C01%7Cdthaler%40microsoft.com%7C105f96f6b0744e2a276408d593f98cc2% > 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636577622384270342&sdata=3D > 32qt5mT4aXYjJ9gZW%2BFRegXm4GbM%2FWlOpwh6XmnJ84I%3D&reserved=3D0 > er-domain-ddos-mitigations-potentials-challenges-and-solutions-min-suk > -kang/ >=20 > So, I would like to include this usecase as a target for the WG. I=20 > will write a draft related to this usecase. Thanks Wanting it to be a target and writing a draft are both orthogonal to the qu= estion of whether the work is in-charter. (Rechartering to include it woul= d of course be possible, through the normal procedure...) -Ben > ../Sorin >=20 > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > Sent: Friday, March 23, 2018 8:39 AM > To: faibish, sorin > Cc: Dave Thaler ; teep ;=20 > teep-chairs@ietf.org > Subject: Re: [Teep] IETF 101 agenda requests >=20 > Hi Sorin, >=20 > On Thu, Mar 22, 2018 at 09:26:22AM +0000, faibish, sorin wrote: > > New proposed usecase for TEEP WG. > >=20 > > Most recently the frequency and intensity of DDoS attacks from IoT devi= ces increased with attacks almost every day. The reason of the proliferatio= n of DDoS attacks from IoT devices is a result of the lower and maybe inexi= stent security protection of cheap IoT devices that have no security featur= es implemented as this would increase the cost of such devices using any se= curity HW. In the current charter of TEEP there sre 3 usecases and I would = like to add the protectioin against DDoS of IoT as a new usecase: >=20 > On a quick read of the charter, I don't see how this topic would be in sc= ope -- am I missing something that would allow it? >=20 > Thanks, >=20 > Ben >=20 > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i > etf.org%2Fmailman%2Flistinfo%2Fteep&data=3D02%7C01%7Cdthaler%40microsoft > .com%7C105f96f6b0744e2a276408d593f98cc2%7C72f988bf86f141af91ab2d7cd011 > db47%7C1%7C0%7C636577622384270342&sdata=3D1F4dZBFAumiRdEl7G4FYn0bO9VSzFy > k%2BSkxW6cCfesw%3D&reserved=3D0 _______________________________________________ TEEP mailing list TEEP@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fteep&data=3D02%7C01%7Cdthaler%40microsoft.com%7= C105f96f6b0744e2a276408d593f98cc2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C= 0%7C636577622384270342&sdata=3D1F4dZBFAumiRdEl7G4FYn0bO9VSzFyk%2BSkxW6cCfes= w%3D&reserved=3D0 From nobody Tue Mar 27 11:21:50 2018 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0022F129C6B; Tue, 27 Mar 2018 11:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 hb1BUlz-xglA; Tue, 27 Mar 2018 11:21:43 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0119.outbound.protection.outlook.com [104.47.42.119]) (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 2ACE61201F2; Tue, 27 Mar 2018 11:21:43 -0700 (PDT) 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=2x0FpQDoHl4x9Ag6+ZFNZhUV6LMP/zWytKNUvKsrA2c=; b=FsvMlNMcVtYTzG74+pfxWp8n//jAHslhzN0OCRbfH0UferC0viOVfJAPpRs6S73SBTbWuO/nq6sApMZqwrmKfDdM5nbSVR8hmGX0NspiGMV0NJv0aUFpis7eaZJWeBwjayu7gxRvBcXgifDJm0Y2FvrqvpvRGj1VvtZ9BrhBVTo= Received: from CY4PR21MB0774.namprd21.prod.outlook.com (10.173.192.20) by CY4PR21MB0774.namprd21.prod.outlook.com (10.173.192.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.0; Tue, 27 Mar 2018 18:21:41 +0000 Received: from CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::41f5:f274:8793:f7b1]) by CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::41f5:f274:8793:f7b1%8]) with mapi id 15.20.0653.002; Tue, 27 Mar 2018 18:21:41 +0000 From: Dave Thaler To: "Wheeler, David M" , Benjamin Kaduk , "faibish, sorin" CC: teep , "teep-chairs@ietf.org" Thread-Topic: [Teep] IETF 101 agenda requests Thread-Index: AdO9Xdcov18dMzNFTtSIcGlRK17eigEYdluQADkSTYAArP0PgAAE50aAAB23MQAAAJWuwAADX+YAAACHsOA= Date: Tue, 27 Mar 2018 18:21:41 +0000 Message-ID: References: <2313358402DBCC4DB2F2DC03CB08BBFEFF050A@MX304CL01.corp.emc.com> <20180323123925.GD25919@kduck.kaduk.org> <2313358402DBCC4DB2F2DC03CB08BBFE0100C5FE@MX304CL01.corp.emc.com> <20180327013301.GN44086@kduck.kaduk.org> <0627F5240443D2498FAA65332EE46C84367A64B7@CRSMSX102.amr.corp.intel.com> <0627F5240443D2498FAA65332EE46C84367A6598@CRSMSX102.amr.corp.intel.com> In-Reply-To: <0627F5240443D2498FAA65332EE46C84367A6598@CRSMSX102.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-03-27T17:58:07.4870731Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [167.220.0.59] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0774; 7:3QmePXX5fvVb309sgUmfLg0HwEx4DPD6ihx4OKNWQJK/zC+WDtAp3PVtzBKdTDls3uW7CbxlMjHLGtfLl0CmO1JU24JTTmFlq3wkyzA1XWoZFxZxBhOpO6SywaV/twv7hFcCw7dCX4blE8L9pOtyIdHZ5wso2vXNP0KszbqcGvUC09IpzeLnXhp8Wu21simW7KfZ+23M6ID12Q7tK8uW5IFKo9Xpod0yFSnNg0TWTf2zdJ8P0GVk7kDnQFAyasqj; 20:l6dACsBB83Yk6bfEC7xCr5uQ4t9zwc1JTQVj8dNfcgtx4661IyMYhxvNCFVZGT++5UKp/JkhMGZS6qDefTr4lnwywYa1ywJszwRKKuslmXrs+0fKtuE6CwoUBGx8JWoMCw9NLe8UA/ogJaKPHT6EwznGzJJ1Fn3rDOHmWFVyzRE= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: bfa8c17d-a86c-4c26-3ec3-08d5940f967e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY4PR21MB0774; x-ms-traffictypediagnostic: CY4PR21MB0774: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(278428928389397)(89211679590171)(192374486261705)(189930954265078)(219752817060721)(155532106045638)(21748063052155)(240460790083961)(56004941905204); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0774; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0774; x-forefront-prvs: 0624A2429E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(366004)(396003)(376002)(346002)(189003)(199004)(13464003)(3280700002)(26005)(93886005)(2906002)(81166006)(33656002)(6346003)(81156014)(2171002)(6436002)(53546011)(6506007)(8676002)(74316002)(4326008)(2900100001)(55016002)(5250100002)(3846002)(561944003)(86612001)(10290500003)(6246003)(6116002)(25786009)(102836004)(790700001)(8666007)(86362001)(106356001)(8990500004)(575784001)(316002)(68736007)(59450400001)(186003)(5890100001)(105586002)(966005)(76176011)(7736002)(7696005)(229853002)(14454004)(11346002)(5660300001)(446003)(486005)(476003)(66066001)(486005)(53936002)(54906003)(10090500001)(9686003)(236005)(3660700001)(54896002)(6306002)(97736004)(606006)(22452003)(478600001)(99286004)(110136005)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0774; H:CY4PR21MB0774.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-microsoft-antispam-message-info: JJKkkc8j77Uj9R+KatIllSUSSGLy3MicYWxxJWvC9epR1aqANKzXHJRd55fvaL04IfYauGUtk0hRjcsyTUKobvtJmV54twnym57sgmC8PWi/X8eDuhny6RFzektbhjo4PlkU7WZO993slOxdJJL7+lOYHRU86aH9nYAO0nwnDKg0EdovgfmDOY5M6ku5y8KXfGyNP9XPOyauTb91ks0gRWK32eMbnz6YN0D7WYkuvxrB1Iweu9gyleayvZNmwRyI/bOwwDJb4Q3NXzJYjHyosbIZTZZXVmagk5XG/uoHHwgDjCaR22mYn4wOU/AmkagKbx3cNv7uWkTdWD1mHwemfg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB077497716751D23AEF38D279A3AC0CY4PR21MB0774namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: bfa8c17d-a86c-4c26-3ec3-08d5940f967e X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2018 18:21:41.1618 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0774 Archived-At: Subject: Re: [Teep] IETF 101 agenda requests X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 18:21:48 -0000 --_000_CY4PR21MB077497716751D23AEF38D279A3AC0CY4PR21MB0774namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Wheeler, David M Sent: Tuesday, March 27, 2018 10:37 AM To: Dave Thaler ; Benjamin Kaduk ; fa= ibish, sorin Cc: teep ; teep-chairs@ietf.org Subject: RE: [Teep] IETF 101 agenda requests > For it to not be orthogonal, one would have to argue how/why it affects t= he OTrP protocol itself. OK, let me try to present the argument :) Excellent, thanks for doing this. A TEE application, when provisioned into a device, will require certain res= ources of the device. These resources will definitely include storage, RAM, and possibly some mea= sure of CPU time. OTrP //should// have some policy hooks that allow a device/device user/owne= r to define what are acceptable limits of resource consumption for a TEE ap= plication. For example, as long as a TEE app consumes less than 100MB RAM, = it is OK to install (perhaps because I only have 250MB allocated to the TEE= , and I don't want ALL the memory consumed by one app). This policy should be attached to the TEE application at install time, be i= nterpreted by the OTrP Agent, and be evaluated as an intersection of the ap= plication characteristics along with the device/platform/TEE policy. Now, once these simple TEE app characteristics (memory, storage, CPU time) = are considered, there are other characteristics that a TEE app might want/n= eed access to. Here are some examples: - device monotonic counter: some platforms have limits as to how often the = MC can be updated, and the entire life of the MC, based on flash wear level= ing. Restricting how a TEE app can use a MC is a policy decision for the de= vice/TEE - secure key store: there may be limits to the number of keys that can be s= tored within the TEE in a replay protected non-volatile secure storage area= . Access to this might be based on a TEE policy - other trusted HW devices: some devices on the platform may solely be acce= ssible inside the TEE, others might be configurable to be in the TEE or out= side. And access to these devices might need to be restricted. For example,= access to certain FW flash areas for secure update, access to the Safety I= sland on certain industrial parts, and of course access to the network, esp= ecially in a promiscuous mode. Additionally, I might configure my device so that //certain// service provi= ders are trusted to a level where they get access to //all// these types of= special resources (I trust those service providers) and other service prov= iders do not get any such access, or very limited access. One might argue, = how can you enforce this? The TEE manifest that includes the characteristic= s and requirements could lie - yes, but then they would be found out, becau= se their app is signed, and they would be banned by the TSM. All of the above makes sense to me. So, now back to our proposed use case: For the DDoS application to work, it must be able to get access to the lowe= st packet level of the network stack, and be able to process packets at lin= e speed. Now you lost me. To conduct a DDoS attack against an external entity you d= on't have to process packets very fast at all. You, and zillions of other = devices like you, sending packets at a slow rate, collectively add up to a = DDoS attack against a victim. This requirement has significant draws on the capability of the TEE - avail= able access to the network device, amount of memory consumed for packet buf= fers, amount of processing to keep up with packets, ... Sorin's original use case, as I understand it, is about devices being able = to conduct DDoS attacks. Preventing TEE apps from doing so doesn't address= that use case, if REE apps on the same devices can still do the attacks, e= specially since that's how such attacks already work. Some TEEs may not even be //able// to provide such services. Other TEEs may= restrict it. OTrP should be able to convey, during install, the rich set of application = requirements the TEE app needs to properly run, and this should be able to = be interpreted against the policy and capabilities of the TEE as interprete= d by the OTrP agent (or equivalent manager in the TEE). Again, I don't see this as addressing the DDoS use case. I sounds like yo= u're hinting at a separate use case which isn't about DDoS at all, maybe yo= u can expand on that? For this reason, I like this use case, because it represents a non-trivial = application (not just an App computing pi), with interesting and complex re= quirements on the HW, environment, and other policy (like privacy - do I wa= nt an app that sees ALL of my network traffic and possibly be able to evalu= ate my network flows?) How should OTrP handle the communication of TEE Application requirements? W= hat policy language is built into the protocol? Does the policy language in= clude some privacy atoms, as well as TEE resource atoms? What other charact= eristics can be / should be represented by the policy language? What are th= e limits of policy interpretation by the OTrP agent? These, I believe are v= aluable questions to consider. Perhaps we get to the point that it is too c= omplex for our first version, but I would like us to have the conversation = and consider it. And then, at least, have some insight to where such a desc= riptive policy language might intersect with the protocol (at some point). Your last paragraph does sound potentially relevant and useful to discuss (= though again, not connected to any DDoS use case in any way I can see yet). Thanks, - Dave Wheeler -----Original Message----- From: Dave Thaler [mailto:dthaler@microsoft.com] Sent: Tuesday, March 27, 2018 9:34 AM To: Wheeler, David M >; Benjamin Kaduk >; faibish, sor= in > Cc: teep >; teep-chairs@ietf.org Subject: RE: [Teep] IETF 101 agenda requests On slide 6 of the "Problem Statement" slides there were three use cases for= Trusted Applications (as opposed to use cases for OTrP or TEEP per se), of= which one was IoT. The Mirai botnet attack used the REE (not a TEE) of devices to conduct atta= cks against an external entity. Since TEEP is about TEE provisioning, not = REE provisioning, TEEP is not directly applicable to controlling how/whethe= r malware can be installed in the REE. I think what David's saying is that a provisioned TEE application could hav= e functionality to detect/mitigate something malicious that it detects an R= EE app is doing. That's true, just like the TEE application could do anyth= ing else (compute pi, etc.) but we shouldn't try to enumerate every operati= on that a TEE application might try to do, just things that introduce requi= rements on OTrP. In the "TEEP Use Cases" slides for IETF 101, these are use cases for OTrP (= as opposed to use cases for Trusted Apps in general). In the discussion around slide 6, we agreed that Rich Apps are largely orth= ogonal because they don't introduce new requirements on the OTrP protocol. I think Ben's saying this is simil= arly orthogonal. For it to not be orthogonal, one would have to argue how/why it affects the= OTrP protocol itself. If there is such an argument, that would be a good = way to continue this discussion. If not, or if we don't know if there is, = then it's orthogonal until such an argument is provided. Dave -----Original Message----- From: Wheeler, David M > Sent: Tuesday, March 27, 2018 8:44 AM To: Benjamin Kaduk >; faibish, sorin > Cc: teep >; Dave Thaler >; teep-chairs@ietf.org Subject: RE: [Teep] IETF 101 agenda requests Ben, I agree with you regarding the question of charter, however, I think (pleas= e correct if I misunderstand) what Sorin is proposing is to use the DDoS ex= ample as a use case to evaluate if OTrP has considered the appropriate rela= tionships and entities within the protocol that would allow the proposed DD= oS solution to be implemented. Our charter does state that "the solution approach must take a wide range o= f TEE and relevant technologies" and the architecture document includes "re= levant use cases." Since the DDoS proposal includes an implementation where= a TEE application implements a set of filtering policies, I believe it is = relevant. I think it is a very interesting use case, since it expands beyond a simple= Device-User to Service-Provider situation, and creates a more complex inte= raction for the application - especially the interaction of the trusted app= lication to aspects of the device itself (i.e. filtering outgoing packets).= Is our policy for accepting TEE applications rich enough (or at least exte= nsible enough) to enable a device/user to implement controls on what applic= ations are allowed to do, perhaps even based on the service provider instal= ling those applications. I believe it is in our best interest to evaluate it, and the implications o= f such TEE applications. We can still come to the conclusion that some aspe= cts of supporting such a use case may be out-of-scope, but it will give us = concrete information to point to regarding what is exactly out-of-scope, wh= y it breeches our scope, and perhaps direct future additions/expansions to = the protocol. Thanks, Dave Wheeler -----Original Message----- From: TEEP [mailto:teep-bounces@ietf.org] On Behalf Of Benjamin Kaduk Sent: Monday, March 26, 2018 6:33 PM To: faibish, sorin > Cc: teep >; Dave Thaler >; teep-chairs@ietf.org Subject: Re: [Teep] IETF 101 agenda requests On Mon, Mar 26, 2018 at 11:12:37PM +0000, faibish, sorin wrote: > We discussed the DDoS in Singapore and we had a presentation on the DDoS: > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat > racker.ietf.org%2Fmeeting%2F100%2Fmaterials%2Fslides-100-saag-int&data > =3D02%7C01%7Cdthaler%40microsoft.com%7C105f96f6b0744e2a276408d593f98cc2% > 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636577622384270342&sdata=3D > 32qt5mT4aXYjJ9gZW%2BFRegXm4GbM%2FWlOpwh6XmnJ84I%3D&reserved=3D0 > er-domain-ddos-mitigations-potentials-challenges-and-solutions-min-suk > -kang/ > > So, I would like to include this usecase as a target for the WG. I > will write a draft related to this usecase. Thanks Wanting it to be a target and writing a draft are both orthogonal to the qu= estion of whether the work is in-charter. (Rechartering to include it woul= d of course be possible, through the normal procedure...) -Ben > ../Sorin > > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > Sent: Friday, March 23, 2018 8:39 AM > To: faibish, sorin > > Cc: Dave Thaler >; te= ep >; > teep-chairs@ietf.org > Subject: Re: [Teep] IETF 101 agenda requests > > Hi Sorin, > > On Thu, Mar 22, 2018 at 09:26:22AM +0000, faibish, sorin wrote: > > New proposed usecase for TEEP WG. > > > > Most recently the frequency and intensity of DDoS attacks from IoT devi= ces increased with attacks almost every day. The reason of the proliferatio= n of DDoS attacks from IoT devices is a result of the lower and maybe inexi= stent security protection of cheap IoT devices that have no security featur= es implemented as this would increase the cost of such devices using any se= curity HW. In the current charter of TEEP there sre 3 usecases and I would = like to add the protectioin against DDoS of IoT as a new usecase: > > On a quick read of the charter, I don't see how this topic would be in sc= ope -- am I missing something that would allow it? > > Thanks, > > Ben > > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i > etf.org%2Fmailman%2Flistinfo%2Fteep&data=3D02%7C01%7Cdthaler%40microsoft > .com%7C105f96f6b0744e2a276408d593f98cc2%7C72f988bf86f141af91ab2d7cd011 > db47%7C1%7C0%7C636577622384270342&sdata=3D1F4dZBFAumiRdEl7G4FYn0bO9VSzFy > k%2BSkxW6cCfesw%3D&reserved=3D0 _______________________________________________ TEEP mailing list TEEP@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fteep&data=3D02%7C01%7Cdthaler%40microsoft.com%7= C105f96f6b0744e2a276408d593f98cc2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C= 0%7C636577622384270342&sdata=3D1F4dZBFAumiRdEl7G4FYn0bO9VSzFyk%2BSkxW6cCfes= w%3D&reserved=3D0 --_000_CY4PR21MB077497716751D23AEF38D279A3AC0CY4PR21MB0774namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

-----Original Message-= ----
From: Wheeler, David M <david.m.wheeler@intel.com>
Sent: Tuesday, March 27, 2018 10:37 AM
To: Dave Thaler <dthaler@microsoft.com>; Benjamin Kaduk <kaduk@mit= .edu>; faibish, sorin <Faibish.Sorin@dell.com>
Cc: teep <teep@ietf.org>; teep-chairs@ietf.org
Subject: RE: [Teep] IETF 101 agenda requests

 

> For it to not be = orthogonal, one would have to argue how/why it affects the OTrP protocol it= self. 

 

OK, let me try to pres= ent the argument :)

 

Excellent, thanks for= doing this.

 

A TEE application, whe= n provisioned into a device, will require certain resources of the device.<= o:p>

These resources will d= efinitely include storage, RAM, and possibly some measure of CPU time.=

OTrP //should// have s= ome policy hooks that allow a device/device user/owner to define what are a= cceptable limits of resource consumption for a TEE application. For example= , as long as a TEE app consumes less than 100MB RAM, it is OK to install (perhaps because I only have 250MB all= ocated to the TEE, and I don't want ALL the memory consumed by one app).

 

This policy should be = attached to the TEE application at install time, be interpreted by the OTrP= Agent, and be evaluated as an intersection of the application characterist= ics along with the device/platform/TEE policy.

 

Now, once these simple= TEE app characteristics (memory, storage, CPU time) are considered, there = are other characteristics that a TEE app might want/need access to. Here ar= e some examples:

- device monotonic cou= nter: some platforms have limits as to how often the MC can be updated, and= the entire life of the MC, based on flash wear leveling. Restricting how a= TEE app can use a MC is a policy decision for the device/TEE

 

- secure key store: th= ere may be limits to the number of keys that can be stored within the TEE i= n a replay protected non-volatile secure storage area. Access to this might= be based on a TEE policy

 

- other trusted HW dev= ices: some devices on the platform may solely be accessible inside the TEE,= others might be configurable to be in the TEE or outside. And access to th= ese devices might need to be restricted. For example, access to certain FW flash areas for secure update, access to= the Safety Island on certain industrial parts, and of course access to the= network, especially in a promiscuous mode.

 

Additionally, I might = configure my device so that //certain// service providers are trusted to a = level where they get access to //all// these types of special resources (I = trust those service providers) and other service providers do not get any such access, or very limited access. One = might argue, how can you enforce this? The TEE manifest that includes the c= haracteristics and requirements could lie - yes, but then they would be fou= nd out, because their app is signed, and they would be banned by the TSM.

 

All of the above make= s sense to me.

 

So, now back to our pr= oposed use case:

For the DDoS applicati= on to work, it must be able to get access to the lowest packet level of the= network stack, and be able to process packets at line speed.

 

Now you lost me.  To conduct a DDoS attack a= gainst an external entity you don’t have to process packets very fast= at all.  You, and zillions of other devices like you, sending packets= at a slow rate, collectively add up to a DDoS attack against a victim.

 

This requirement has s= ignificant draws on the capability of the TEE - available access to the net= work device, amount of memory consumed for packet buffers, amount of proces= sing to keep up with packets, ...

 

Sorin’s origina= l use case, as I understand it, is about devices being able to conduct DDoS= attacks.  Preventing TEE apps from doing so doesn’t address tha= t use case, if REE apps on the same devices can still do the attacks, especially since that’s how such attacks already wor= k.

 

Some TEEs may not even= be //able// to provide such services. Other TEEs may restrict it.

 

OTrP should be able to= convey, during install, the rich set of application requirements the TEE a= pp needs to properly run, and this should be able to be interpreted against= the policy and capabilities of the TEE as interpreted by the OTrP agent (or equivalent manager in the TEE). <= o:p>

 

Again, I don’t = see this as addressing the DDoS use case.   I sounds like youR= 17;re hinting at a separate use case which isn’t about DDoS at all, m= aybe you can expand on that?

 

For this reason, I lik= e this use case, because it represents a non-trivial application (not just = an App computing pi), with interesting and complex requirements on the HW, = environment, and other policy (like privacy - do I want an app that sees ALL of my network traffic and possibl= y be able to evaluate my network flows?)

 

How should OTrP handle= the communication of TEE Application requirements? What policy language is= built into the protocol? Does the policy language include some privacy ato= ms, as well as TEE resource atoms? What other characteristics can be / should be represented by the policy languag= e? What are the limits of policy interpretation by the OTrP agent? These, I= believe are valuable questions to consider. Perhaps we get to the point th= at it is too complex for our first version, but I would like us to have the conversation and consider it. And= then, at least, have some insight to where such a descriptive policy langu= age might intersect with the protocol (at some point).

 

Your last paragraph d= oes sound potentially relevant and useful to discuss (though again, not con= nected to any DDoS use case in any way I can see yet).

 

Thanks,

- Dave Wheeler

 

-----Original Message-----

From: Dave Thaler [mailto:dth= aler@microsoft.com]

Sent: Tuesday, March 27, 2018 9:34 AM<= /p>

To: Wheeler, David M <= david.m.wheeler@intel.com>; Benjamin Kaduk <ka= duk@mit.edu>; faibish, sorin <Faibish.Sorin@dell.com>

Cc: teep <teep@ietf.org= >; teep-chairs@ietf.org

Subject: RE: [Teep] IETF 101 agenda requests=

 

On slide 6 of the "Problem Statement" s= lides there were three use cases for Trusted Applications (as opposed to us= e cases for OTrP or TEEP per se), of which one was IoT.

 

The Mirai botnet attack used the REE (not a TEE) = of devices to conduct attacks against an external entity.  Since TEEP = is about TEE provisioning, not REE provisioning, TEEP is not directly appli= cable to controlling how/whether malware can be installed in the REE.

 

I think what David's saying is that a provisioned= TEE application could have functionality to detect/mitigate something mali= cious that it detects an REE app is doing.  That's true, just like the= TEE application could do anything else (compute pi, etc.) but we shouldn't try to enumerate every operation that = a TEE application might try to do, just things that introduce requirements = on OTrP.

 

In the "TEEP Use Cases" slides for IETF= 101, these are use cases for OTrP (as opposed to use cases for Trusted App= s in general).

In the discussion around slide 6, we agreed that = Rich Apps are largely orthogonal because they don't introduce

new requirements on the OTrP protocol.  = ; I think Ben's saying this is similarly orthogonal.

 

For it to not be orthogonal, one would have to ar= gue how/why it affects the OTrP protocol itself.  If there is such an = argument, that would be a good way to continue this discussion.  If no= t, or if we don't know if there is, then it's orthogonal until such an argument is provided.

 

Dave

 

-----Original Message-----

From: Wheeler, David M <david.m.wheeler@intel.com>

Sent: Tuesday, March 27, 2018 8:44 AM<= /p>

To: Benjamin Kaduk <kaduk@mit.edu<= /span>>; faibish, sorin <Faibish.Sorin@dell.= com>

Cc: teep <teep@ietf.org= >; Dave Thaler <dthaler@microsoft.com= >; teep-chairs@ietf.org

Subject: RE: [Teep] IETF 101 agenda requests=

 

Ben,

I agree with you regarding the question of charte= r, however, I think (please correct if I misunderstand) what Sorin is propo= sing is to use the DDoS example as a use case to evaluate if OTrP has consi= dered the appropriate relationships and entities within the protocol that would allow the proposed DDoS soluti= on to be implemented.

 

Our charter does state that "the solution ap= proach must take a wide range of TEE and relevant technologies" and th= e architecture document includes "relevant use cases." Since the = DDoS proposal includes an implementation where a TEE application implements a set of filtering policies, I believe it is relevant.

 

I think it is a very interesting use case, since = it expands beyond a simple Device-User to Service-Provider situation, and c= reates a more complex interaction for the application - especially the inte= raction of the trusted application to aspects of the device itself (i.e. filtering outgoing packets). Is our = policy for accepting TEE applications rich enough (or at least extensible e= nough) to enable a device/user to implement controls on what applications a= re allowed to do, perhaps even based on the service provider installing those applications.

 

I believe it is in our best interest to evaluate = it, and the implications of such TEE applications. We can still come to the= conclusion that some aspects of supporting such a use case may be out-of-s= cope, but it will give us concrete information to point to regarding what is exactly out-of-scope, why it bre= eches our scope, and perhaps direct future additions/expansions to the prot= ocol.

 

Thanks,

Dave Wheeler

 

 

-----Original Message-----

From: TEEP [mailto:teep-bounc= es@ietf.org] On Behalf Of Benjamin Kaduk

Sent: Monday, March 26, 2018 6:33 PM

To: faibish, sorin <Faibi= sh.Sorin@dell.com>

Cc: teep <teep@ietf.org= >; Dave Thaler <dthaler@microsoft.com= >; teep-chairs@ietf.org

Subject: Re: [Teep] IETF 101 agenda requests=

 

On Mon, Mar 26, 2018 at 11:12:37PM +0000, fai= bish, sorin wrote:

> We discussed the DDoS in Singapore and we ha= d a presentation on the DDoS:

> https://na01.safelink= s.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat

> racker.ietf.org%2Fmeeting%2F100%2Fmaterials%= 2Fslides-100-saag-int&data

> =3D02%7C01%7Cdthaler%40microsoft.com%7C105f9= 6f6b0744e2a276408d593f98cc2%

> 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7= C636577622384270342&sdata=3D

> 32qt5mT4aXYjJ9gZW%2BFRegXm4GbM%2FWlOpwh6XmnJ= 84I%3D&reserved=3D0

> er-domain-ddos-mitigations-potentials-challe= nges-and-solutions-min-suk

> -kang/

>

> So, I would like to include this usecase as = a target for the WG. I

> will write a draft related to this usecase. = Thanks

 

Wanting it to be a target and writing a draft are= both orthogonal to the question of whether the work is in-charter.  (= Rechartering to include it would of course be possible, through the normal<= o:p>

procedure...)

 

-Ben

 

> ../Sorin

>

> -----Original Message-----

> From: Benjamin Kaduk [mailto:kad= uk@mit.edu]

> Sent: Friday, March 23, 2018 8:39 AM

> To: faibish, sorin <f= aibish_sorin@emc.com>

> Cc: Dave Thaler <dtha= ler@microsoft.com>; teep <teep@ietf.org= >;

> teep-chairs@ietf.org

> Subject: Re: [Teep] IETF 101 agenda requests=

>

> Hi Sorin,

>

> On Thu, Mar 22, 2018 at 09:26:22AM +0000= , faibish, sorin wrote:

> > New proposed usecase for TEEP WG.<= /o:p>

> >

> > Most recently the frequency and intensi= ty of DDoS attacks from IoT devices increased with attacks almost every day= . The reason of the proliferation of DDoS attacks from IoT devices is a res= ult of the lower and maybe inexistent security protection of cheap IoT devices that have no security features implemented= as this would increase the cost of such devices using any security HW. In = the current charter of TEEP there sre 3 usecases and I would like to add th= e protectioin against DDoS of IoT as a new usecase:

>

> On a quick read of the charter, I don't see = how this topic would be in scope -- am I missing something that would allow= it?

>

> Thanks,

>

> Ben

>

> ____________________________________________= ___

> TEEP mailing list

> TEEP@ietf.org

> https://na01.safelink= s.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i

> etf.org%2Fmailman%2Flistinfo%2Fteep&data= =3D02%7C01%7Cdthaler%40microsoft

> .com%7C105f96f6b0744e2a276408d593f98cc2%7C72= f988bf86f141af91ab2d7cd011

> db47%7C1%7C0%7C636577622384270342&sdata= =3D1F4dZBFAumiRdEl7G4FYn0bO9VSzFy

> k%2BSkxW6cCfesw%3D&reserved=3D0

 

_______________________________________________

TEEP mailing list

TEEP@ietf.org

https://na01.safelinks.pro= tection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%= 2Fteep&data=3D02%7C01%7Cdthaler%40microsoft.com%7C105f96f6b0744e2a27640= 8d593f98cc2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636577622384270342= &sdata=3D1F4dZBFAumiRdEl7G4FYn0bO9VSzFyk%2BSkxW6cCfesw%3D&reserved= =3D0

--_000_CY4PR21MB077497716751D23AEF38D279A3AC0CY4PR21MB0774namp_-- From nobody Tue Mar 27 16:19:27 2018 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C13012E8AD; Tue, 27 Mar 2018 16:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=trtlQ7ma; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=WaukLmcw 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 hhN9-pGtLAIY; Tue, 27 Mar 2018 16:19:16 -0700 (PDT) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 B572312E876; Tue, 27 Mar 2018 16:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1522192755; x=1553728755; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EPszruwZ96/zNpD2LHYW7AXVmF8mCT1tYBurtGbCj8Y=; b=trtlQ7macmr7Wf+PR60SNIjPHVm5O0K1eA0z2QsFCqutksIHPD+B2zby 9TPNLmVH70O31L1ldhI6Y243BSoUo/SE9DTeuu9HRJTIiWOa2m08VLz5W DoW+LygXW9MimIphLncuuXKXbEyUUOB99VD8Zd/Sr4O2aThTihEZ8x766 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2G7BwAV0LpamD+a6ERTCg4OAQEBBAEBC?= =?us-ascii?q?gEBgm8jgQIOcCgKmGeBdHUaklEUgTU6CyMIgWaCcwKEAyE2FgECAQEBAQEBAgE?= =?us-ascii?q?CEAEBAQEBCAsLBigjDII4JAEODiMCAhYhCAExAQEBAQEBAQEBAQEBAQEBAQEBF?= =?us-ascii?q?wIlGBMCGAEBAQMBOgYuBAcBBAcEAgEIEQEDAQEBChQJBzIUAwYIAgQBDQUIEQK?= =?us-ascii?q?CdQSBYgMNCAEOrheCd4QbA4E2giEDBYU6BIEUDHqBVECBDIJTNIFBgVIEGYEHC?= =?us-ascii?q?AEBBwQHAQsWBSUMgnmCJIc2kA8IAoVRihCDWIJchFiHJ4gvAgQCBAUCFIElIwg?= =?us-ascii?q?3VHFwT4JDgi+DUIoXOm8BAQGNMgEOGIEIgRcBAQ?= X-IPAS-Result: =?us-ascii?q?A2G7BwAV0LpamD+a6ERTCg4OAQEBBAEBCgEBgm8jgQIOcCg?= =?us-ascii?q?KmGeBdHUaklEUgTU6CyMIgWaCcwKEAyE2FgECAQEBAQEBAgECEAEBAQEBCAsLB?= =?us-ascii?q?igjDII4JAEODiMCAhYhCAExAQEBAQEBAQEBAQEBAQEBAQEBFwIlGBMCGAEBAQM?= =?us-ascii?q?BOgYuBAcBBAcEAgEIEQEDAQEBChQJBzIUAwYIAgQBDQUIEQKCdQSBYgMNCAEOr?= =?us-ascii?q?heCd4QbA4E2giEDBYU6BIEUDHqBVECBDIJTNIFBgVIEGYEHCAEBBwQHAQsWBSU?= =?us-ascii?q?MgnmCJIc2kA8IAoVRihCDWIJchFiHJ4gvAgQCBAUCFIElIwg3VHFwT4JDgi+DU?= =?us-ascii?q?IoXOm8BAQGNMgEOGIEIgRcBAQ?= Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2018 18:19:14 -0500 From: "faibish, sorin" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2018 05:15:31 +0600 Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w2RNJA1m031118 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 27 Mar 2018 19:19:12 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com w2RNJA1m031118 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1522192753; bh=QsmO/ryaMQ5u+Zbc+4QmXNHOpZ8=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=WaukLmcwzik4gbybgBPC8SE71e8R1aa0ZiaWZV5A/jKlvfsQgVYJ6iL1GCzY2y8zJ 0zm4I78Z4nR1wnlIu2mNGU+presZlO63A5t3dERVslfVaz1Kdc7OawkCsY0wEFbZwz QMpyp6HkY2Y48n7C07eq6RIUnP7GScufXFmWDDNE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com w2RNJA1m031118 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd52.lss.emc.com (RSA Interceptor); Tue, 27 Mar 2018 19:18:51 -0400 Received: from MXHUB320.corp.emc.com (MXHUB320.corp.emc.com [10.146.3.98]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w2RNImF8024938 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 27 Mar 2018 19:18:50 -0400 Received: from MX304CL01.corp.emc.com ([fe80::2d21:ebf8:dc15:2b07]) by MXHUB320.corp.emc.com ([10.146.3.98]) with mapi id 14.03.0382.000; Tue, 27 Mar 2018 19:18:48 -0400 To: "Wheeler, David M" , Dave Thaler , Benjamin Kaduk CC: teep , "teep-chairs@ietf.org" Thread-Topic: [Teep] IETF 101 agenda requests Thread-Index: AdO9Xdcov18dMzNFTtSIcGlRK17eigEYdluQAEF0EYAApIpjUAANWfKAAB23MQAAAb1mgAACOC4AAAM2OuA= Date: Tue, 27 Mar 2018 23:18:48 +0000 Message-ID: <2313358402DBCC4DB2F2DC03CB08BBFE0101206F@MX304CL01.corp.emc.com> References: <2313358402DBCC4DB2F2DC03CB08BBFEFF050A@MX304CL01.corp.emc.com> <20180323123925.GD25919@kduck.kaduk.org> <2313358402DBCC4DB2F2DC03CB08BBFE0100C5FE@MX304CL01.corp.emc.com> <20180327013301.GN44086@kduck.kaduk.org> <0627F5240443D2498FAA65332EE46C84367A64B7@CRSMSX102.amr.corp.intel.com> <0627F5240443D2498FAA65332EE46C84367A6598@CRSMSX102.amr.corp.intel.com> In-Reply-To: <0627F5240443D2498FAA65332EE46C84367A6598@CRSMSX102.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.252.42.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [Teep] IETF 101 agenda requests X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 23:19:25 -0000 David, Thank you for your detailed clarifications. I just want to address one poin= t within: -----Original Message----- From: Wheeler, David M [mailto:david.m.wheeler@intel.com]=20 Sent: Tuesday, March 27, 2018 1:37 PM To: Dave Thaler ; Benjamin Kaduk ; fa= ibish, sorin Cc: teep ; teep-chairs@ietf.org Subject: RE: [Teep] IETF 101 agenda requests > For it to not be orthogonal, one would have to argue how/why it affects t= he OTrP protocol itself. =20 OK, let me try to present the argument :) A TEE application, when provisioned into a device, will require certain res= ources of the device. These resources will definitely include storage, RAM, and possibly some mea= sure of CPU time. OTrP //should// have some policy hooks that allow a device/device user/owne= r to define what are acceptable limits of resource consumption for a TEE ap= plication. For example, as long as a TEE app consumes less than 100MB RAM, = it is OK to install (perhaps because I only have 250MB allocated to the TEE= , and I don't want ALL the memory consumed by one app). This policy should be attached to the TEE application at install time, be i= nterpreted by the OTrP Agent, and be evaluated as an intersection of the ap= plication characteristics along with the device/platform/TEE policy. Now, once these simple TEE app characteristics (memory, storage, CPU time) = are considered, there are other characteristics that a TEE app might want/n= eed access to. Here are some examples: - device monotonic counter: some platforms have limits as to how often the = MC can be updated, and the entire life of the MC, based on flash wear level= ing. Restricting how a TEE app can use a MC is a policy decision for the de= vice/TEE [sf] The resources used for DDoS potential attacks are not necessarily dete= cted as extremely different as Dave pointed in the other email yet the fact= that the execution of the offending code is IMHO already a breach as the s= ecure application was used to activate network traffic that it was trusted = to be real data sent to the cloud and yet it is malicious. As Dave mentione= d the amount of traffic is not very large but it is sent from many IoT devi= ces. The problem I want to address is the trust that the "safe" application= was given and due to the breach the attackers are using to generate the ne= twork packets which in my opinion is a breach of trust. There is a valid qu= estion though that Dave asks: how do we identify malicious packets not in v= ery large amounts sent by the "trusted" application. In normal situations t= he application may send packets to the cloud, for example, not legitimate o= nes. This is the real problem of trust.=20 ./Sorin =20 - secure key store: there may be limits to the number of keys that can be s= tored within the TEE in a replay protected non-volatile secure storage area= . Access to this might be based on a TEE policy - other trusted HW devices: some devices on the platform may solely be acce= ssible inside the TEE, others might be configurable to be in the TEE or out= side. And access to these devices might need to be restricted. For example,= access to certain FW flash areas for secure update, access to the Safety I= sland on certain industrial parts, and of course access to the network, esp= ecially in a promiscuous mode. Additionally, I might configure my device so that //certain// service provi= ders are trusted to a level where they get access to //all// these types of= special resources (I trust those service providers) and other service prov= iders do not get any such access, or very limited access. One might argue, = how can you enforce this? The TEE manifest that includes the characteristic= s and requirements could lie - yes, but then they would be found out, becau= se their app is signed, and they would be banned by the TSM. So, now back to our proposed use case: For the DDoS application to work, it must be able to get access to the lowe= st packet level of the network stack, and be able to process packets at lin= e speed. This requirement has significant draws on the capability of the TE= E - available access to the network device, amount of memory consumed for p= acket buffers, amount of processing to keep up with packets, ... Some TEEs may not even be //able// to provide such services. Other TEEs may= restrict it. OTrP should be able to convey, during install, the rich set of application = requirements the TEE app needs to properly run, and this should be able to = be interpreted against the policy and capabilities of the TEE as interprete= d by the OTrP agent (or equivalent manager in the TEE).=20 For this reason, I like this use case, because it represents a non-trivial = application (not just an App computing pi), with interesting and complex re= quirements on the HW, environment, and other policy (like privacy - do I wa= nt an app that sees ALL of my network traffic and possibly be able to evalu= ate my network flows?)=20 How should OTrP handle the communication of TEE Application requirements? W= hat policy language is built into the protocol? Does the policy language in= clude some privacy atoms, as well as TEE resource atoms? What other charact= eristics can be / should be represented by the policy language? What are th= e limits of policy interpretation by the OTrP agent? These, I believe are v= aluable questions to consider. Perhaps we get to the point that it is too c= omplex for our first version, but I would like us to have the conversation = and consider it. And then, at least, have some insight to where such a desc= riptive policy language might intersect with the protocol (at some point). Thanks, - Dave Wheeler -----Original Message----- From: Dave Thaler [mailto:dthaler@microsoft.com] Sent: Tuesday, March 27, 2018 9:34 AM To: Wheeler, David M ; Benjamin Kaduk ; faibish, sorin Cc: teep ; teep-chairs@ietf.org Subject: RE: [Teep] IETF 101 agenda requests On slide 6 of the "Problem Statement" slides there were three use cases for= Trusted Applications (as opposed to use cases for OTrP or TEEP per se), of= which one was IoT.=20 The Mirai botnet attack used the REE (not a TEE) of devices to conduct atta= cks against an external entity. Since TEEP is about TEE provisioning, not = REE provisioning, TEEP is not directly applicable to controlling how/whethe= r malware can be installed in the REE. I think what David's saying is that a provisioned TEE application could hav= e functionality to detect/mitigate something malicious that it detects an R= EE app is doing. That's true, just like the TEE application could do anyth= ing else (compute pi, etc.) but we shouldn't try to enumerate every operati= on that a TEE application might try to do, just things that introduce requi= rements on OTrP. In the "TEEP Use Cases" slides for IETF 101, these are use cases for OTrP (= as opposed to use cases for Trusted Apps in general). In the discussion around slide 6, we agreed that Rich Apps are largely orth= ogonal because they don't introduce new requirements on the OTrP protocol. I think Ben's saying this is simil= arly orthogonal. For it to not be orthogonal, one would have to argue how/why it affects the= OTrP protocol itself. If there is such an argument, that would be a good = way to continue this discussion. If not, or if we don't know if there is, = then it's orthogonal until such an argument is provided. Dave -----Original Message----- From: Wheeler, David M Sent: Tuesday, March 27, 2018 8:44 AM To: Benjamin Kaduk ; faibish, sorin Cc: teep ; Dave Thaler ; teep-chairs@= ietf.org Subject: RE: [Teep] IETF 101 agenda requests Ben, I agree with you regarding the question of charter, however, I think (pleas= e correct if I misunderstand) what Sorin is proposing is to use the DDoS ex= ample as a use case to evaluate if OTrP has considered the appropriate rela= tionships and entities within the protocol that would allow the proposed DD= oS solution to be implemented. Our charter does state that "the solution approach must take a wide range o= f TEE and relevant technologies" and the architecture document includes "re= levant use cases." Since the DDoS proposal includes an implementation where= a TEE application implements a set of filtering policies, I believe it is = relevant. I think it is a very interesting use case, since it expands beyond a simple= Device-User to Service-Provider situation, and creates a more complex inte= raction for the application - especially the interaction of the trusted app= lication to aspects of the device itself (i.e. filtering outgoing packets).= Is our policy for accepting TEE applications rich enough (or at least exte= nsible enough) to enable a device/user to implement controls on what applic= ations are allowed to do, perhaps even based on the service provider instal= ling those applications. I believe it is in our best interest to evaluate it, and the implications o= f such TEE applications. We can still come to the conclusion that some aspe= cts of supporting such a use case may be out-of-scope, but it will give us = concrete information to point to regarding what is exactly out-of-scope, wh= y it breeches our scope, and perhaps direct future additions/expansions to = the protocol. Thanks, Dave Wheeler -----Original Message----- From: TEEP [mailto:teep-bounces@ietf.org] On Behalf Of Benjamin Kaduk Sent: Monday, March 26, 2018 6:33 PM To: faibish, sorin Cc: teep ; Dave Thaler ; teep-chairs@= ietf.org Subject: Re: [Teep] IETF 101 agenda requests On Mon, Mar 26, 2018 at 11:12:37PM +0000, faibish, sorin wrote: > We discussed the DDoS in Singapore and we had a presentation on the DDoS: > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat > racker.ietf.org%2Fmeeting%2F100%2Fmaterials%2Fslides-100-saag-int&data > =3D02%7C01%7Cdthaler%40microsoft.com%7C105f96f6b0744e2a276408d593f98cc2% > 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636577622384270342&sdata=3D > 32qt5mT4aXYjJ9gZW%2BFRegXm4GbM%2FWlOpwh6XmnJ84I%3D&reserved=3D0 > er-domain-ddos-mitigations-potentials-challenges-and-solutions-min-suk > -kang/ >=20 > So, I would like to include this usecase as a target for the WG. I=20 > will write a draft related to this usecase. Thanks Wanting it to be a target and writing a draft are both orthogonal to the qu= estion of whether the work is in-charter. (Rechartering to include it woul= d of course be possible, through the normal procedure...) -Ben > ../Sorin >=20 > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > Sent: Friday, March 23, 2018 8:39 AM > To: faibish, sorin > Cc: Dave Thaler ; teep ;=20 > teep-chairs@ietf.org > Subject: Re: [Teep] IETF 101 agenda requests >=20 > Hi Sorin, >=20 > On Thu, Mar 22, 2018 at 09:26:22AM +0000, faibish, sorin wrote: > > New proposed usecase for TEEP WG. > >=20 > > Most recently the frequency and intensity of DDoS attacks from IoT devi= ces increased with attacks almost every day. The reason of the proliferatio= n of DDoS attacks from IoT devices is a result of the lower and maybe inexi= stent security protection of cheap IoT devices that have no security featur= es implemented as this would increase the cost of such devices using any se= curity HW. In the current charter of TEEP there sre 3 usecases and I would = like to add the protectioin against DDoS of IoT as a new usecase: >=20 > On a quick read of the charter, I don't see how this topic would be in sc= ope -- am I missing something that would allow it? >=20 > Thanks, >=20 > Ben >=20 > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i > etf.org%2Fmailman%2Flistinfo%2Fteep&data=3D02%7C01%7Cdthaler%40microsoft > .com%7C105f96f6b0744e2a276408d593f98cc2%7C72f988bf86f141af91ab2d7cd011 > db47%7C1%7C0%7C636577622384270342&sdata=3D1F4dZBFAumiRdEl7G4FYn0bO9VSzFy > k%2BSkxW6cCfesw%3D&reserved=3D0 _______________________________________________ TEEP mailing list TEEP@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fteep&data=3D02%7C01%7Cdthaler%40microsoft.com%7= C105f96f6b0744e2a276408d593f98cc2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C= 0%7C636577622384270342&sdata=3D1F4dZBFAumiRdEl7G4FYn0bO9VSzFyk%2BSkxW6cCfes= w%3D&reserved=3D0 From nobody Tue Mar 27 17:14:36 2018 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A51126D3F; Tue, 27 Mar 2018 17:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 gYXaESQYHFLb; Tue, 27 Mar 2018 17:14:30 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (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 E908F1200C1; Tue, 27 Mar 2018 17:14:29 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2018 17:14:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.48,368,1517904000"; d="scan'208,217"; a="27551120" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga007.fm.intel.com with ESMTP; 27 Mar 2018 17:14:27 -0700 Received: from fmsmsx117.amr.corp.intel.com (10.18.116.17) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 27 Mar 2018 17:14:27 -0700 Received: from crsmsx151.amr.corp.intel.com (172.18.7.86) by fmsmsx117.amr.corp.intel.com (10.18.116.17) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 27 Mar 2018 17:14:26 -0700 Received: from crsmsx102.amr.corp.intel.com ([169.254.2.248]) by CRSMSX151.amr.corp.intel.com ([169.254.3.101]) with mapi id 14.03.0319.002; Tue, 27 Mar 2018 18:14:24 -0600 From: "Wheeler, David M" To: Dave Thaler , Benjamin Kaduk , "faibish, sorin" CC: teep , "teep-chairs@ietf.org" Thread-Topic: [Teep] IETF 101 agenda requests Thread-Index: AdO9Xdcov18dMzNFTtSIcGlRK17eigEYdluQAEWk84AArP0PgAAE50aAABCON7AADuZggAALj1sQ///BsYCAADe8kA== Date: Wed, 28 Mar 2018 00:14:23 +0000 Message-ID: <0627F5240443D2498FAA65332EE46C84367A66E6@CRSMSX102.amr.corp.intel.com> References: <2313358402DBCC4DB2F2DC03CB08BBFEFF050A@MX304CL01.corp.emc.com> <20180323123925.GD25919@kduck.kaduk.org> <2313358402DBCC4DB2F2DC03CB08BBFE0100C5FE@MX304CL01.corp.emc.com> <20180327013301.GN44086@kduck.kaduk.org> <0627F5240443D2498FAA65332EE46C84367A64B7@CRSMSX102.amr.corp.intel.com> <0627F5240443D2498FAA65332EE46C84367A6598@CRSMSX102.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMjA2OTY4NmEtNDFhYy00OTQxLWEyOWItNzM5YzM0M2M4NTUyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IkhyTlhyb2lZS1wvSEw5eWRpbHJEV3VtTnRxZTBoKzBZenRTa21cL0oxa051ND0ifQ== dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [172.18.205.10] Content-Type: multipart/alternative; boundary="_000_0627F5240443D2498FAA65332EE46C84367A66E6CRSMSX102amrcor_" MIME-Version: 1.0 Archived-At: Subject: Re: [Teep] IETF 101 agenda requests X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 00:14:34 -0000 --_000_0627F5240443D2498FAA65332EE46C84367A66E6CRSMSX102amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Now you lost me. To conduct a DDoS attack against an external entity you= don't have to process packets very fast at all. > You, and zillions of other devices like you, sending packets at a slow ra= te, collectively add up to a DDoS attack against a victim. > Sorin's original use case, as I understand it, is about devices being abl= e to conduct DDoS attacks. I see. I wasn't in the presentation, I just briefly looked over the slides.= What I saw in Sorin's use case was not CONDUCTING DDoS attacks, but about = STOPPING DDoS attacks, by implementing a filter on a device, preventing cer= tain types of traffic from exiting the device. See slide 9, where the Admin= and some external trusted party activate policies inside the TEE where a T= EE app is classifying and rate limiting outbound traffic. This slide 9 implies access to the packet stream, which may require special= privileges. Perhaps I misunderstand Sorin's proposal? Perhaps this is a different use c= ase? Thanks, - Dave Wheeler From: Dave Thaler [mailto:dthaler@microsoft.com] Sent: Tuesday, March 27, 2018 11:22 AM To: Wheeler, David M ; Benjamin Kaduk ; faibish, sorin Cc: teep ; teep-chairs@ietf.org Subject: RE: [Teep] IETF 101 agenda requests -----Original Message----- From: Wheeler, David M > Sent: Tuesday, March 27, 2018 10:37 AM To: Dave Thaler >; Benj= amin Kaduk >; faibish, sorin > Cc: teep >; teep-chairs@ietf.org Subject: RE: [Teep] IETF 101 agenda requests > For it to not be orthogonal, one would have to argue how/why it affects t= he OTrP protocol itself. OK, let me try to present the argument :) Excellent, thanks for doing this. A TEE application, when provisioned into a device, will require certain res= ources of the device. These resources will definitely include storage, RAM, and possibly some mea= sure of CPU time. OTrP //should// have some policy hooks that allow a device/device user/owne= r to define what are acceptable limits of resource consumption for a TEE ap= plication. For example, as long as a TEE app consumes less than 100MB RAM, = it is OK to install (perhaps because I only have 250MB allocated to the TEE= , and I don't want ALL the memory consumed by one app). This policy should be attached to the TEE application at install time, be i= nterpreted by the OTrP Agent, and be evaluated as an intersection of the ap= plication characteristics along with the device/platform/TEE policy. Now, once these simple TEE app characteristics (memory, storage, CPU time) = are considered, there are other characteristics that a TEE app might want/n= eed access to. Here are some examples: - device monotonic counter: some platforms have limits as to how often the = MC can be updated, and the entire life of the MC, based on flash wear level= ing. Restricting how a TEE app can use a MC is a policy decision for the de= vice/TEE - secure key store: there may be limits to the number of keys that can be s= tored within the TEE in a replay protected non-volatile secure storage area= . Access to this might be based on a TEE policy - other trusted HW devices: some devices on the platform may solely be acce= ssible inside the TEE, others might be configurable to be in the TEE or out= side. And access to these devices might need to be restricted. For example,= access to certain FW flash areas for secure update, access to the Safety I= sland on certain industrial parts, and of course access to the network, esp= ecially in a promiscuous mode. Additionally, I might configure my device so that //certain// service provi= ders are trusted to a level where they get access to //all// these types of= special resources (I trust those service providers) and other service prov= iders do not get any such access, or very limited access. One might argue, = how can you enforce this? The TEE manifest that includes the characteristic= s and requirements could lie - yes, but then they would be found out, becau= se their app is signed, and they would be banned by the TSM. All of the above makes sense to me. So, now back to our proposed use case: For the DDoS application to work, it must be able to get access to the lowe= st packet level of the network stack, and be able to process packets at lin= e speed. Now you lost me. To conduct a DDoS attack against an external entity you d= on't have to process packets very fast at all. You, and zillions of other = devices like you, sending packets at a slow rate, collectively add up to a = DDoS attack against a victim. This requirement has significant draws on the capability of the TEE - avail= able access to the network device, amount of memory consumed for packet buf= fers, amount of processing to keep up with packets, ... Sorin's original use case, as I understand it, is about devices being able = to conduct DDoS attacks. Preventing TEE apps from doing so doesn't address= that use case, if REE apps on the same devices can still do the attacks, e= specially since that's how such attacks already work. Some TEEs may not even be //able// to provide such services. Other TEEs may= restrict it. OTrP should be able to convey, during install, the rich set of application = requirements the TEE app needs to properly run, and this should be able to = be interpreted against the policy and capabilities of the TEE as interprete= d by the OTrP agent (or equivalent manager in the TEE). Again, I don't see this as addressing the DDoS use case. I sounds like yo= u're hinting at a separate use case which isn't about DDoS at all, maybe yo= u can expand on that? For this reason, I like this use case, because it represents a non-trivial = application (not just an App computing pi), with interesting and complex re= quirements on the HW, environment, and other policy (like privacy - do I wa= nt an app that sees ALL of my network traffic and possibly be able to evalu= ate my network flows?) How should OTrP handle the communication of TEE Application requirements? W= hat policy language is built into the protocol? Does the policy language in= clude some privacy atoms, as well as TEE resource atoms? What other charact= eristics can be / should be represented by the policy language? What are th= e limits of policy interpretation by the OTrP agent? These, I believe are v= aluable questions to consider. Perhaps we get to the point that it is too c= omplex for our first version, but I would like us to have the conversation = and consider it. And then, at least, have some insight to where such a desc= riptive policy language might intersect with the protocol (at some point). Your last paragraph does sound potentially relevant and useful to discuss (= though again, not connected to any DDoS use case in any way I can see yet). Thanks, - Dave Wheeler -----Original Message----- From: Dave Thaler [mailto:dthaler@microsoft.com] Sent: Tuesday, March 27, 2018 9:34 AM To: Wheeler, David M >; Benjamin Kaduk >; faibish, sor= in > Cc: teep >; teep-chairs@ietf.org Subject: RE: [Teep] IETF 101 agenda requests On slide 6 of the "Problem Statement" slides there were three use cases for= Trusted Applications (as opposed to use cases for OTrP or TEEP per se), of= which one was IoT. The Mirai botnet attack used the REE (not a TEE) of devices to conduct atta= cks against an external entity. Since TEEP is about TEE provisioning, not = REE provisioning, TEEP is not directly applicable to controlling how/whethe= r malware can be installed in the REE. I think what David's saying is that a provisioned TEE application could hav= e functionality to detect/mitigate something malicious that it detects an R= EE app is doing. That's true, just like the TEE application could do anyth= ing else (compute pi, etc.) but we shouldn't try to enumerate every operati= on that a TEE application might try to do, just things that introduce requi= rements on OTrP. In the "TEEP Use Cases" slides for IETF 101, these are use cases for OTrP (= as opposed to use cases for Trusted Apps in general). In the discussion around slide 6, we agreed that Rich Apps are largely orth= ogonal because they don't introduce new requirements on the OTrP protocol. I think Ben's saying this is simil= arly orthogonal. For it to not be orthogonal, one would have to argue how/why it affects the= OTrP protocol itself. If there is such an argument, that would be a good = way to continue this discussion. If not, or if we don't know if there is, = then it's orthogonal until such an argument is provided. Dave -----Original Message----- From: Wheeler, David M > Sent: Tuesday, March 27, 2018 8:44 AM To: Benjamin Kaduk >; faibish, sorin > Cc: teep >; Dave Thaler >; teep-chairs@ietf.org Subject: RE: [Teep] IETF 101 agenda requests Ben, I agree with you regarding the question of charter, however, I think (pleas= e correct if I misunderstand) what Sorin is proposing is to use the DDoS ex= ample as a use case to evaluate if OTrP has considered the appropriate rela= tionships and entities within the protocol that would allow the proposed DD= oS solution to be implemented. Our charter does state that "the solution approach must take a wide range o= f TEE and relevant technologies" and the architecture document includes "re= levant use cases." Since the DDoS proposal includes an implementation where= a TEE application implements a set of filtering policies, I believe it is = relevant. I think it is a very interesting use case, since it expands beyond a simple= Device-User to Service-Provider situation, and creates a more complex inte= raction for the application - especially the interaction of the trusted app= lication to aspects of the device itself (i.e. filtering outgoing packets).= Is our policy for accepting TEE applications rich enough (or at least exte= nsible enough) to enable a device/user to implement controls on what applic= ations are allowed to do, perhaps even based on the service provider instal= ling those applications. I believe it is in our best interest to evaluate it, and the implications o= f such TEE applications. We can still come to the conclusion that some aspe= cts of supporting such a use case may be out-of-scope, but it will give us = concrete information to point to regarding what is exactly out-of-scope, wh= y it breeches our scope, and perhaps direct future additions/expansions to = the protocol. Thanks, Dave Wheeler -----Original Message----- From: TEEP [mailto:teep-bounces@ietf.org] On Behalf Of Benjamin Kaduk Sent: Monday, March 26, 2018 6:33 PM To: faibish, sorin > Cc: teep >; Dave Thaler >; teep-chairs@ietf.org Subject: Re: [Teep] IETF 101 agenda requests On Mon, Mar 26, 2018 at 11:12:37PM +0000, faibish, sorin wrote: > We discussed the DDoS in Singapore and we had a presentation on the DDoS: > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat > racker.ietf.org%2Fmeeting%2F100%2Fmaterials%2Fslides-100-saag-int&data > =3D02%7C01%7Cdthaler%40microsoft.com%7C105f96f6b0744e2a276408d593f98cc2% > 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636577622384270342&sdata=3D > 32qt5mT4aXYjJ9gZW%2BFRegXm4GbM%2FWlOpwh6XmnJ84I%3D&reserved=3D0 > er-domain-ddos-mitigations-potentials-challenges-and-solutions-min-suk > -kang/ > > So, I would like to include this usecase as a target for the WG. I > will write a draft related to this usecase. Thanks Wanting it to be a target and writing a draft are both orthogonal to the qu= estion of whether the work is in-charter. (Rechartering to include it woul= d of course be possible, through the normal procedure...) -Ben > ../Sorin > > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > Sent: Friday, March 23, 2018 8:39 AM > To: faibish, sorin > > Cc: Dave Thaler >; te= ep >; > teep-chairs@ietf.org > Subject: Re: [Teep] IETF 101 agenda requests > > Hi Sorin, > > On Thu, Mar 22, 2018 at 09:26:22AM +0000, faibish, sorin wrote: > > New proposed usecase for TEEP WG. > > > > Most recently the frequency and intensity of DDoS attacks from IoT devi= ces increased with attacks almost every day. The reason of the proliferatio= n of DDoS attacks from IoT devices is a result of the lower and maybe inexi= stent security protection of cheap IoT devices that have no security featur= es implemented as this would increase the cost of such devices using any se= curity HW. In the current charter of TEEP there sre 3 usecases and I would = like to add the protectioin against DDoS of IoT as a new usecase: > > On a quick read of the charter, I don't see how this topic would be in sc= ope -- am I missing something that would allow it? > > Thanks, > > Ben > > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i > etf.org%2Fmailman%2Flistinfo%2Fteep&data=3D02%7C01%7Cdthaler%40microsoft > .com%7C105f96f6b0744e2a276408d593f98cc2%7C72f988bf86f141af91ab2d7cd011 > db47%7C1%7C0%7C636577622384270342&sdata=3D1F4dZBFAumiRdEl7G4FYn0bO9VSzFy > k%2BSkxW6cCfesw%3D&reserved=3D0 _______________________________________________ TEEP mailing list TEEP@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fteep&data=3D02%7C01%7Cdthaler%40microsoft.com%7= C105f96f6b0744e2a276408d593f98cc2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C= 0%7C636577622384270342&sdata=3D1F4dZBFAumiRdEl7G4FYn0bO9VSzFyk%2BSkxW6cCfes= w%3D&reserved=3D0 --_000_0627F5240443D2498FAA65332EE46C84367A66E6CRSMSX102amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> Now you= lost me.  To conduct a DDoS attack against an external entity you don= ’t have to process packets very fast at all. 

> You, and zillions of other devices like you,= sending packets at a slow rate, collectively add up to a DDoS attack again= st a victim.

 

> Sorin’s original use case, as I understand it, is a= bout devices being able to conduct DDoS attacks. 

 =

I see. I wasn’t in= the presentation, I just briefly looked over the slides. What I saw in Sor= in’s use case was not CONDUCTING DDoS attacks, but about STOPPING DDo= S attacks, by implementing a filter on a device, preventing certain types of traffic from exiting the device. See slide 9, = where the Admin and some external trusted party activate policies inside th= e TEE where a TEE app is classifying and rate limiting outbound traffic.

 =

This slide 9 implies acc= ess to the packet stream, which may require special privileges.<= /span>

 =

Perhaps I misunderstand = Sorin’s proposal? Perhaps this is a different use case?

Thanks,

- = ;       Dave Wheeler

 

From: Dav= e Thaler [mailto:dthaler@microsoft.com]
Sent: Tuesday, March 27, 2018 11:22 AM
To: Wheeler, David M <david.m.wheeler@intel.com>; Benjamin Kad= uk <kaduk@mit.edu>; faibish, sorin <Faibish.Sorin@dell.com>
Cc: teep <teep@ietf.org>; teep-chairs@ietf.org
Subject: RE: [Teep] IETF 101 agenda requests

 

 

 

-----Original Message-= ----
From: Wheeler, David M <dav= id.m.wheeler@intel.com>
Sent: Tuesday, March 27, 2018 10:37 AM
To: Dave Thaler <dthaler@micros= oft.com>; Benjamin Kaduk <kaduk@= mit.edu>; faibish, sorin <Faibish.Sorin@dell.com>
Cc: teep <teep@ietf.org>; teep-chairs@ietf.org
Subject: RE: [Teep] IETF 101 agenda requests

 

> For it to not be = orthogonal, one would have to argue how/why it affects the OTrP protocol it= self. 

 

OK, let me try to pres= ent the argument :)

 

Excellent, thanks for= doing this.

 

A TEE application, whe= n provisioned into a device, will require certain resources of the device.<= o:p>

These resources will d= efinitely include storage, RAM, and possibly some measure of CPU time.=

OTrP //should// have s= ome policy hooks that allow a device/device user/owner to define what are a= cceptable limits of resource consumption for a TEE application. For example= , as long as a TEE app consumes less than 100MB RAM, it is OK to install (perhaps because I only have 250MB all= ocated to the TEE, and I don't want ALL the memory consumed by one app).

 

This policy should be = attached to the TEE application at install time, be interpreted by the OTrP= Agent, and be evaluated as an intersection of the application characterist= ics along with the device/platform/TEE policy.

 

Now, once these simple= TEE app characteristics (memory, storage, CPU time) are considered, there = are other characteristics that a TEE app might want/need access to. Here ar= e some examples:

- device monotonic cou= nter: some platforms have limits as to how often the MC can be updated, and= the entire life of the MC, based on flash wear leveling. Restricting how a= TEE app can use a MC is a policy decision for the device/TEE

 

- secure key store: th= ere may be limits to the number of keys that can be stored within the TEE i= n a replay protected non-volatile secure storage area. Access to this might= be based on a TEE policy

 

- other trusted HW dev= ices: some devices on the platform may solely be accessible inside the TEE,= others might be configurable to be in the TEE or outside. And access to th= ese devices might need to be restricted. For example, access to certain FW flash areas for secure update, access to= the Safety Island on certain industrial parts, and of course access to the= network, especially in a promiscuous mode.

 

Additionally, I might = configure my device so that //certain// service providers are trusted to a = level where they get access to //all// these types of special resources (I = trust those service providers) and other service providers do not get any such access, or very limited access. One = might argue, how can you enforce this? The TEE manifest that includes the c= haracteristics and requirements could lie - yes, but then they would be fou= nd out, because their app is signed, and they would be banned by the TSM.

 

All of the above make= s sense to me.

 

So, now back to our pr= oposed use case:

For the DDoS applicati= on to work, it must be able to get access to the lowest packet level of the= network stack, and be able to process packets at line speed.

 

Now you lost me.  To conduct a DDoS attack a= gainst an external entity you don’t have to process packets very fast= at all.  You, and zillions of other devices like you, sending packets= at a slow rate, collectively add up to a DDoS attack against a victim.

 

This requirement has s= ignificant draws on the capability of the TEE - available access to the net= work device, amount of memory consumed for packet buffers, amount of proces= sing to keep up with packets, ...

 

Sorin’s origina= l use case, as I understand it, is about devices being able to conduct DDoS= attacks.  Preventing TEE apps from doing so doesn’t address tha= t use case, if REE apps on the same devices can still do the attacks, especially since that’s how such attacks already wor= k.

 

Some TEEs may not even= be //able// to provide such services. Other TEEs may restrict it.

 

OTrP should be able to= convey, during install, the rich set of application requirements the TEE a= pp needs to properly run, and this should be able to be interpreted against= the policy and capabilities of the TEE as interpreted by the OTrP agent (or equivalent manager in the TEE). <= o:p>

 

Again, I don’t = see this as addressing the DDoS use case.   I sounds like youR= 17;re hinting at a separate use case which isn’t about DDoS at all, m= aybe you can expand on that?

 

For this reason, I lik= e this use case, because it represents a non-trivial application (not just = an App computing pi), with interesting and complex requirements on the HW, = environment, and other policy (like privacy - do I want an app that sees ALL of my network traffic and possibl= y be able to evaluate my network flows?)

 

How should OTrP handle= the communication of TEE Application requirements? What policy language is= built into the protocol? Does the policy language include some privacy ato= ms, as well as TEE resource atoms? What other characteristics can be / should be represented by the policy languag= e? What are the limits of policy interpretation by the OTrP agent? These, I= believe are valuable questions to consider. Perhaps we get to the point th= at it is too complex for our first version, but I would like us to have the conversation and consider it. And= then, at least, have some insight to where such a descriptive policy langu= age might intersect with the protocol (at some point).

 

Your last paragraph d= oes sound potentially relevant and useful to discuss (though again, not con= nected to any DDoS use case in any way I can see yet).

 

Thanks,

- Dave Wheeler

 

-----Original Message-----

From: Dave Thaler [mailto:dth= aler@microsoft.com]

Sent: Tuesday, March 27, 2018 9:34 AM<= /p>

To: Wheeler, David M <= david.m.wheeler@intel.com>; Benjamin Kaduk <ka= duk@mit.edu>; faibish, sorin <Faibish.Sorin@dell.com>

Cc: teep <teep@ietf.org= >; teep-chairs@ietf.org

Subject: RE: [Teep] IETF 101 agenda requests=

 

On slide 6 of the "Problem Statement" s= lides there were three use cases for Trusted Applications (as opposed to us= e cases for OTrP or TEEP per se), of which one was IoT.

 

The Mirai botnet attack used the REE (not a TEE) = of devices to conduct attacks against an external entity.  Since TEEP = is about TEE provisioning, not REE provisioning, TEEP is not directly appli= cable to controlling how/whether malware can be installed in the REE.

 

I think what David's saying is that a provisioned= TEE application could have functionality to detect/mitigate something mali= cious that it detects an REE app is doing.  That's true, just like the= TEE application could do anything else (compute pi, etc.) but we shouldn't try to enumerate every operation that = a TEE application might try to do, just things that introduce requirements = on OTrP.

 

In the "TEEP Use Cases" slides for IETF= 101, these are use cases for OTrP (as opposed to use cases for Trusted App= s in general).

In the discussion around slide 6, we agreed that = Rich Apps are largely orthogonal because they don't introduce

new requirements on the OTrP protocol.  = ; I think Ben's saying this is similarly orthogonal.

 

For it to not be orthogonal, one would have to ar= gue how/why it affects the OTrP protocol itself.  If there is such an = argument, that would be a good way to continue this discussion.  If no= t, or if we don't know if there is, then it's orthogonal until such an argument is provided.

 

Dave

 

-----Original Message-----

From: Wheeler, David M <david.m.wheeler@intel.com>

Sent: Tuesday, March 27, 2018 8:44 AM<= /p>

To: Benjamin Kaduk <kaduk@mit.edu<= /span>>; faibish, sorin <Faibish.Sorin@dell.= com>

Cc: teep <teep@ietf.org= >; Dave Thaler <dthaler@microsoft.com= >; teep-chairs@ietf.org

Subject: RE: [Teep] IETF 101 agenda requests=

 

Ben,

I agree with you regarding the question of charte= r, however, I think (please correct if I misunderstand) what Sorin is propo= sing is to use the DDoS example as a use case to evaluate if OTrP has consi= dered the appropriate relationships and entities within the protocol that would allow the proposed DDoS soluti= on to be implemented.

 

Our charter does state that "the solution ap= proach must take a wide range of TEE and relevant technologies" and th= e architecture document includes "relevant use cases." Since the = DDoS proposal includes an implementation where a TEE application implements a set of filtering policies, I believe it is relevant.

 

I think it is a very interesting use case, since = it expands beyond a simple Device-User to Service-Provider situation, and c= reates a more complex interaction for the application - especially the inte= raction of the trusted application to aspects of the device itself (i.e. filtering outgoing packets). Is our = policy for accepting TEE applications rich enough (or at least extensible e= nough) to enable a device/user to implement controls on what applications a= re allowed to do, perhaps even based on the service provider installing those applications.

 

I believe it is in our best interest to evaluate = it, and the implications of such TEE applications. We can still come to the= conclusion that some aspects of supporting such a use case may be out-of-s= cope, but it will give us concrete information to point to regarding what is exactly out-of-scope, why it bre= eches our scope, and perhaps direct future additions/expansions to the prot= ocol.

 

Thanks,

Dave Wheeler

 

 

-----Original Message-----

From: TEEP [mailto:teep-bounc= es@ietf.org] On Behalf Of Benjamin Kaduk

Sent: Monday, March 26, 2018 6:33 PM

To: faibish, sorin <Faibi= sh.Sorin@dell.com>

Cc: teep <teep@ietf.org= >; Dave Thaler <dthaler@microsoft.com= >; teep-chairs@ietf.org

Subject: Re: [Teep] IETF 101 agenda requests=

 

On Mon, Mar 26, 2018 at 11:12:37PM +0000, fai= bish, sorin wrote:

> We discussed the DDoS in Singapore and we ha= d a presentation on the DDoS:

> https://na01.safelink= s.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat

> racker.ietf.org%2Fmeeting%2F100%2Fmaterials%= 2Fslides-100-saag-int&data

> =3D02%7C01%7Cdthaler%40microsoft.com%7C105f9= 6f6b0744e2a276408d593f98cc2%

> 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7= C636577622384270342&sdata=3D

> 32qt5mT4aXYjJ9gZW%2BFRegXm4GbM%2FWlOpwh6XmnJ= 84I%3D&reserved=3D0

> er-domain-ddos-mitigations-potentials-challe= nges-and-solutions-min-suk

> -kang/

>

> So, I would like to include this usecase as = a target for the WG. I

> will write a draft related to this usecase. = Thanks

 

Wanting it to be a target and writing a draft are= both orthogonal to the question of whether the work is in-charter.  (= Rechartering to include it would of course be possible, through the normal<= o:p>

procedure...)

 

-Ben

 

> ../Sorin

>

> -----Original Message-----

> From: Benjamin Kaduk [mailto:kad= uk@mit.edu]

> Sent: Friday, March 23, 2018 8:39 AM

> To: faibish, sorin <f= aibish_sorin@emc.com>

> Cc: Dave Thaler <dtha= ler@microsoft.com>; teep <teep@ietf.org= >;

> teep-chairs@ietf.org

> Subject: Re: [Teep] IETF 101 agenda requests=

>

> Hi Sorin,

>

> On Thu, Mar 22, 2018 at 09:26:22AM +0000= , faibish, sorin wrote:

> > New proposed usecase for TEEP WG.<= /o:p>

> >

> > Most recently the frequency and intensi= ty of DDoS attacks from IoT devices increased with attacks almost every day= . The reason of the proliferation of DDoS attacks from IoT devices is a res= ult of the lower and maybe inexistent security protection of cheap IoT devices that have no security features implemented= as this would increase the cost of such devices using any security HW. In = the current charter of TEEP there sre 3 usecases and I would like to add th= e protectioin against DDoS of IoT as a new usecase:

>

> On a quick read of the charter, I don't see = how this topic would be in scope -- am I missing something that would allow= it?

>

> Thanks,

>

> Ben

>

> ____________________________________________= ___

> TEEP mailing list

> TEEP@ietf.org

> https://na01.safelink= s.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i

> etf.org%2Fmailman%2Flistinfo%2Fteep&data= =3D02%7C01%7Cdthaler%40microsoft

> .com%7C105f96f6b0744e2a276408d593f98cc2%7C72= f988bf86f141af91ab2d7cd011

> db47%7C1%7C0%7C636577622384270342&sdata= =3D1F4dZBFAumiRdEl7G4FYn0bO9VSzFy

> k%2BSkxW6cCfesw%3D&reserved=3D0

 

_______________________________________________

TEEP mailing list

TEEP@ietf.org

https://na01.safelinks.pro= tection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%= 2Fteep&data=3D02%7C01%7Cdthaler%40microsoft.com%7C105f96f6b0744e2a27640= 8d593f98cc2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636577622384270342= &sdata=3D1F4dZBFAumiRdEl7G4FYn0bO9VSzFyk%2BSkxW6cCfesw%3D&reserved= =3D0

--_000_0627F5240443D2498FAA65332EE46C84367A66E6CRSMSX102amrcor_--