From nobody Fri Dec 1 05:16:47 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15148128D3E; Fri, 1 Dec 2017 05:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=ericsson.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 Gezm9FO531xq; Fri, 1 Dec 2017 05:16:42 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 21A73128BBB; Fri, 1 Dec 2017 05:16:40 -0800 (PST) X-AuditID: c1b4fb2d-d6fff700000036aa-81-5a215637fa56 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3E.C0.13994.736512A5; Fri, 1 Dec 2017 14:16:39 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 1 Dec 2017 14:16:38 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QZKEGlploxq4ldQ3gS//CLtOcYnaMEnFYmCtDqx/xO8=; b=Uuj1hAvHSpDI9aC2A/EAqubD2PRmk+V0AxFlB2Ufn59SJqeY23ylLxx+DCVCNL7quQ0Aljv83gZLtmFp/sR2m5P1irIhWN9uPSTFQOyhMBhIrSYFjrkZikEIRhuNJwUoRuGhZG+LaPjYA0RgxhT2YpKMCyKYwJum7mumL/peK/A= Received: from DB5PR0701MB2005.eurprd07.prod.outlook.com (10.167.228.147) by DB5PR0701MB2005.eurprd07.prod.outlook.com (10.167.228.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Fri, 1 Dec 2017 13:16:37 +0000 Received: from DB5PR0701MB2005.eurprd07.prod.outlook.com ([fe80::cded:d65b:8eb2:a1bd]) by DB5PR0701MB2005.eurprd07.prod.outlook.com ([fe80::cded:d65b:8eb2:a1bd%14]) with mapi id 15.20.0282.006; Fri, 1 Dec 2017 13:16:37 +0000 From: John Mattsson To: "aland@deployingradius.com" , Mohit Sethi M , Bernard Aboba , "Jim Schaad" , "reap@ietf.org" , "saag@ietf.org" , "emu@ietf.org" Thread-Topic: [Reap] EAP - TLS 1.3 Thread-Index: AQHTaqadALXEaMxOiE21NMZBzoSXMg== Date: Fri, 1 Dec 2017 13:16:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.28.0.171108 x-originating-ip: [82.214.47.185] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR0701MB2005; 6:rTJCAuBmtvGfpDlfojfITW33vvYS6Nkgx6K+IlXtAICXvrxrJCM45/L8elTun3eeMyo+wATbs610LEckD9zJQ5QtsCoVZPwDafpSFyzGLFjcMhkl8rOKLhqywXJcQB7NEaWymUpAIGePRIB0YdIzLko3CMtjEWN5OYkinUBOwQn0lC83AxYiP2kxCNbJMYBwMG/AuDWpRxCOtDKHOMFUzbqE/JhA29+a4VcQeQwb3l8DTJeijeZke1gNU9nl7z4IyGT5199RpMUhvrci3jJTQy+vUASP7BhSez3fU/Da4IAnxgEY/43B93CAnA66soiF/W3IwM5uWw0rS6OqfKWXl0IMPqBzFSw9zBviTQIE3rw=; 5:vrdpHJAng3tzT4jCrlzK7Cq0UkzPXaZLJNDN6A3BYUfaj7e2xz1hMBuI0uiphbVQmnEuoqAeN2O6rgBocrYQLs/pCkGqqydUwU2SkYzt+/m6uBWwb7wqpGlEPvBAmseQncKkU/e7R0axOWRWI10fYy+aYRPCa0gNQr9iuX4gvZg=; 24:1GRIbeILISUZPx05HhT1MVZPv4gvdFEoKN0170oBAGpRzIb1U3KbKB6XPkRDwu2dBVEZb3SfybwnmJWMEJBm3o02dQJnS663yn53HNIoaA8=; 7:SxpDMqfA864rApIaRyf/EhzVr/lnTMt6LN1zLzufIM1+Fix8nuLs+Z5tgdyivkqkfbnayZbYFqQ+1/TsPBT/DklUOQMF9jhW27Y6qMW6wBxbNn/K1IGRII5SIOp/78UN3q1Sp9V7N6QWNjtcMzp7o40wqg8yTl8AAdh9Fc7E41t2LXMu3nbKF3rtM0kWxH4mOETo0LELDaL+MaI1qpuUcQuHbrBgGCPiFu8VdEkpAUkc+py34faORafZWzas5JmT x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 27115dd0-9085-42e6-b432-08d538bdc064 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:DB5PR0701MB2005; x-ms-traffictypediagnostic: DB5PR0701MB2005: authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231022)(10201501046)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011); SRVR:DB5PR0701MB2005; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB5PR0701MB2005; x-forefront-prvs: 05087F0C24 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(376002)(366004)(346002)(189002)(199003)(24454002)(2501003)(316002)(110136005)(5660300001)(66066001)(83506002)(2906002)(36756003)(5250100002)(229853002)(25786009)(86362001)(58126008)(6436002)(81166006)(6506006)(8676002)(6486002)(105586002)(81156014)(53936002)(102836003)(97736004)(82746002)(2201001)(478600001)(2900100001)(3846002)(3660700001)(106356001)(6116002)(561944003)(99286004)(8936002)(83716003)(33656002)(14454004)(189998001)(3280700002)(68736007)(54356011)(305945005)(39060400002)(7736002)(6246003)(101416001)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR0701MB2005; H:DB5PR0701MB2005.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4DDF76905BFF5F409B7709A38BAE9C0E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 27115dd0-9085-42e6-b432-08d538bdc064 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2017 13:16:36.9811 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0701MB2005 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SWUwTURiFvZ3pdGhscilF/iCYtPFBkM0lWo0RfTApYrW+qCEhUmECKFs6 lYBPTQFFFqGCIoVSNQVZZA2ILCKibBolYgwGkD0StrhgQmS17dTEt++ec/4/595cmhA38N3p 6Dgto4lTx8goIVl4qfm87+EL0pCAvimxXL+sF8jrOrYIeU9tNSmvKlih5B8qekl5fs5t3glK UV9cQClSu1NJRYvxq0BhsfzhqcgQ4bEIJiY6kdH4Hw8TRqXUjVEJZcqk9OFSQofKgzOQEw34 IOR8/E5kICEtxq8RmLMe8bhDLwL93ChpO5A4m4CWlA4B55h4MGv45Zj5hsCQ3ci3LaNwAJja dZTNkOASHnzZKhfYDBcshQef5ykbS7AMJlLWEcd+oK8f5NmYxLvhjnnVziIcCCUjRnse4R2w 8vapXSewG+h/V/C55hgs7QMEx64wN71p112tOzdbFnicLoXS7vuOvCcMmjORrRzgNwIYHxp1 GH7QZFhCHCuhZrmW5EJlCF5mTJKc4QN9pveORqGQllbgGI6H9o4aRyYIusYyCG7YQsCAaYji DA8Yan3h2DrDh5tNs/Z+YszAk+o0lIt8jf9dz4hoK3tBbas/JytgKeUxn2Mp5GdOCoz2V3KG /sIZ8iHiVyJXlmHZ2Mj9B/wYTXQ4y8bH+cUx2gZk/UmvGtd8n6OqhZNdCNNItl1UoZKGiPnq RDY5tgsBTcgkotCzVkkUoU6+wWjiL2uuxzBsF9pJkzI3UX+QKESMI9Va5hrDJDCafy6PdnLX Iefmc52q8bDByKt7Ww1320QttzZmB8cX8opHgn36j74by6rKa9R3mr3SD9WH9lickxuYDqVk 4+Janj53yq2oL3t6Ln74SGWAKsmzLSC8ik738N/wTlj9qVtXbpPUFwWemn925czSPQKbdDKX cK1Uvyj5cZpZq/m0y1hmztmzOCEj2Sj1Pm9Cw6r/AmnbLXxFAwAA Archived-At: Subject: Re: [saag] [Reap] EAP - TLS 1.3 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 13:16:45 -0000 VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIEFsYW4uIFZlcnkgaGVscGZ1bC4gU2VlIGFuc3dlcnMg YW5kIGNvbW1lbnRzIGJlbG93Og0KDQpPbiBOb3YgMTYsIDIwMTcsIEFsYW4gRGVLb2sgd3JvdGU6 DQoNCj5UaGF0J3MgZ29vZC4gIEJ1dCBhcyBCZXJuYXJkIHBvaW50cyBvdXQsIHRoZXJlJ3Mgbm8g bmVlZCB0byBjaGFuZ2UNCj5FQVAtVExTLiAgWW91IGNhbiBqdXN0IHVzZSBUTFMgMS4zLg0KDQpJ IGRvbuKAmXQgYWdyZWUgd2l0aCB0aGF0LCBzZWUgY29uY3JldGUgZGV0YWlscyBiZWxvdy4NCg0K DQo+SG93IHNvPyA1MjE2IHNheXMgKGVzc2VudGlhbGx5KSAiZW5jYXBzdWxhdGUgVExTIHdpdGhp biBFQVAiLiBIb3csIGV4YWN0bHksID5kb2VzIHRoaXMgY2hhbmdlIHdpdGggVExTIDEuMz8NCg0K SWYgUkZDNTIxNiBhY3R1YWxseSBzYWlkIHRoYXQgaXQgd291bGQgYmUgbGVzcyBvZiBhIHByb2Js ZW0sIGJ1dCBSRkM1MjE2IGhhcyBhIGxhcmdlIGFtb3VudCBvZiBub3JtYXRpdmUgdGVybWlub2xv Z3kgdGhhdCBpcyBjb3JyZWN0IGZvciBUTFMgMS4wIC0gMS4yLCBidXQgd3JvbmcgZm9yIFRMUyAx LjMuIEp1c3QgbG9va2luZyBxdWlja2x5IGF0IHRoZSBiYXNlIGNhc2UgaW4gUkZDNTIxNiAoU2Vj dGlvbiAyLjEuMS4pOg0KDQoidW50aWwgdGhlIGNoYW5nZV9jaXBoZXJfc3BlYyBtZXNzYWdlIg0K KEluIFRMUyAxLjMgY2hhbmdlX2NpcGhlcl9zcGVjIGlzIGFuIG9wdGluYWwgZHVtbXkgcmVjb3Jk IG9ubHkgdXNlZCBmb3IgTWlkZGxlYm94IGNvbXBhdGliaWxpdHkpLg0KDQoiYSBzZXJ2ZXJfaGVs bG9fZG9uZSBoYW5kc2hha2UgbWVzc2FnZSBNVVNUIGJlIHRoZSBsYXN0IGhhbmRzaGFrZSBtZXNz YWdlIGVuY2Fwc3VsYXRlZCBpbiB0aGlzIEVBUC1SZXF1ZXN0IHBhY2tldC4iDQooc2VydmVyX2hl bGxvX2RvbmUgaXMgdXNlZCBpbiBUTFMgMS4zKS4NCg0KImEgVExTIHNlcnZlcl9rZXlfZXhjaGFu Z2UgaGFuZHNoYWtlIG1lc3NhZ2UgTVVTVCBhbHNvIGJlIGluY2x1ZGVkIg0KKHNlcnZlcl9rZXlf ZXhjaGFuZ2UgaXMgdXNlZCBpbiBUTFMgMS4zKS4NCg0KIk1VU1QgZW5jYXBzdWxhdGUgb25lIG9y IG1vcmUgVExTIHJlY29yZHMgY29udGFpbmluZyBhIFRMUyBjbGllbnRfa2V5X2V4Y2hhbmdlLCBj aGFuZ2VfY2lwaGVyX3NwZWMiDQooY2xpZW50X2tleV9leGNoYW5nZSBpcyB1c2VkIGluIFRMUyAx LjMpLg0KDQoidGhlIHBlZXIgTVVTVCBzZW5kIG9ubHkgdGhlIGNoYW5nZV9jaXBoZXJfc3BlYyIN CihzZWUgYWJvdmUpDQoNCkVBUC1UTFMgd2l0aCBUTFMgMS4zIHdvdWxkIGJyZWFrIGEgX2xhcmdl XyBhbW91bnQgb2YgTVVTVCBpbiBSRkM1MjE2Lg0KDQoNCj5XaGF0LCBleGFjdGx5IGlzIGRpZmZl cmVudCB3aXRoIHRoZSBtZXNzYWdlIGZsb3dzIGluIEVBUC1UTFMgd2hlbiBUTFMgMS4zIGlzID51 c2VkPw0KDQpXaGlsZSB0aGUgbWVzc2FnZSBmbG93cyBhcmUgZXhhY3RseSB0aGUgc2FtZSBpbiBU TFMgMS4wLCBUTFMgMS4xLCBhbmQgVExTIDEuMg0KDQogICAgIENsaWVudEhlbGxvICAgICAgICAg ICAgICAgICAgLS0tLS0tLS0+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBTZXJ2ZXJIZWxsbw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBDZXJ0aWZpY2F0ZSoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2VydmVyS2V5RXhjaGFuZ2UqDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2VydGlmaWNhdGVSZXF1ZXN0 Kg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LS0tLS0tLS0gICAgICBTZXJ2 ZXJIZWxsb0RvbmUNCiAgICAgIENlcnRpZmljYXRlKg0KICAgICAgQ2xpZW50S2V5RXhjaGFuZ2UN CiAgICAgIENlcnRpZmljYXRlVmVyaWZ5Kg0KICAgICAgW0NoYW5nZUNpcGhlclNwZWNdDQogICAg ICBGaW5pc2hlZCAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbQ2hhbmdlQ2lwaGVyU3BlY10NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tLS0tLS0tICAgICAgICAgICAgIEZpbmlz aGVkDQoNClRoZSBtZXNzYWdlIGZsb3cgYW5kIGl0cyBjb250ZW50IGlzIGNvbXBsZXRlbHkgZGlm ZmVyZW50IGluIFRMUyAxLjMNCg0KS2V5ICBeIENsaWVudEhlbGxvDQpFeGNoIHwgKyBrZXlfc2hh cmUqDQogICAgIHwgKyBzaWduYXR1cmVfYWxnb3JpdGhtcyoNCiAgICAgfCArIHBza19rZXlfZXhj aGFuZ2VfbW9kZXMqDQogICAgIHYgKyBwcmVfc2hhcmVkX2tleSogICAgICAgICAtLS0tLS0tLT4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBT ZXJ2ZXJIZWxsbyAgXiBLZXkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICsga2V5X3NoYXJlKiAgfCBFeGNoDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKyBwcmVfc2hhcmVkX2tleSogIHYNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHtFbmNyeXB0ZWRFeHRlbnNp b25zfSAgXiAgU2VydmVyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB7Q2VydGlmaWNhdGVSZXF1ZXN0Kn0gIHYgIFBhcmFtcw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHtDZXJ0aWZpY2F0ZSp9ICBeDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAge0NlcnRpZmljYXRlVmVy aWZ5Kn0gIHwgQXV0aA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB7RmluaXNoZWR9ICB2DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8LS0tLS0tLS0gICAgIFtBcHBsaWNhdGlvbiBEYXRhKl0NCiAgICAgXiB7Q2VydGlmaWNh dGUqfQ0KQXV0aCB8IHtDZXJ0aWZpY2F0ZVZlcmlmeSp9DQogICAgIHYge0ZpbmlzaGVkfSAgICAg ICAgICAgICAgICAtLS0tLS0tLT4NCg0KKEkgYWdyZWUgd2l0aCBCZXJuYW5kIHRoYW4gZGV2ZWxv cGVycyB3b3VsZCBsaWtlbHkgZ2V0IHRoZSBtZXNzYWdlIGZsb3dzIHJpZ2h0LCBob3dldmVyIHN1 Y2ggYW4gaW1wbGVtZW50YXRpb24gd291bGQgYnJlYWsgYSBfbGFyZ2VfIG51bWJlciBvZiBNVVNU IGluIFJGQzUyMTYgKHNlZSBhYm92ZSkuIEkgYWxzbyB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRv IGdpdmUgcGVvcGxlIHdhbnRpbmcgdG8gdXNlIEVBUC1UTFMgaG93IG1hbnkgcm91bmR0cmlwcyB0 aGV5IGNhbiBleHBlY3Qgd2l0aCBUTFMgMS4zIChpbiBnZW5lcmFsIG9uZSBsZXNzIHRoYXQgd2l0 aCBUTFMgMS4wIC0gMS4yKS4NCg0KICANCj5JIHRoaW5rIG9uZSBvZiB0aGUgY29uY2VybnMgaGVy ZSBpcyB0aGUgcHJvY2VkdXJhbCBhc3BlY3QuICBZb3VyIHByb3Bvc2FsDQo+d2FzIHRvIGZvcmJp ZCBldmVyeW9uZSAqZWxzZSogZnJvbSB1c2luZyBUTFMgMS4wIGJlY2F1c2UgeW91ciByZXF1aXJl bWVudHMNCj53ZXJlIGZvciBUTFMgMS4zLiAgVGhhdCdzIG5vdCB0aGUgd2F5IHRvIGdhaW4gc3Vw cG9ydC4NCg0KWWVzLCBwcm9jZWR1cmFsIGFzcGVjdHMgc2VlbSB0byBiZSBhIGxhcmdlIGNvbmNl cm4sIGJ1dCDigJxvYnNvbGV0ZeKAnSBkb2VzIG5vdCBmb3JiaWQgYW55b25lIGZyb20gdXNpbmcg RUFQLVRMUyB3aXRoIFRMUyAxLjAuIEUuZy4gVExTIDEuMyBvYnNvbGV0ZXMgVExTIDEuMiwgd2hp Y2ggb2Jzb2xldGVzIFRMUyAxLjEgZXRjLiBidXQgdGhhdCBkb2VzIG5vdCBtZWFuIHRoYXQgcGVv cGxlIGFyZSBmb3JiaWRkZW4gdG8gdXNlIFRMUyAxLjIuIElmIGZhY3QgVExTIHByb3ZpZGVzIGEg dmVyc2lvbmluZyBtZWNoYW5pc20gYW5kIHRoZSBUTFMgd29ya2luZyBncm91cCBpcyBldmVuIHBs YW5uaW5nIFRMUyAxLjIgTG9uZy10ZXJtIHN1cHBvcnQuIFRoYXQgc2FpZCwgSSBhbSBwZXJmZWN0 bHkgZmluZSB3aXRoIOKAnHVwZGF0ZeKAnSBpZiB0aGF0IGlzIHdoYXQgdGhlIG1haWxpbmcgbGlz dCB3YW50cywgSSB3aWxsIGNoYW5nZSAib2Jzb2xldGUiIHRvICJ1cGRhdGUiIGluIHRoZSAtMDEg dmVyc2lvbiwgYW5kIG1ha2UgaXQgY2xlYXIgdGhhdCBpbiB0aGUgdGV4dCB0aGF0IHRoZSB1cGRh dGUgaXMgc3RpbGwgY29tcGF0aWJsZSB3aXRoIFJGQzUyMTYgdXNpbmcgVExTIDEuMC4NCg0KDQo+ SW1wbGVtZW50YXRpb25zIG9mIEVBUC1UTFMgZG8gbmVlZCB0byBjaGFuZ2Ugd2hlbiB0aGUga2V5 IGRlcml2YXRpb24gY2hhbmdlcy4NCj5TdWNoIGFzIGZvciBUTFMgMS4yLiAgSG93ZXZlciwgdGhv c2UgY2hhbmdlcyBhcmUgPmxhcmdlbHkgbGltaXRlZCB0byB0aGUgVExTDQo+bGlicmFyeSwgbm90 IHRoZSBFQVAtVExTIGNvZGUuDQoNClJGQzUyMTYsIFNlY3Rpb24gMi41IGRlZmluZXMgdGhhdCBN U0ssIEVNU0ssIGFuZCBJViBpcyBkZXJpdmVkIHdpdGggdGhlIFRMUy1QUkYsIHdoaWNoIGlzIHRo ZSByaWdodCB3YXkgdG8gZG8gaXQgaW4gVExTIDEuMCwgVExTIDEuMSwgVExTIDEuMi4gVExTIDEu MyByZXBsYWNlcyB0aGUgUFJGIHdpdGggSEtERiwgdGh1cyByZXF1aXJpbmcgYSBuZXcgY29uc3Ry dWN0aW9uLiBIb3cgd291bGQgc29tZW9uZSB0cnlpbmcgdG8gaW1wbGVtZW50IFRMUyAxLjMgd2l0 aCBSRkM1MjE2IGRlcml2ZSB0aGUga2V5cz8NCg0KMS4gRm9sbG93IFJGQzUyMTYgYW5kIHVzZSB0 aGUgb2xkIFRMUy1QUkYgdG8gZGVyaXZlIE1TSywgRU1TSywgSVY/DQoNCiAgS2V5X01hdGVyaWFs ID0gVExTLVBSRi0xMjgobWFzdGVyX3NlY3JldCwgImNsaWVudCBFQVAgZW5jcnlwdGlvbiIsDQog ICAgICAgICAgICAgICAgICAgICBjbGllbnQucmFuZG9tIHx8IHNlcnZlci5yYW5kb20pDQogICAg ICAgICAgICAgICAgICAgICANClRoaXMgd291bGQgbWVhbiB0aGF0IHRoZSBFQVAtVExTIGNvZGUg d291bGQgaGF2ZSB0byBpbXBsZW1lbnQgdGhlIFRMUy1QUkYsIHRoZSBUTFMgbGlicmFyeSB3b3Vs ZCBhbHNvIG5lZWQgdG8gYmUgbW9kaWZpZWQgdG8gZW5hYmxlIGV4dHJhY3Rpb24gb2YgbWFzdGVy X3NlY3JldCwgY2xpZW50LnJhbmRvbSwgYW5kIHNlcnZlci5yYW5kb20uIFRoYXQgc2VlbXMgbGlr ZSBhIHZlcnkgYmFkIHNvbHV0aW9uLg0KDQpBbHNvIHdvdWxkIHN1Y2ggYW4gaW1wbGVtZW50YXRp b24gdXNlIHRoZSBUTFMgMS4yIG9yIFRMUyAxLjEgUFJGPw0KDQoyLiBUcnkgdG8gZ3Vlc3MgaG93 IHRvIGRvIHNvbWV0aGluZyBzaW1pbGFyIHdpdGggdGhlIFRMUyBIS0RGIGNvbnN0cnVjdGlvbg0K DQogIEtleV9NYXRlcmlhbCA9IERlcml2ZS1TZWNyZXQoTWFzdGVyIFNlY3JldCwgImNsaWVudCBF QVAgZW5jcnlwdGlvbiIsIGNsaWVudC5yYW5kb20gfHwgc2VydmVyLnJhbmRvbSkNCg0KMy4gT3Ig ZXF1YWxseSBsaWtlbHkgcmVwbGFjZSBDbGllbnRIZWxsby5yYW5kb20gKyBTZXJ2ZXJIZWxsby5y YW5kb20gd2l0aCBDbGllbnRIZWxsby4uLnNlcnZlciBGaW5pc2hlZCBhcyBkb25lIGluIGFsbCBr ZXkgZGVyaXZhdGlvbiBpbiBUTFMgMS4zICAgIA0KDQogIEtleV9NYXRlcmlhbCA9IERlcml2ZS1T ZWNyZXQoTWFzdGVyIFNlY3JldCwgImNsaWVudCBFQVAgZW5jcnlwdGlvbiIsIENsaWVudEhlbGxv Li4uc2VydmVyIEZpbmlzaGVkKQ0KDQo0LiBPciBkbyBpdCB0aGUgbmF0dXJhbCB3YXkgaW4gVExT IDEuMyAoVXNlZCBpbiBlLmcuIGRyYWZ0LWlldGYtcXVpYy10bHMpIA0KDQogIEtleV9NYXRlcmlh bCA9IFRMUy1FeHBvcnRlcigiY2xpZW50IEVBUCBlbmNyeXB0aW9uIiwgIiIsIDEyOCkNCg0KSSB0 aGluayB0aGlzIGlzIGV4dHJlbWVseSBsaWtlbHkgdG8gbGVhZCB0byBpbmNvbXBhdGlibGUgaW1w bGVtZW50YXRpb25zIG9mIEVBUC1UTFMgd2l0aCBUTFMgMS4zIHVubGVzcyBJRVRGIGdpdmVzIGd1 aWRhbmNlLiBNeSB2aWV3IGlzIHRoYXQgYSBkb2N1bWVudCBpcyBuZWVkZWQgc3RhdGluZyBob3cg dGhlIGtleSBkZXJpdmF0aW9uIGlzIGRvbmUgd2hlbiBFQVAtVExTIGlzIHVzZWQgd2l0aCBUTFMg MS4zLCBteSBwcm9wb3NhbCB3b3VsZCBiZToNCg0KICBLZXlfTWF0ZXJpYWwgPSBUTFMtRXhwb3J0 ZXIoImNsaWVudCBFQVAgZW5jcnlwdGlvbiIsICIiLCAxMjgpDQoNCg0KPkluIGFkZGl0aW9uLCB5 b3VyIG90aGVyIGFyZ3VtZW50cyBhcmUgaGFuZC13YXZpbmcsIGFuZCBkb24ndCBwcm92aWRlIGNv bmNyZXRlID5kZXRhaWxzIHRvIGJhY2sgdXAgeW91ciBwb3NpdGlvbi4gIEhhdmluZyBjb25jcmV0 ZSBkZXRhaWxzIHdvdWxkIGhlbHAuDQoNCkkgaG9wZSB0aGF0IHRoZSBkZXRhaWxzIGFib3ZlIGls bHVzdHJhdGUgd2h5IEkgdGhpbmsgYW4gc2hvcnQgZG9jdW1lbnQgZGVzY3JpYmluZyBob3cgdG8g dXNlIEVBUC1UTFMgd2l0aCBUTFMgMS4zIGlzIG5lZWRlZC4gSSB3aWxsIHVwZGF0ZSB0aGUgZG9j dW1lbnQgYWxpZ25pbmcgd2l0aCB0aGUgY29tbWVudHMgcmVjZWl2ZWQ6DQoNCi0gInVwZGF0ZSIg aW5zdGVhZCBvZiAib2Jzb2xldGUiIGFuZCBhbHNvIG1ha2luZyBjbGVhciB0aGF0IGFuIGltcGxh bWVudGF0aW9uIGZvbGxvd2luZyB0aGUgZG9jdW1lbnQgaXMgc3RpbGwgY29tcGF0aWJsZSB3aXRo IEVBUC1UTFMgd2l0aCBUTFMgMS4wICh1cCB0byB0aGUgYXBwbGljYXRpb24gdG8gZGVjaWRlKS4g VGhpcyBtZWFucyB0aGF0IHRoZSBFQVAtVExTIHdpdGggVExTIDEuMyBkb2N1bWVudCBjYW4gYmUg c2hvcnRlciB0b3RhbGx5IGF2b2lkaW5nIG92ZXJsYXAgd2l0aCBSRkM1MjE2LCBvbmx5IGRlc2Ny aWJpbmcgYW55IGRpZmZlcmVuY2Ugd2hlbiB1c2lnbiBUTFMgMS4zLg0KDQotIEhpZ2hsaWdodCB3 aGljaCBwYXJ0cyByZWxldmFudCBmb3IgRUFQLVRMUyB0aGF0IGNoYW5nZXMgaW4gVExTIDEuMyBh bmQgd2h5IGFuIHVwZGF0ZSBpcyBuZWVkZWQuDQoNCi0gQWRkIGluZm9ybWF0aW9uIG9uIGhvdyBL ZXlfTWF0ZXJpYWwgYW5kIElWIGlzIGRlcml2ZWQgd2hlbiB1c2luZyBFQVAtVExTIHdpdGggVExT IDEuMy4gUmVmZXJpbmcgdG8gUkZDNTIxNiBmb3IgdG8gZ2V0IE1TSywgRU1TSywgZXRjLCBmcm9t IEtleWluZ19NYXRlcmlhbC4NCg0KQ2hlZXJzLA0KSm9obg0KDQoNCg0KDQoNCg0K From nobody Fri Dec 1 05:58:14 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD97128D44; Fri, 1 Dec 2017 05:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=ericsson.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 67OmPCCPYAby; Fri, 1 Dec 2017 05:58:03 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.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 B8CAE126DFE; Fri, 1 Dec 2017 05:58:02 -0800 (PST) X-AuditID: c1b4fb25-36dff70000000151-99-5a215fe8e754 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 54.6B.00337.8EF512A5; Fri, 1 Dec 2017 14:58:00 +0100 (CET) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 1 Dec 2017 14:58:00 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wBP7e2wXgWYJuEPjhW8GLIrK4h7CWHzdC5JeJfxMkkw=; b=m+WK8SmKy8cRwTqOcingu4B7CBVlE87t/hCzu9v0CtMix1CxmeXLfFdzEaVb0vvduKb3pmLxliu04iXGcMU+EF+4aaaFywe6QjPLiLaQ8GpAh5vrT0JITKsBnS8JEOjcP28CLz8GmO/lvTQKwSvg8De7HgO+gLdCV553Gko+YWE= Received: from DB5PR0701MB2005.eurprd07.prod.outlook.com (10.167.228.147) by DB6PR07MB3270.eurprd07.prod.outlook.com (10.175.233.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Fri, 1 Dec 2017 13:57:58 +0000 Received: from DB5PR0701MB2005.eurprd07.prod.outlook.com ([fe80::cded:d65b:8eb2:a1bd]) by DB5PR0701MB2005.eurprd07.prod.outlook.com ([fe80::cded:d65b:8eb2:a1bd%14]) with mapi id 15.20.0282.006; Fri, 1 Dec 2017 13:57:58 +0000 From: John Mattsson To: Bernard Aboba , Jari Arkko , Mohit Sethi M , "reap@ietf.org" , "saag@ietf.org" , "emu@ietf.org" Thread-Topic: [Reap] [Emu] EAP - TLS 1.3 Thread-Index: AQHTaqxkTIQHAGf0302lfanrf7k7pg== Date: Fri, 1 Dec 2017 13:57:58 +0000 Message-ID: <8C04ED3B-0D84-443B-8853-3EBD950C1732@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.28.0.171108 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.47.185] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR07MB3270; 6:5HLOip5+XrVZJZDUZ1CjEWMO0LpGeCFMC6VUZYeHceutJdfO3CR2L6JqLy0z+1BfxcLFc1sJD4OVUZlYFSbMVIUhxTwc6nWiuzpf5GQjq0SbVIKD4dNQNYsxx2oSYhdk8DjNNVC2ZwfWw4UeTchXekBhA7fwT7snj24D+hsavFikx05giGpi91tDyL34w9orFtMdMxWS1LGdH6EmTU6roOvmNpyGhj7Fwo4/n9IAoHtuf6z0/L1SbZ+7hTGyb+xCBN7Na23CyaSz9b+DgMInncxIJU29piyzceRUXGqqL2u3ICC04JEPjInhloZbg1gO1m4hDZKmwLBokxc/sQFN+ke+TmaM1B1Neda6qJm9esc=; 5:B3wuv4UFVlPPQw8DtuX0nkl5vDq/bdHoVBNeg9Wes9ejMMOsSZL1o1bGbR8YuInpkWKhB+qluzKrr/LJKyToNYJPT/sDAiGBPyF6U5omAKeburQjX0/EThiNk/urB+zpd0QWaPJmBEVRl4Mc/5+kuYrB9ecYXTUF5TiIqTyNnNg=; 24:4uQNMgiKaerJnvXUX5PDkvsKHQh3NkAzafAcdkR+RMoc/hFgtmEOp0jEgOg6Vd9l1HzVVXjJ2tc3odN6nBGhCYiLqqJal0tvw8g6UAHf+J0=; 7:i/27peTXJsQUJ7JQ0Ad84Rmjfr464TVoElD4Zb9px6ibDzSCh69rJYJHouDf+4crXlKEiHCeUPUqjkYb/9vxkApJxMIkbLQRauTLT6dJgtIa06+3ms67aref/9+51JUCYGmPtCIEUUy4xyVjk6RtENaQva4idrTq5o3Gv0YlGq0HnAZgG9QNot959Cm6Vr6IJcpCD+Uye7sQilKvpD7C0Y3Im5FfvLmfOBZLU7WCvuZtqsC3xruIo6gou16q9Qzl x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 685a6b2b-af22-4d4c-f51c-08d538c387a6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:DB6PR07MB3270; x-ms-traffictypediagnostic: DB6PR07MB3270: x-ld-processed: 92e84ceb-fbfd-47ab-be52-080c6b87953f,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231022)(6041248)(20161123564025)(20161123555025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011); SRVR:DB6PR07MB3270; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB6PR07MB3270; x-forefront-prvs: 05087F0C24 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(366004)(346002)(39860400002)(24454002)(51444003)(199003)(189002)(305945005)(8676002)(7736002)(81156014)(68736007)(6486002)(83506002)(229853002)(81166006)(99286004)(6506006)(8936002)(66066001)(14454004)(478600001)(58126008)(110136005)(101416001)(3846002)(5660300001)(2201001)(316002)(54356011)(189998001)(36756003)(6436002)(6116002)(97736004)(102836003)(2501003)(83716003)(3660700001)(2900100001)(3280700002)(53936002)(39060400002)(86362001)(82746002)(5250100002)(106356001)(33656002)(25786009)(6512007)(2906002)(105586002)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR07MB3270; H:DB5PR0701MB2005.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <93E298844DEBA0469B42C7966A02578C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 685a6b2b-af22-4d4c-f51c-08d538c387a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2017 13:57:58.7499 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3270 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUyM2K7se6LeMUog+W7TS027PvPbHFs/VoW i3Mrj7NYTOnvZHJg8dg56y67x5IlP5kCmKK4bFJSczLLUov07RK4MiZ/6mMqOCde0XIjuIGx QbyLkZNDQsBEYvfeS4xdjFwcQgKHGSXWbrrGCpIQEjjOKPGkRR8kwSLQyyxx79o3ZoiqGUwS 85YtZoOoesYocfqyHIjNJmAgMXdPAxtIkYjAE0aJzgX9zCAJYQF1ifX3tjOB2CICGhIPv+9j hLD1JLb+PAO2jkVARWL6/G6wobwC9hLvmhrB6hkFxCS+n1oDZjMLiEs0fVnJCnG3gMSSPeeZ IWxRiZeP/4HFRYFm/tv5Gqo3VqK1dTpUvaLE0qPToGxZiUvzu8F+lhA4xC7x7foiFogE0EET 3zJC2L4SJ5ZsZoEoWsIoMffqDqiElkTH5qtQto3EjO7pUFdkSxxrecIEV3NkFhNE8wJmiQf/ b0NtkJG4vmsv1NSHrBJPnu9lnsCoNwvJe7MYOYBsTYn1u/Qhwh4SJxub2CBsRYkp3Q/ZZ4FD SVDi5MwnLAsYWVcxihanFiflphsZ66UWZSYXF+fn6eWllmxiBCaZg1t+q+5gvPzG8RCjAAej Eg+vjL9ilBBrYllxZe4hRgkOZiUR3lg/oBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHek568UUIC 6YklqdmpqQWpRTBZJg5OqQZGtt+K7lJ5aoFiBQb7WHu2OTfWK85p3HH0sYpsMk9j3ixPQc/z nBMefTS7f8zhRjxbPl/Lvb+fStQPBbn1vLhnrRm2z97WwvvI7lfrD3U9SDzNmPjp+5WwuVue hGi+fuuUnrKQa6aO3a59xtzvvI9bu/i6qiVtD57wtf4370mz+pP8O+1PqDEosRRnJBpqMRcV JwIAp19PCS4DAAA= Archived-At: Subject: Re: [saag] [Reap] [Emu] EAP - TLS 1.3 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 13:58:05 -0000 SGkgQmVybmFyZCwNCg0KT24gVGh1LCBOb3YgMTksIDIwMTcsIEJlcm5hcmQgQWJvYmEgd3JvdGU6 DQoNCj5UaGUgYmlnIHF1ZXN0aW9uIGlzICJXaHkgbm90IGNyZWF0ZSBhIG5ldyBFQVAgbWV0aG9k Ij/CoA0KDQo+VGhlIG92ZXJhbGwgaW50ZW50IHNlZW1zIHRvIGJlIHRvIGNyZWF0ZSBhbiBwcmUt c2hhcmVkIGtleSBFQVAgbWV0aG9kIG9wdGltaXplZCBmb3IgNUcsDQo+YmFzZWQgb24gRUFQLVRM UyB2MS4zLsKgwqANCg0KSSBkb27igJl0IGtub3cgd2h5IHlvdSBoYXZlIGdvdHRlbiB0aGUgaWRl YSB0aGF0IHRoZSBpbnRlbnQgaXMgcHJlLXNoYXJlZCBrZXkgYXV0aGVudGljYXRpb24uIDNHUFAg aGFzIG5vIGludGVyZXN0IGluIEVBUC1UTFMgd2l0aCBwcmUtc2hhcmVkIGtleSBhdXRoZW50aWNh dGlvbi4gM0dQUCB3YW50cyB0byB1c2UgRUFQLVRMUyB3aXRoIGNlcnRpZmljYXRlIGF1dGhlbnRp Y2F0aW9uLg0KDQo+U2luY2UgdGhlIHByb3RvY29sIGRlc2NyaWJlZCB3aWxsIG5vdCBpbnRlcm9w ZXJhdGUgd2l0aCBhbnkgb2YgdGhlIGV4aXN0aW5nIDIrIGJpbGxpb24NCj5FQVAtVExTIGRldmlj ZXMsIHdoeSByZXVzZSB0aGUgRUFQLVRMUyBjb2RlIHBvaW50IG9yIEVBUC1UTFMgbmFtZT/CoCDC oFdoYXQgaGFzIGJlZW4NCj5kZXNjcmliZWQgaXMgYW4gZW50aXJlbHkgZGlzdGluY3QgYXV0aGVu dGljYXRpb24gbWV0aG9kLCBub3QgYSAiY2xhcmlmaWNhdGlvbiIgdG8gYW4NCj5leGlzdGluZyBz cGVjaWZpY2F0aW9uLg0KDQo+SW4gZmFjdCwgZnJvbSBob3cgaXQgaGFzIGJlZW4gZGVzY3JpYmVk LCBpdCB3b3VsZCBhcHBlYXIgdGhhdCB0aGUgbmV3IHByb3RvY29sIGlzIG9ubHkgZm9yIHVzZQ0K PndpdGggbmV3IGRldmljZXMgc3VwcG9ydGluZyA1RyBhbmQgbmV3IDVHIHNlcnZlcnMgc3VwcG9y dGluZyB0aGUgbmV3IG1ldGhvZC7CoCBJbiB3aGljaCBjYXNlLA0KPmlmIHRoZSBuZXcgbWV0aG9k IGlzIG5vdCBmb3IgZ2VuZXJhbCB1c2Ugb24gdGhlIEludGVybmV0LCB3aHkgY2FuJ3QgM0dQUCBq dXN0IGRlZmluZSB0aGUgbWV0aG9kID50aGVtc2VsdmVzIGFuZCBhbGxvY2F0ZSB0aGVpciBvd24g cHJpdmF0ZSBFQVAgdHlwZSBjb2RlP8KgDQoNCkkgZG9u4oCZdCBrbm93IHdoeSB5b3UgaGFzIGNv bWUgdG8gdGhlIGNvbmNsdXNpb24gdGhhdCB0aGlzIHdvdWxkIG5vdCBpbnRlcm9wZXJhdGUgd2l0 aCBleGlzdGluZyBFQVAtVExTIGRldmljZXMuIFRMUyAxLjMgZS5nLiBvYnNvbGV0ZXMgVExTIDEu MiBidXQgc3RpbGwgaW50ZXJvcGVyYXRlIGp1c3QgZmluZSB3aXRoIGFsbCBvbGQgdmVyc2lvbnMg b2YgVExTLiAzR1BQIHBsYW5zIHRvIHVzZSBFQVAtVExTIChSRkM1MjE2KSB3aXRoIGN1cnJlbnQg dmVyc2lvbnMgb2YgVExTLiBJbiB0aGUgZnV0dXJlLCAzR1BQIChhbmQgcHJvYmFibHkgbWFueSBv dGhlcnMpIHdvdWxkIGxpa2UgdG8gdXNlIEVBUC1UTFMgd2l0aCBUTFMgMS4zLg0KDQozR1BQIGhh cyBubyBzcGVjaWFsIHJlcXVpcmVtZW50cyB3aGVuIGl0IGNvbWVzIHRvIHVzaW5nIEVBUC1UTFMg d2l0aCBUTFMgMS4zLCBhbmQgd291bGQgbGlrZSB0byBiZSBpbnRlcm9wZXJhYmxlIHdpdGggYWxs IGltcGxlbWVudGF0aW9ucyBvZiBFQVAtVExTIHdpdGggVExTIDEuMy4gVGhlIG1ham9yIHBvaW50 IHdpdGggRUFQLVRMUyBpcyB0byB1c2UgdGhlIFRMUyB2ZXJzaW9uIG5lZ290aWF0aW9uLCBkZWZp bmluZyBFQVAtVExTIHdpdGggVExTIDEuMyBhcyBhIGRpZmZlcmVudCBjb2RlIGlzIG5vdCBhIGdv b2QgaWRlYS4NCg0KTXkgdmlldyBpcyB0aGF0IGl0IGlzIG5vdCBjbGVhciBob3cgdGhlIGtleSBk ZXJpdmF0aW9uIGlzIGRvbmUgd2hlbiBFQVAtVExTIGlzIHVzZWQgd2l0aCBUTFMgMS4zLiBOb24t aW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMgd291bGQgbm90IGJlIGdvb2QgZm9yIHRoZSBJ bnRlcm5ldC4gRnVydGhlcm1vcmUsIGFuIGltcGxlbWVudGF0aW9uIG9mIEVBUC1UTFMgd2l0aCBU TFMgMS4zIHdvdWxkIGJyZWFrIGEgX2xhcmdlXyBhbW91bnQgb2YgTVVTVHMgaW4gUkZDNTEyNiBh cyBUTFMgMS4zIGNoYW5nZXMgYSBsb3QgZnJvbSBUTFMgMS4wIOKAkyAxLjIuIEkgdGhpbmsgdGhh dCBhbiB1cGRhdGUgdG8gUkZDNTIxNSBpcyBuZWVkZWQgaXJyZXNwZWN0aXZlbHkgb2YgM0dQUCB1 c2luZyBFQVAtVExTIG9yIG5vdC4NCg0KQ2hlZXJzLA0KSm9obg0KDQo= From nobody Wed Dec 6 19:48:51 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A98128D16 for ; Wed, 6 Dec 2017 19:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 5GLgNnmxh-Bk for ; Wed, 6 Dec 2017 19:48:47 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 93F4A128D64 for ; Wed, 6 Dec 2017 19:48:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1512618526; x=1544154526; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=dM2quHwawq0SIoBIKelJnfbG23/d96MWC2ML/++GgQc=; b=B0kQUlTrIX3tqKSKmQxsiNwWtrrkfPl0ZS65YDAzlYySkBdeS0VVyETe lnB5IDvA5dztOlr8PucFpIng2UNcDTO9SuSUi5gO6/mqdoY+KZ2mUdwC8 /6Se02u4tWCUqWcnzjFZ3/FHvIXQFLGci5DKN3aRs5q9fw1cnBQ5JWxRK vcd7M3q1K4VYbJXRk/DJYt/VFiED26Mx4/UP1HXc5wq6fq+a2wIYYPuAn r7LxvIBNha6pW7AS9eqA+RTNAHOON/zVElMFTb2/AJlS7SU64VlG45Ccb rqgxhk4y7wxe1RHRBqMKSVaAk44RhwTeLBaiyM6JYtyIlWB8dLx/fVQ3A A==; X-IronPort-AV: E=Sophos;i="5.45,370,1508756400"; d="scan'208";a="201987727" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.4 - Outgoing - Outgoing Received: from uxcn13-ogg-c.uoa.auckland.ac.nz ([10.6.2.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 07 Dec 2017 16:48:44 +1300 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.4) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 7 Dec 2017 16:48:44 +1300 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::78f4:a266:466b:508b]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::78f4:a266:466b:508b%14]) with mapi id 15.00.1263.000; Thu, 7 Dec 2017 16:48:44 +1300 From: Peter Gutmann To: "saag@ietf.org" Thread-Topic: Status of the SCEP RFC draft Thread-Index: AQHTbw4UUnneaIh1UU6hdrWtX9hT6Q== Date: Thu, 7 Dec 2017 03:48:43 +0000 Message-ID: <1512618517258.43968@cs.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 03:48:49 -0000 After 18 years in the draft stage, this is finally ready for publication. T= he=0A= one sticking point is its status, which I think should be Standards Track b= ut=0A= others think should be Historic.=0A= =0A= The problem with Historic is two-fold, firstly RFC 2026 defines historic as= "A=0A= specification that has been superseded by a more recent specification or is= =0A= for any other reason considered to be obsolete is assigned to the "Historic= "=0A= level", which is in both cases the exact opposite of what SCEP is, it's not= =0A= superseded and it's in wider and more active use than the marked-as-standar= ds-=0A= track CMP and CMC.=0A= =0A= The second is that SCEP is in extremely wide, and active use, and is=0A= referenced in numerous other industry standards (usually with an apologetic= =0A= note about having to refer to a draft :-). For example Apple's OTA profile= =0A= configuration and delivery protocol only supports SCEP, and it seems to be = the=0A= standard MDM mechanism in enterprise environments. Microsoft has supported= it=0A= as standard since Server 2003 via NDES and that's then used to provision=0A= mobile devices, as well as routers, firewalls, ... not to mention its use i= n=0A= SCADA, ICS, embedded, etc. There are (at least) a billion+ devices running= =0A= SCEP today. Like C, it'll probably be around forever because so much=0A= infrastructure depends on it.=0A= =0A= In addition there are new implementations as recently as the last six month= s,=0A= and more expected over time since it's pretty much the only protocol there = is=0A= for automated cert provisioning of devices, or at least the only one that's= =0A= widely deployed and that works.=0A= =0A= So both from the RFC 2026 and the pragmatic point of view, I think this sho= uld=0A= be published as standards-track. It's definitely not Historic in either=0A= sense.=0A= =0A= Peter.= From nobody Thu Dec 7 07:07:39 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC5B128AB0 for ; Thu, 7 Dec 2017 07:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 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=-2.8, 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=digicert.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 Nb8t4yTWC2UD for ; Thu, 7 Dec 2017 07:07:35 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.198]) (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 07CDE12896F for ; Thu, 7 Dec 2017 07:07:34 -0800 (PST) Received: from [216.82.242.46] by server-6.bemta-8.messagelabs.com id EC/59-03668-539592A5; Thu, 07 Dec 2017 15:07:33 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSWUwTURSGe2e6DISSoQU5VojaSAQSViWp8UE e1FQF4ouJEhIddGwbu5CZojXRCLiioogYlqBVbNQYleIekiIUFMFohKARsCqxLhRwr4hxm+mM 29t3zv/fs9wcAlf1yzUE7bDTjJUya+Xh0kczrqhTMlYl5ae/DGToRt68kumqD5Zj2Zi+t7QN0 7tck9hyLF9mshbaHGtkxj0BNyoK6h39FU14CapYtBeFE1LyLQbN498VfKAiqzD4MDIpF4IOBK 89Li4II+RkOjz0dGE8R5N50PLTF8qrySTY+aydyxNcPhlubNcLlkxwubsUPEvJWeDsfBZiJVk AVV+CMp5V5Bwo9ZfgPIeRc2G8yhfKI3IKTPScC7XCyVgY9DtDDGQ0DPfekQscAyPPf4j+Ajj6 0SvmtTB0/gsSOB76nPsQvwuQXgXsaJuQCUIqXDk0Lppy4aN7t0IwnULQOvAEF4RkuO3dJZo2Q DBQI3bIgTu7nGLVDhwOd/aIVePgSPAELghdMnAPjyqEPddB9Vmv+F0a8PWXI4Hj4PVjj6wSJd b/s2o99x4nnQiaasqk9aE/i4LuOr9UMKVAS2sbLvB0uDbeIPJ8qP3aLhd4JlTvG1YInAWjN9+ j44g4ixJZmtlIMymZWamFjMlgtFsokzklI12XaqFZljLQZqqQTV1rs1xE3G1tk0jQdfTiXa4X TSUwbYwyLy8pXxVZaFu32UixxtVMsZlmvSiOILSg3LKS06IY2kA71pvM3IH+loGI0EYrZ/Cyk i2iLKzJIEg9aA7R4Bn8hhEv60ZLcJXUarPSmlili7eSvNVYbP1T6Pex96F4jVqJJBKJKqKIZi wm+/96AMUSSKtW5vBVIkxW+59+AW4UjBul4PhsfhQ79VfSlCBtzNWytd2Gvbcq7/s67m4deno g+ODFktqo9Q90zfaZprE0z4LDZ3ZbKpbZ4vTMvewL105uurQ4bdPAnsgpnRv8DQtqFpd/rW9q R4k+x42oFRPe9O3Rs8rGGrOy3Ug671Ojc2nCwhG26hWl/nya9us6FJfTjrEXuy8n5L6fNlm62 bhfK2WNVEYyzrDUL0kwzJTnAwAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-9.tower-96.messagelabs.com!1512659248!113935514!1 X-Originating-IP: [216.32.181.19] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20434 invoked from network); 7 Dec 2017 15:07:29 -0000 Received: from mail-co1nam03lp0019.outbound.protection.outlook.com (HELO NAM03-CO1-obe.outbound.protection.outlook.com) (216.32.181.19) by server-9.tower-96.messagelabs.com with AES256-SHA256 encrypted SMTP; 7 Dec 2017 15:07:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fuLt/rV6rdD4sLzYNEuQ7GvukBQmNv3tfN7R3TPByos=; b=Yo0Wp0CV1HfzlUl2oLafTdMsGG8C9uIwa+Moql+cpAYli6JiRYPRuWeWuAPKmAqNZIDWYSPN6gsTS/pR83gs63kvPECYA5DkyxL+2qw2Uc6kaDiZcOIIf6nx7iEsEzQwJY0YXhxhctsuDaPSdTyDgfOgI+YWgXe/nF6iZxDqe6M= Received: from DM5PR14MB1289.namprd14.prod.outlook.com (10.173.132.19) by DM5PR14MB1289.namprd14.prod.outlook.com (10.173.132.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Thu, 7 Dec 2017 15:07:27 +0000 Received: from DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) by DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) with mapi id 15.20.0302.010; Thu, 7 Dec 2017 15:07:27 +0000 From: Tim Hollebeek To: Peter Gutmann , "saag@ietf.org" Thread-Topic: Status of the SCEP RFC draft Thread-Index: AQHTbw4UUnneaIh1UU6hdrWtX9hT6aM3+z/A Date: Thu, 7 Dec 2017 15:07:26 +0000 Message-ID: References: <1512618517258.43968@cs.auckland.ac.nz> In-Reply-To: <1512618517258.43968@cs.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [74.111.107.128] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR14MB1289; 6:oCEuzEsFcYPaRGE4FH3Gsunl5DNO3r60VaRuKgk0Q65VbaOcLRBXc6K9BJhOM8LQuqkjP+Anp+6hq6adPTpFhTAX32GGMaz1pObbSNr1rS6JF4c0c8qWLbW+pVv69Xc387zPq7le1ARuaTjzoV1V6RkPB+6ZDSatFkKKUFfeYLLSSwZ7mzY0eZNv6aIAMJruXCTimzPSS2zv3Hxaf+CAfcJe0LMxx41U+t+aTzb3ooCAu6meQYIm36MjTcT9QmrWc4oR3Q8cZ3WAffFyLOUDVoQsLz/zZRt+f4RixohZeymrvi9KIbT8Y/GY0UMD8ZuwQ5bJGUes+zsjwJKL2QSeo02RAb71CoqdoP8o+attgtE=; 5:kMkrd+hPKQTCC3fafIrK7u1DMHPfPvR3E109TuD3if3Xv1D69jDjQyEZnCobIChjKOZBJs/O7z3r2DC/BWMRjBqswrH1G93DfSk/rVbDJaP8H9p2wHrgMEAAa1pemQMjtBPg2ayiBTjyJ3upmsDlffcqhnvVtxXZ/BwFIIKU9S0=; 24:6CVB4dUmGBwY3O7avbUx4lhsqeTSvmFLbBmW8fpY3bZC0eioAXMe8YyPmiFbET87fOsRNpSbEjfQm2SgGhSfRPrhXV6t/JEPZgiaNrLnaiE=; 7:selz6178DYwkhE9qTWzVi3I8MIb3K6MGolILGcziedKhY5ml3cRPqoK8H18/S2eF6yCXxrZ6lpLeri/O5yufm0peGcvm+20IXIZG7N/p3mwtdcMTI7F1Fe3Aawx1KS5fRMLB+SWAashe2cB0DOkGJKOojKy5pyts+VIg6ChUzQkzHeuHcQH1R9Qv33/CP0FKVCwQ5NJ9Qta1vwj3l6gxArgunVILax0Q7C6dBJc2HYlLn4/2RYGQin0OGkswJSqi x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3f271b53-8000-4a2f-a816-08d53d843aa5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603286)(49563074); SRVR:DM5PR14MB1289; x-ms-traffictypediagnostic: DM5PR14MB1289: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231022)(3002001)(6041248)(2016111802025)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(6043046)(201708071742011); SRVR:DM5PR14MB1289; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR14MB1289; x-forefront-prvs: 05143A8241 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(376002)(189003)(199004)(13464003)(53546010)(97736004)(45080400002)(478600001)(305945005)(7736002)(8936002)(76176011)(2900100001)(81156014)(81166006)(3846002)(6116002)(14454004)(102836003)(966005)(7696005)(8676002)(2501003)(99286004)(9686003)(55016002)(6506006)(316002)(6246003)(6436002)(229853002)(110136005)(5660300001)(68736007)(6306002)(53936002)(25786009)(33656002)(106356001)(105586002)(86362001)(2906002)(66066001)(74316002)(101416001)(3660700001)(2950100002)(3280700002)(99936001)(77096006)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR14MB1289; H:DM5PR14MB1289.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_008E_01D36F32.6913CE70" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3f271b53-8000-4a2f-a816-08d53d843aa5 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2017 15:07:26.8736 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR14MB1289 Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 15:07:37 -0000 ------=_NextPart_000_008E_01D36F32.6913CE70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I can confirm that SCEP is required for Apple MDM (I previously led a team that implemented SCEP as part of a mobile security product). I find the perspective that SCEP is only of historical interest to be somewhat baffling. -Tim -----Original Message----- From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Peter Gutmann Sent: Wednesday, December 6, 2017 8:49 PM To: saag@ietf.org Subject: [saag] Status of the SCEP RFC draft After 18 years in the draft stage, this is finally ready for publication. The one sticking point is its status, which I think should be Standards Track but others think should be Historic. The problem with Historic is two-fold, firstly RFC 2026 defines historic as "A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level", which is in both cases the exact opposite of what SCEP is, it's not superseded and it's in wider and more active use than the marked-as-standards- track CMP and CMC. The second is that SCEP is in extremely wide, and active use, and is referenced in numerous other industry standards (usually with an apologetic note about having to refer to a draft :-). For example Apple's OTA profile configuration and delivery protocol only supports SCEP, and it seems to be the standard MDM mechanism in enterprise environments. Microsoft has supported it as standard since Server 2003 via NDES and that's then used to provision mobile devices, as well as routers, firewalls, ... not to mention its use in SCADA, ICS, embedded, etc. There are (at least) a billion+ devices running SCEP today. Like C, it'll probably be around forever because so much infrastructure depends on it. In addition there are new implementations as recently as the last six months, and more expected over time since it's pretty much the only protocol there is for automated cert provisioning of devices, or at least the only one that's widely deployed and that works. So both from the RFC 2026 and the pragmatic point of view, I think this should be published as standards-track. It's definitely not Historic in either sense. Peter. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag ------=_NextPart_000_008E_01D36F32.6913CE70 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTcxMjA3MTUwNzIyWjAvBgkqhkiG9w0BCQQxIgQg3O8BLiwtEpSeLItn7bfxVoZPZbiy vKDLEvZi7Zcv3K4wgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAFXGczZmAv1ii61Y7VcLDtpi9h91FiQiW8O06xvPNcscnw8dB5v4JUfH7PPJXDzx/a+BCKsE GQnpSOvC5MpveUq060mpyjk3AKwdIQ3pZRtkSNNusfWvtRkZdYthaSbyBU/XgwqpJLHF+89/ID6a Xw8HoFajNbhpIyov3x+t99AXW149AE9reiM5LSx6dQWW/dnqfoSoQ1rs/tkN02oAZOup3xRGOYGZ Od0XjAS4OQxp7B8C8cMBZWJrggiumXFMccgn9Pyf3EYkJ48gsbSpxc5eEAAuzb9EZPcuHvkPlpcw MTf/MFuRV97mTxc/vOp4j15ZS61bY9mp2Z7rAj+Eq1MAAAAAAAA= ------=_NextPart_000_008E_01D36F32.6913CE70-- From nobody Thu Dec 7 07:12:32 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902B7129442 for ; Thu, 7 Dec 2017 07:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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=redhoundsoftware.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 qlj9kQoF-YEh for ; Thu, 7 Dec 2017 07:12:29 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 502DF128B8F for ; Thu, 7 Dec 2017 07:12:29 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id e2so18337428qti.0 for ; Thu, 07 Dec 2017 07:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=IwKxElzJAwuPz1CkEq1vryFyygsNRgGOhMwG0I1+cjA=; b=sjkkLI9pqRM3Vsni8MkNYeiaoyYjuqa01+K5te3PiLJPcczTthTNaKyle2o1blwLu4 8afE/ugITmCB8vwZTSf+4ew+w1FyipzdTzpM5rXJBYnaTESaZjKO4d+wI1zNMC0IFyzP 0QwzdkogeMQetaNV4+gv73tGY4dsn5HsaIy3s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-transfer-encoding; bh=IwKxElzJAwuPz1CkEq1vryFyygsNRgGOhMwG0I1+cjA=; b=uL6tfpU75ftJHP6G9+5WE6/r97/fVlalifOe6Md3/JD1u0bgfUobf5BaVcPQBB0hFz ND1Gz8Z3P+zlfPmRjaOdtd18MTJFVro5oh0/2ZznIc+Orr03EdXgL4R/WoUzVqTV3TS6 +xupflr0CkVB3XakPKJRAAKbIv0+kutoNywjRVGQSX8sKfcQWM71tlncjM+gEHNQLZli T13vOIh6IHqBdH9snaRxq9zQeldSlpG9+3j5Xw0brldOQvqosS3HpK34Xx6EdXicyU5F tDekxH1ePTF3O5UB+SUEdMbJENNmDaNOCgBq/CcT+WvPFZQm0pq0AQP7ltLB0n/McgkM qZsQ== X-Gm-Message-State: AKGB3mKQMgYIR2ERb/tA1PIejR3rKUi/Bnrtuv0wBEm7fUsYAONz83xt +BzEz9avHrK5u2UWe83CBNKsuQ== X-Google-Smtp-Source: AGs4zMbuJDoOGO/0m0TFY34rDcqKdjWGLXvhmY0j1FFDK4njKPU/1zG0RNUCzpc75WsUaLs3Njaj1Q== X-Received: by 10.55.123.71 with SMTP id w68mr30101166qkc.38.1512659548396; Thu, 07 Dec 2017 07:12:28 -0800 (PST) Received: from [192.168.2.27] (pool-173-66-76-215.washdc.fios.verizon.net. [173.66.76.215]) by smtp.googlemail.com with ESMTPSA id z128sm3048822qke.92.2017.12.07.07.12.25 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 07 Dec 2017 07:12:27 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.7.6.170621 Date: Thu, 07 Dec 2017 10:12:21 -0500 From: Carl Wallace To: Tim Hollebeek , Peter Gutmann , "saag@ietf.org" Message-ID: Thread-Topic: [saag] Status of the SCEP RFC draft Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 15:12:31 -0000 Likewise. I volunteered to be the doc shepherd for this draft after voicing objection to the historic designation earlier this year. I've implemented a couple of SCEP implementations for mobile device purposes in the last couple of years. Standards track seems like the correct designation. On 12/7/17, 10:07 AM, "saag on behalf of Tim Hollebeek" wrote: >I can confirm that SCEP is required for Apple MDM (I previously led a team >that implemented SCEP as part of a mobile security product). > >I find the perspective that SCEP is only of historical interest to be >somewhat baffling. > >-Tim > >-----Original Message----- >From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Peter Gutmann >Sent: Wednesday, December 6, 2017 8:49 PM >To: saag@ietf.org >Subject: [saag] Status of the SCEP RFC draft > >After 18 years in the draft stage, this is finally ready for publication. >The one sticking point is its status, which I think should be Standards >Track but others think should be Historic. > >The problem with Historic is two-fold, firstly RFC 2026 defines historic >as >"A specification that has been superseded by a more recent specification >or >is for any other reason considered to be obsolete is assigned to the >"Historic" >level", which is in both cases the exact opposite of what SCEP is, it's >not >superseded and it's in wider and more active use than the >marked-as-standards- track CMP and CMC. > >The second is that SCEP is in extremely wide, and active use, and is >referenced in numerous other industry standards (usually with an >apologetic >note about having to refer to a draft :-). For example Apple's OTA >profile >configuration and delivery protocol only supports SCEP, and it seems to be >the standard MDM mechanism in enterprise environments. Microsoft has >supported it as standard since Server 2003 via NDES and that's then used >to >provision mobile devices, as well as routers, firewalls, ... not to >mention >its use in SCADA, ICS, embedded, etc. There are (at least) a billion+ >devices running SCEP today. Like C, it'll probably be around forever >because so much infrastructure depends on it. > >In addition there are new implementations as recently as the last six >months, and more expected over time since it's pretty much the only >protocol >there is for automated cert provisioning of devices, or at least the only >one that's widely deployed and that works. > >So both from the RFC 2026 and the pragmatic point of view, I think this >should be published as standards-track. It's definitely not Historic in >either sense. > >Peter. >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag From nobody Thu Dec 7 07:14:40 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805A712945C for ; Thu, 7 Dec 2017 07:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 i7mKasESfViM for ; Thu, 7 Dec 2017 07:14:37 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 54906128D0D for ; Thu, 7 Dec 2017 07:14:37 -0800 (PST) Received: from [10.32.60.141] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vB7FCxu4088928 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 7 Dec 2017 08:13:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.141] From: "Paul Hoffman" To: "saag@ietf.org" Date: Thu, 07 Dec 2017 07:14:34 -0800 Message-ID: <4DFF11D3-95DE-4DA7-B11A-F53D8C0BBC0B@vpnc.org> In-Reply-To: <1512618517258.43968@cs.auckland.ac.nz> References: <1512618517258.43968@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 15:14:38 -0000 +1 to standards track. This is not a shining moment of glory for the IETF, but we need to be honest about its status. --Paul Hoffman From nobody Thu Dec 7 07:17:10 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E165129468 for ; Thu, 7 Dec 2017 07:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 QaFmnZIYQrLX for ; Thu, 7 Dec 2017 07:17:07 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10BF2128CFF for ; Thu, 7 Dec 2017 07:17:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 31066BE3E; Thu, 7 Dec 2017 15:17:05 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLIETT4qdIFo; Thu, 7 Dec 2017 15:17:05 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D6549BDF9; Thu, 7 Dec 2017 15:17:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1512659824; bh=0CbQBp/dW5cTBB+vfn+ucGlpiZHEZ7YvANgeFsG93Cc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=zjTjOJdPgyV6PUCpEM/RXAXz+0I8B/Sm/Qy+Ev+BTVhLrljrTh7iAEskvm5z9XWk8 LNw0/b43ihEaBQydZYzKfnyitOqrWynRcZ0SNRheXvUCuh9X2wdHAZBqm1nvqFbeVA r5gGNJ+N+o7p8fM7G6OkAafXKGo7C2amevHmUa4s= To: Peter Gutmann , "saag@ietf.org" References: <1512618517258.43968@cs.auckland.ac.nz> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <637c3766-b479-d38b-2948-1e30dcf85c35@cs.tcd.ie> Date: Thu, 7 Dec 2017 15:17:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1512618517258.43968@cs.auckland.ac.nz> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9sOx8OPNVvSM86BUOu4iA2W7EUQ2Fn8HT" Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 15:17:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9sOx8OPNVvSM86BUOu4iA2W7EUQ2Fn8HT Content-Type: multipart/mixed; boundary="CArcktQ9nIvj3v55kLS37EJAXNdr5M4rs"; protected-headers="v1" From: Stephen Farrell To: Peter Gutmann , "saag@ietf.org" Message-ID: <637c3766-b479-d38b-2948-1e30dcf85c35@cs.tcd.ie> Subject: Re: [saag] Status of the SCEP RFC draft References: <1512618517258.43968@cs.auckland.ac.nz> In-Reply-To: <1512618517258.43968@cs.auckland.ac.nz> --CArcktQ9nIvj3v55kLS37EJAXNdr5M4rs Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 07/12/17 03:48, Peter Gutmann wrote: > After 18 years in the draft stage, this is finally ready for publicatio= n. The > one sticking point is its status, which I think should be Standards Tra= ck but > others think should be Historic. FWIW, I think SCEP really ought be an RFC. It's an embarrassment to the IETF that it's lingered long enough to buy beer in most places;-) I haven't read the latest version, when I last looked a year-ish ago it wasn't quite done, but I'm sure it could be by now. Good enough for some kind of last-call anyway. If there was an IETF LC for it, I'd review it then if that helped. I don't think this warrants any kind of WG formation, unless it turned out (e.g. in last call reviews) that there was a big difference between the text and what's deployed. I'd be just fine with standards track, we already have multiple cert management standards track RFCs and one more won't damage anything that's not already busted, esp. if the new one is used in the wild. That said, I don't have any real skin in that game, so I don't much care about the RFC status. Cheers, S. >=20 > The problem with Historic is two-fold, firstly RFC 2026 defines histori= c as "A > specification that has been superseded by a more recent specification o= r is > for any other reason considered to be obsolete is assigned to the "Hist= oric" > level", which is in both cases the exact opposite of what SCEP is, it's= not > superseded and it's in wider and more active use than the marked-as-sta= ndards- > track CMP and CMC. >=20 > The second is that SCEP is in extremely wide, and active use, and is > referenced in numerous other industry standards (usually with an apolog= etic > note about having to refer to a draft :-). For example Apple's OTA pro= file > configuration and delivery protocol only supports SCEP, and it seems to= be the > standard MDM mechanism in enterprise environments. Microsoft has suppo= rted it > as standard since Server 2003 via NDES and that's then used to provisio= n > mobile devices, as well as routers, firewalls, ... not to mention its u= se in > SCADA, ICS, embedded, etc. There are (at least) a billion+ devices run= ning > SCEP today. Like C, it'll probably be around forever because so much > infrastructure depends on it. >=20 > In addition there are new implementations as recently as the last six m= onths, > and more expected over time since it's pretty much the only protocol th= ere is > for automated cert provisioning of devices, or at least the only one th= at's > widely deployed and that works. >=20 > So both from the RFC 2026 and the pragmatic point of view, I think this= should > be published as standards-track. It's definitely not Historic in eithe= r > sense. >=20 > Peter. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --CArcktQ9nIvj3v55kLS37EJAXNdr5M4rs-- --9sOx8OPNVvSM86BUOu4iA2W7EUQ2Fn8HT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaKVtvAAoJEC88hzaAX42iuhwH/AnLv/pmeMmNaGq1XlFpEuRE HWfl+OZDXsOF3Nkg5gUVS6n/4eWsju1D8q7s6yKuAPWf6tDuTd7cIIp9KevBzDHG KhpeDAwCxWjKkrG0op6Dyfyvp/cOoN991PSUHBt/r8+CO5/hVCHMHT7RpH0fq+zr QQ7z2ZgWZpHf5VoTa44+ckgmNOuvapyWljva6h3zddEft7Rr5rGOZ4My5nWS9ZnY w1gUqRSO3WnHsfL0vqVWmANPUdgKspMuqaJ77HjR/l5a6fIBTInFpFFArpQ+dYv5 N1g5Ff5YviDytyGeNEC8UA8cUTuYFaQhuftz4edEB0dpP+/vJ9+ANs+XLlE3/Lg= =sTFH -----END PGP SIGNATURE----- --9sOx8OPNVvSM86BUOu4iA2W7EUQ2Fn8HT-- From nobody Thu Dec 7 08:38:17 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6E9120713 for ; Thu, 7 Dec 2017 08:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 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, URIBL_BLOCKED=0.001, 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 T4-OhR1UyOcF for ; Thu, 7 Dec 2017 08:38:15 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0031201FA for ; Thu, 7 Dec 2017 08:38:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37590; q=dns/txt; s=iport; t=1512664694; x=1513874294; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qmb1PZcOHxQ2xfktkuX6q659xq6/YRm/X/xlPT/Mx1o=; b=bdlvWN1cZIqeaCyFxmyyH7e80URJmBC3SHiH79dF15aH7Ayk6G0ZKEtH XIV/pT0hmdpUysxpup/5AJDwKRBNaNEFVjLqdwjxq2HJmYpCpXcLHS55D p0TM3LW+qpDD4Z/B8KcWfXJks4bsWY1Fs7qcRMbM1XaJKcoCbP2Q+H3RJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AAD/bSla/40NJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKdGZyJweDe4ogjn+BV5cvghIDChgBCoUYAhqFST8YAQEBAQE?= =?us-ascii?q?BAQEBayiFIwIBAwEBIUkCBgIDEAIBCDgBBgMCAgIlCxQRAgQOBYlDZBCncoIni?= =?us-ascii?q?lYBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYNZggqDPykLgneFCy2CfjGCMgWjAQK?= =?us-ascii?q?VG4IWihqHLJYsAhEZAYE6AR85gU9vFToqAYF+glIcgWd4iU+BFQEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,373,1508803200"; d="scan'208,217";a="323485476" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Dec 2017 16:38:13 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id vB7GcDht031535 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Dec 2017 16:38:13 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 7 Dec 2017 10:38:12 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1320.000; Thu, 7 Dec 2017 10:38:12 -0600 From: "Max Pritikin (pritikin)" To: Stephen Farrell CC: Peter Gutmann , "saag@ietf.org" Thread-Topic: [saag] Status of the SCEP RFC draft Thread-Index: AQHTbw4UUnneaIh1UU6hdrWtX9hT6aM4Y1eAgAAWrQA= Date: Thu, 7 Dec 2017 16:38:12 +0000 Message-ID: <0DC39419-3923-4448-A785-A61920CB3B42@cisco.com> References: <1512618517258.43968@cs.auckland.ac.nz> <637c3766-b479-d38b-2948-1e30dcf85c35@cs.tcd.ie> In-Reply-To: <637c3766-b479-d38b-2948-1e30dcf85c35@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.5] Content-Type: multipart/alternative; boundary="_000_0DC3941939234448A785A61920CB3B42ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 16:38:17 -0000 --_000_0DC3941939234448A785A61920CB3B42ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2luY2UgSeKAmW0gaW4gdGhlIGlyb25pYyBwb3NpdGlvbiBvZiBoYXZpbmcgd3JpdHRlbiBtdWNo IG9mIFNDRVAsIG1haW50YWluZWQgdGhlIGRvYyBmb3IgeWVhcnMsIGFuZCB0aGVuIGZvcndhcmQg bXVjaCBvZiB0aGUgdmFsdWUgaW50byBFU1QgKFJGQzcwMzApIHRvIGdhaW4gZWxsaXB0aWMgY3Vy dmUgc3VwcG9ydCBhbmQgYXJ0aWN1bGF0ZSBDTUMgYWxpZ25tZW50IGFuZCB0byBhdm9pZCAicHJv cGFnYXRpb24gb2Ygc3RhbmRhcmRzIiBJIHN1cHBvc2UgSeKAmWxsIGNoaXAgaW7igKYgYWx0aG91 Z2ggaW4gdGhlIGxhdGVzdCBkcmFmdCBvbmx5IFBldGVyIGlzIGxpc3RlZCBhcyBhbiBhdXRob3Iu DQoNCknigJl2ZSBiZWxpZXZlZCBmb3IgYSB3aGlsZSB0aGF0IHJlY29nbml6aW5nIFNDRVAgYXMg YSBzdGFuZGFyZHMgdHJhY2sgUkZDIGlzIGEgcmVjb2duaXRpb24gb2YgcmVhbGl0eS4gSXJvbmlj YWxseSBpdOKAmWQgYmUgZWFzaWVyIHRvIGV4cGxhaW4gdGhlIGFzcGVjdHMgb2YgdGhlIHByb3Rv Y29sIHRoYXQgYXJlIOKAnG91dGRhdGVk4oCdIChvciDigJxoaXN0b3JpY+KAnSkgaWYgdGhhdCBy ZWFsaXR5IGhhZCBiZWVuIHJlY29nbml6ZWQgbG9uZyBhZ28uIE15IGxhc3QgdXBkYXRlcyB0byB0 aGUgU0NFUCBpbnRyb2R1Y3Rpb24gcmVmbGVjdGVkIHRoYXQgcmVhbGl0eSBhcyB3ZSBtb3ZlZCB0 b3dhcmQgRVNUIGFzIHRoZSBjb21wcm9taXNlLiBQZXRlcuKAmXMgdXBkYXRlcyB0byB0aGF0IHRl eHQgaGFzIHJlZHVjZWQgdGhlIGFzc2VydGlvbiB0aGF0IENNQy9DTVAgKG9yIEVTVCkg4oCcU0hP VUxE4oCdIGJlIHVzZWQgdG8gYSBzdGF0ZW1lbnQgdGhhdCB0aGV5IOKAnE1BWeKAnSBiZSB1c2Vk LiBJbiB0aGUgY29udGV4dCBvZiB0aGlzIGNvbnZlcnNhdGlvbjsgd2UgbmVlZCB0aGlzIHRleHQg dG8gYWNjdXJhdGVseSByZWZsZWN0IHRoZSBwb3NpdGlvbiBvZiBJRVRGIChwcmVzdW1hYmx5IHRo ZSBvdXRwdXQgb2YgdGhpcyB0aHJlYWQpLg0KDQotIG1heA0KDQoNCk9uIERlYyA3LCAyMDE3LCBh dCA4OjE3IEFNLCBTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8bWFp bHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+PiB3cm90ZToNCg0KDQoNCk9uIDA3LzEyLzE3 IDAzOjQ4LCBQZXRlciBHdXRtYW5uIHdyb3RlOg0KQWZ0ZXIgMTggeWVhcnMgaW4gdGhlIGRyYWZ0 IHN0YWdlLCB0aGlzIGlzIGZpbmFsbHkgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLiBUaGUNCm9uZSBz dGlja2luZyBwb2ludCBpcyBpdHMgc3RhdHVzLCB3aGljaCBJIHRoaW5rIHNob3VsZCBiZSBTdGFu ZGFyZHMgVHJhY2sgYnV0DQpvdGhlcnMgdGhpbmsgc2hvdWxkIGJlIEhpc3RvcmljLg0KDQpGV0lX LCBJIHRoaW5rIFNDRVAgcmVhbGx5IG91Z2h0IGJlIGFuIFJGQy4gSXQncyBhbg0KZW1iYXJyYXNz bWVudCB0byB0aGUgSUVURiB0aGF0IGl0J3MgbGluZ2VyZWQgbG9uZw0KZW5vdWdoIHRvIGJ1eSBi ZWVyIGluIG1vc3QgcGxhY2VzOy0pDQoNCkkgaGF2ZW4ndCByZWFkIHRoZSBsYXRlc3QgdmVyc2lv biwgd2hlbiBJIGxhc3QgbG9va2VkIGENCnllYXItaXNoIGFnbyBpdCB3YXNuJ3QgcXVpdGUgZG9u ZSwgYnV0IEknbSBzdXJlIGl0IGNvdWxkDQpiZSBieSBub3cuIEdvb2QgZW5vdWdoIGZvciBzb21l IGtpbmQgb2YgbGFzdC1jYWxsIGFueXdheS4NCklmIHRoZXJlIHdhcyBhbiBJRVRGIExDIGZvciBp dCwgSSdkIHJldmlldyBpdCB0aGVuIGlmDQp0aGF0IGhlbHBlZC4gSSBkb24ndCB0aGluayB0aGlz IHdhcnJhbnRzIGFueSBraW5kIG9mDQpXRyBmb3JtYXRpb24sIHVubGVzcyBpdCB0dXJuZWQgb3V0 IChlLmcuIGluIGxhc3QgY2FsbA0KcmV2aWV3cykgdGhhdCB0aGVyZSB3YXMgYSBiaWcgZGlmZmVy ZW5jZSBiZXR3ZWVuIHRoZQ0KdGV4dCBhbmQgd2hhdCdzIGRlcGxveWVkLg0KDQpJJ2QgYmUganVz dCBmaW5lIHdpdGggc3RhbmRhcmRzIHRyYWNrLCB3ZSBhbHJlYWR5DQpoYXZlIG11bHRpcGxlIGNl cnQgbWFuYWdlbWVudCBzdGFuZGFyZHMgdHJhY2sgUkZDcw0KYW5kIG9uZSBtb3JlIHdvbid0IGRh bWFnZSBhbnl0aGluZyB0aGF0J3Mgbm90IGFscmVhZHkNCmJ1c3RlZCwgZXNwLiBpZiB0aGUgbmV3 IG9uZSBpcyB1c2VkIGluIHRoZSB3aWxkLiBUaGF0DQpzYWlkLCBJIGRvbid0IGhhdmUgYW55IHJl YWwgc2tpbiBpbiB0aGF0IGdhbWUsIHNvIEkNCmRvbid0IG11Y2ggY2FyZSBhYm91dCB0aGUgUkZD IHN0YXR1cy4NCg0KQ2hlZXJzLA0KUy4NCg0KDQpUaGUgcHJvYmxlbSB3aXRoIEhpc3RvcmljIGlz IHR3by1mb2xkLCBmaXJzdGx5IFJGQyAyMDI2IGRlZmluZXMgaGlzdG9yaWMgYXMgIkENCnNwZWNp ZmljYXRpb24gdGhhdCBoYXMgYmVlbiBzdXBlcnNlZGVkIGJ5IGEgbW9yZSByZWNlbnQgc3BlY2lm aWNhdGlvbiBvciBpcw0KZm9yIGFueSBvdGhlciByZWFzb24gY29uc2lkZXJlZCB0byBiZSBvYnNv bGV0ZSBpcyBhc3NpZ25lZCB0byB0aGUgIkhpc3RvcmljIg0KbGV2ZWwiLCB3aGljaCBpcyBpbiBi b3RoIGNhc2VzIHRoZSBleGFjdCBvcHBvc2l0ZSBvZiB3aGF0IFNDRVAgaXMsIGl0J3Mgbm90DQpz dXBlcnNlZGVkIGFuZCBpdCdzIGluIHdpZGVyIGFuZCBtb3JlIGFjdGl2ZSB1c2UgdGhhbiB0aGUg bWFya2VkLWFzLXN0YW5kYXJkcy0NCnRyYWNrIENNUCBhbmQgQ01DLg0KDQpUaGUgc2Vjb25kIGlz IHRoYXQgU0NFUCBpcyBpbiBleHRyZW1lbHkgd2lkZSwgYW5kIGFjdGl2ZSB1c2UsIGFuZCBpcw0K cmVmZXJlbmNlZCBpbiBudW1lcm91cyBvdGhlciBpbmR1c3RyeSBzdGFuZGFyZHMgKHVzdWFsbHkg d2l0aCBhbiBhcG9sb2dldGljDQpub3RlIGFib3V0IGhhdmluZyB0byByZWZlciB0byBhIGRyYWZ0 IDotKS4gIEZvciBleGFtcGxlIEFwcGxlJ3MgT1RBIHByb2ZpbGUNCmNvbmZpZ3VyYXRpb24gYW5k IGRlbGl2ZXJ5IHByb3RvY29sIG9ubHkgc3VwcG9ydHMgU0NFUCwgYW5kIGl0IHNlZW1zIHRvIGJl IHRoZQ0Kc3RhbmRhcmQgTURNIG1lY2hhbmlzbSBpbiBlbnRlcnByaXNlIGVudmlyb25tZW50cy4g IE1pY3Jvc29mdCBoYXMgc3VwcG9ydGVkIGl0DQphcyBzdGFuZGFyZCBzaW5jZSBTZXJ2ZXIgMjAw MyB2aWEgTkRFUyBhbmQgdGhhdCdzIHRoZW4gdXNlZCB0byBwcm92aXNpb24NCm1vYmlsZSBkZXZp Y2VzLCBhcyB3ZWxsIGFzIHJvdXRlcnMsIGZpcmV3YWxscywgLi4uIG5vdCB0byBtZW50aW9uIGl0 cyB1c2UgaW4NClNDQURBLCBJQ1MsIGVtYmVkZGVkLCBldGMuICBUaGVyZSBhcmUgKGF0IGxlYXN0 KSBhIGJpbGxpb24rIGRldmljZXMgcnVubmluZw0KU0NFUCB0b2RheS4gIExpa2UgQywgaXQnbGwg cHJvYmFibHkgYmUgYXJvdW5kIGZvcmV2ZXIgYmVjYXVzZSBzbyBtdWNoDQppbmZyYXN0cnVjdHVy ZSBkZXBlbmRzIG9uIGl0Lg0KDQpJbiBhZGRpdGlvbiB0aGVyZSBhcmUgbmV3IGltcGxlbWVudGF0 aW9ucyBhcyByZWNlbnRseSBhcyB0aGUgbGFzdCBzaXggbW9udGhzLA0KYW5kIG1vcmUgZXhwZWN0 ZWQgb3ZlciB0aW1lIHNpbmNlIGl0J3MgcHJldHR5IG11Y2ggdGhlIG9ubHkgcHJvdG9jb2wgdGhl cmUgaXMNCmZvciBhdXRvbWF0ZWQgY2VydCBwcm92aXNpb25pbmcgb2YgZGV2aWNlcywgb3IgYXQg bGVhc3QgdGhlIG9ubHkgb25lIHRoYXQncw0Kd2lkZWx5IGRlcGxveWVkIGFuZCB0aGF0IHdvcmtz Lg0KDQpTbyBib3RoIGZyb20gdGhlIFJGQyAyMDI2IGFuZCB0aGUgcHJhZ21hdGljIHBvaW50IG9m IHZpZXcsIEkgdGhpbmsgdGhpcyBzaG91bGQNCmJlIHB1Ymxpc2hlZCBhcyBzdGFuZGFyZHMtdHJh Y2suICBJdCdzIGRlZmluaXRlbHkgbm90IEhpc3RvcmljIGluIGVpdGhlcg0Kc2Vuc2UuDQoNClBl dGVyLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNh YWcgbWFpbGluZyBsaXN0DQpzYWFnQGlldGYub3JnPG1haWx0bzpzYWFnQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFnDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNhYWcgbWFpbGluZyBsaXN0DQpz YWFnQGlldGYub3JnPG1haWx0bzpzYWFnQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zYWFnDQoNCg== --_000_0DC3941939234448A785A61920CB3B42ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <24C2E9E99F065844A0880CCC69AA0D4D@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KU2luY2UgSeKAmW0gaW4gdGhlIGly b25pYyBwb3NpdGlvbiBvZiBoYXZpbmcgd3JpdHRlbiBtdWNoIG9mIFNDRVAsIG1haW50YWluZWQg dGhlIGRvYyBmb3IgeWVhcnMsIGFuZCB0aGVuIGZvcndhcmQgbXVjaCBvZiB0aGUgdmFsdWUgaW50 byBFU1QgKFJGQzcwMzApIHRvIGdhaW4gZWxsaXB0aWMgY3VydmUgc3VwcG9ydCBhbmQgYXJ0aWN1 bGF0ZSBDTUMgYWxpZ25tZW50IGFuZCB0byBhdm9pZCAmcXVvdDtwcm9wYWdhdGlvbiBvZiBzdGFu ZGFyZHMmcXVvdDsgSSBzdXBwb3NlDQogSeKAmWxsIGNoaXAgaW7igKYgYWx0aG91Z2ggaW4gdGhl IGxhdGVzdCBkcmFmdCBvbmx5IFBldGVyIGlzIGxpc3RlZCBhcyBhbiBhdXRob3IuJm5ic3A7DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5J4oCZdmUg YmVsaWV2ZWQgZm9yIGEgd2hpbGUgdGhhdCByZWNvZ25pemluZyBTQ0VQIGFzIGEgc3RhbmRhcmRz IHRyYWNrIFJGQyBpcyBhIHJlY29nbml0aW9uIG9mIHJlYWxpdHkuIElyb25pY2FsbHkgaXTigJlk IGJlIGVhc2llciB0byBleHBsYWluIHRoZSBhc3BlY3RzIG9mIHRoZSBwcm90b2NvbCB0aGF0IGFy ZSDigJxvdXRkYXRlZOKAnSAob3Ig4oCcaGlzdG9yaWPigJ0pIGlmIHRoYXQgcmVhbGl0eSBoYWQg YmVlbiByZWNvZ25pemVkIGxvbmcNCiBhZ28uIE15IGxhc3QgdXBkYXRlcyB0byB0aGUgU0NFUCBp bnRyb2R1Y3Rpb24gcmVmbGVjdGVkIHRoYXQgcmVhbGl0eSBhcyB3ZSBtb3ZlZCB0b3dhcmQgRVNU IGFzIHRoZSBjb21wcm9taXNlLiBQZXRlcuKAmXMgdXBkYXRlcyB0byB0aGF0IHRleHQgaGFzIHJl ZHVjZWQgdGhlIGFzc2VydGlvbiB0aGF0IENNQy9DTVAgKG9yIEVTVCkg4oCcU0hPVUxE4oCdIGJl IHVzZWQgdG8gYSBzdGF0ZW1lbnQgdGhhdCB0aGV5IOKAnE1BWeKAnSBiZSB1c2VkLiBJbiB0aGUg Y29udGV4dA0KIG9mIHRoaXMgY29udmVyc2F0aW9uOyB3ZSBuZWVkIHRoaXMgdGV4dCB0byBhY2N1 cmF0ZWx5IHJlZmxlY3QgdGhlIHBvc2l0aW9uIG9mIElFVEYgKHByZXN1bWFibHkgdGhlIG91dHB1 dCBvZiB0aGlzIHRocmVhZCkuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tIG1heDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gRGVjIDcsIDIwMTcsIGF0 IDg6MTcgQU0sIFN0ZXBoZW4gRmFycmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXBoZW4uZmFy cmVsbEBjcy50Y2QuaWUiIGNsYXNzPSIiPnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8L2E+Jmd0 OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8 ZGl2IGNsYXNzPSIiPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9 IiI+T24NCiAwNy8xMi8xNyAwMzo0OCwgUGV0ZXIgR3V0bWFubiB3cm90ZTo8L3NwYW4+PGJyIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IiBjbGFzcz0iIj4NCkFmdGVyIDE4IHllYXJzIGluIHRoZSBkcmFmdCBzdGFnZSwg dGhpcyBpcyBmaW5hbGx5IHJlYWR5IGZvciBwdWJsaWNhdGlvbi4gVGhlPGJyIGNsYXNzPSIiPg0K b25lIHN0aWNraW5nIHBvaW50IGlzIGl0cyBzdGF0dXMsIHdoaWNoIEkgdGhpbmsgc2hvdWxkIGJl IFN0YW5kYXJkcyBUcmFjayBidXQ8YnIgY2xhc3M9IiI+DQpvdGhlcnMgdGhpbmsgc2hvdWxkIGJl IEhpc3RvcmljLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBp bmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkZXSVcsDQogSSB0aGluayBTQ0VQIHJlYWxseSBv dWdodCBiZSBhbiBSRkMuIEl0J3MgYW48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1w b3J0YW50OyIgY2xhc3M9IiI+ZW1iYXJyYXNzbWVudA0KIHRvIHRoZSBJRVRGIHRoYXQgaXQncyBs aW5nZXJlZCBsb25nPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNs YXNzPSIiPmVub3VnaA0KIHRvIGJ1eSBiZWVyIGluIG1vc3QgcGxhY2VzOy0pPC9zcGFuPjxiciBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJy IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxM3B4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5v bmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+SQ0KIGhhdmVuJ3QgcmVh ZCB0aGUgbGF0ZXN0IHZlcnNpb24sIHdoZW4gSSBsYXN0IGxvb2tlZCBhPC9zcGFuPjxiciBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBk aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPnllYXItaXNoDQogYWdvIGl0IHdh c24ndCBxdWl0ZSBkb25lLCBidXQgSSdtIHN1cmUgaXQgY291bGQ8L3NwYW4+PGJyIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3Bs YXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+YmUNCiBieSBub3cuIEdvb2QgZW5vdWdo IGZvciBzb21lIGtpbmQgb2YgbGFzdC1jYWxsIGFueXdheS48L3NwYW4+PGJyIHN0eWxlPSJmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6 IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+SWYNCiB0aGVyZSB3YXMgYW4gSUVURiBMQyBm b3IgaXQsIEknZCByZXZpZXcgaXQgdGhlbiBpZjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj50aGF0DQogaGVscGVkLiBJIGRvbid0IHRoaW5rIHRoaXMg d2FycmFudHMgYW55IGtpbmQgb2Y8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0 YW50OyIgY2xhc3M9IiI+V0cNCiBmb3JtYXRpb24sIHVubGVzcyBpdCB0dXJuZWQgb3V0IChlLmcu IGluIGxhc3QgY2FsbDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBj bGFzcz0iIj5yZXZpZXdzKQ0KIHRoYXQgdGhlcmUgd2FzIGEgYmlnIGRpZmZlcmVuY2UgYmV0d2Vl biB0aGU8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+ dGV4dA0KIGFuZCB3aGF0J3MgZGVwbG95ZWQuPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu ZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+SSdkDQogYmUganVzdCBmaW5lIHdpdGggc3RhbmRhcmRz IHRyYWNrLCB3ZSBhbHJlYWR5PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFu dDsiIGNsYXNzPSIiPmhhdmUNCiBtdWx0aXBsZSBjZXJ0IG1hbmFnZW1lbnQgc3RhbmRhcmRzIHRy YWNrIFJGQ3M8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9 IiI+YW5kDQogb25lIG1vcmUgd29uJ3QgZGFtYWdlIGFueXRoaW5nIHRoYXQncyBub3QgYWxyZWFk eTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTNw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5idXN0 ZWQsDQogZXNwLiBpZiB0aGUgbmV3IG9uZSBpcyB1c2VkIGluIHRoZSB3aWxkLiBUaGF0PC9zcGFu PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxM3B4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTNweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0 OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPnNhaWQsDQogSSBk b24ndCBoYXZlIGFueSByZWFsIHNraW4gaW4gdGhhdCBnYW1lLCBzbyBJPC9zcGFuPjxiciBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBk aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPmRvbid0DQogbXVjaCBjYXJlIGFi b3V0IHRoZSBSRkMgc3RhdHVzLjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9y dGFudDsiIGNsYXNzPSIiPkNoZWVycyw8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1w b3J0YW50OyIgY2xhc3M9IiI+Uy48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1h ZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KVGhlIHByb2JsZW0gd2l0aCBIaXN0b3JpYyBpcyB0d28tZm9sZCwgZmly c3RseSBSRkMgMjAyNiBkZWZpbmVzIGhpc3RvcmljIGFzICZxdW90O0E8YnIgY2xhc3M9IiI+DQpz cGVjaWZpY2F0aW9uIHRoYXQgaGFzIGJlZW4gc3VwZXJzZWRlZCBieSBhIG1vcmUgcmVjZW50IHNw ZWNpZmljYXRpb24gb3IgaXM8YnIgY2xhc3M9IiI+DQpmb3IgYW55IG90aGVyIHJlYXNvbiBjb25z aWRlcmVkIHRvIGJlIG9ic29sZXRlIGlzIGFzc2lnbmVkIHRvIHRoZSAmcXVvdDtIaXN0b3JpYyZx dW90OzxiciBjbGFzcz0iIj4NCmxldmVsJnF1b3Q7LCB3aGljaCBpcyBpbiBib3RoIGNhc2VzIHRo ZSBleGFjdCBvcHBvc2l0ZSBvZiB3aGF0IFNDRVAgaXMsIGl0J3Mgbm90PGJyIGNsYXNzPSIiPg0K c3VwZXJzZWRlZCBhbmQgaXQncyBpbiB3aWRlciBhbmQgbW9yZSBhY3RpdmUgdXNlIHRoYW4gdGhl IG1hcmtlZC1hcy1zdGFuZGFyZHMtPGJyIGNsYXNzPSIiPg0KdHJhY2sgQ01QIGFuZCBDTUMuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIHNlY29uZCBpcyB0aGF0IFNDRVAgaXMgaW4g ZXh0cmVtZWx5IHdpZGUsIGFuZCBhY3RpdmUgdXNlLCBhbmQgaXM8YnIgY2xhc3M9IiI+DQpyZWZl cmVuY2VkIGluIG51bWVyb3VzIG90aGVyIGluZHVzdHJ5IHN0YW5kYXJkcyAodXN1YWxseSB3aXRo IGFuIGFwb2xvZ2V0aWM8YnIgY2xhc3M9IiI+DQpub3RlIGFib3V0IGhhdmluZyB0byByZWZlciB0 byBhIGRyYWZ0IDotKS4gJm5ic3A7Rm9yIGV4YW1wbGUgQXBwbGUncyBPVEEgcHJvZmlsZTxiciBj bGFzcz0iIj4NCmNvbmZpZ3VyYXRpb24gYW5kIGRlbGl2ZXJ5IHByb3RvY29sIG9ubHkgc3VwcG9y dHMgU0NFUCwgYW5kIGl0IHNlZW1zIHRvIGJlIHRoZTxiciBjbGFzcz0iIj4NCnN0YW5kYXJkIE1E TSBtZWNoYW5pc20gaW4gZW50ZXJwcmlzZSBlbnZpcm9ubWVudHMuICZuYnNwO01pY3Jvc29mdCBo YXMgc3VwcG9ydGVkIGl0PGJyIGNsYXNzPSIiPg0KYXMgc3RhbmRhcmQgc2luY2UgU2VydmVyIDIw MDMgdmlhIE5ERVMgYW5kIHRoYXQncyB0aGVuIHVzZWQgdG8gcHJvdmlzaW9uPGJyIGNsYXNzPSIi Pg0KbW9iaWxlIGRldmljZXMsIGFzIHdlbGwgYXMgcm91dGVycywgZmlyZXdhbGxzLCAuLi4gbm90 IHRvIG1lbnRpb24gaXRzIHVzZSBpbjxiciBjbGFzcz0iIj4NClNDQURBLCBJQ1MsIGVtYmVkZGVk LCBldGMuICZuYnNwO1RoZXJlIGFyZSAoYXQgbGVhc3QpIGEgYmlsbGlvbiYjNDM7IGRldmljZXMg cnVubmluZzxiciBjbGFzcz0iIj4NClNDRVAgdG9kYXkuICZuYnNwO0xpa2UgQywgaXQnbGwgcHJv YmFibHkgYmUgYXJvdW5kIGZvcmV2ZXIgYmVjYXVzZSBzbyBtdWNoPGJyIGNsYXNzPSIiPg0KaW5m cmFzdHJ1Y3R1cmUgZGVwZW5kcyBvbiBpdC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJ biBhZGRpdGlvbiB0aGVyZSBhcmUgbmV3IGltcGxlbWVudGF0aW9ucyBhcyByZWNlbnRseSBhcyB0 aGUgbGFzdCBzaXggbW9udGhzLDxiciBjbGFzcz0iIj4NCmFuZCBtb3JlIGV4cGVjdGVkIG92ZXIg dGltZSBzaW5jZSBpdCdzIHByZXR0eSBtdWNoIHRoZSBvbmx5IHByb3RvY29sIHRoZXJlIGlzPGJy IGNsYXNzPSIiPg0KZm9yIGF1dG9tYXRlZCBjZXJ0IHByb3Zpc2lvbmluZyBvZiBkZXZpY2VzLCBv ciBhdCBsZWFzdCB0aGUgb25seSBvbmUgdGhhdCdzPGJyIGNsYXNzPSIiPg0Kd2lkZWx5IGRlcGxv eWVkIGFuZCB0aGF0IHdvcmtzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNvIGJvdGgg ZnJvbSB0aGUgUkZDIDIwMjYgYW5kIHRoZSBwcmFnbWF0aWMgcG9pbnQgb2YgdmlldywgSSB0aGlu ayB0aGlzIHNob3VsZDxiciBjbGFzcz0iIj4NCmJlIHB1Ymxpc2hlZCBhcyBzdGFuZGFyZHMtdHJh Y2suICZuYnNwO0l0J3MgZGVmaW5pdGVseSBub3QgSGlzdG9yaWMgaW4gZWl0aGVyPGJyIGNsYXNz PSIiPg0Kc2Vuc2UuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUGV0ZXIuPGJyIGNsYXNz PSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIg Y2xhc3M9IiI+DQpzYWFnIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0 bzpzYWFnQGlldGYub3JnIiBjbGFzcz0iIj5zYWFnQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZzxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWlt cG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNz PSIiPnNhYWcNCiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86c2FhZ0BpZXRm Lm9yZyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTNweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+c2FhZ0BpZXRmLm9yZzwvYT48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2FhZyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zYWFnPC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0DC3941939234448A785A61920CB3B42ciscocom_-- From nobody Thu Dec 7 13:32:27 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11183128796 for ; Thu, 7 Dec 2017 13:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 XhISaPNf0iUL for ; Thu, 7 Dec 2017 13:32:24 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 B1508126DFE for ; Thu, 7 Dec 2017 13:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1512682343; x=1544218343; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qvvE4g9bl8c1KmeFGQdaxvm9XqpC7Q59Ig8qIUVUgTQ=; b=D9yrkUC4kC7oMZfLZbK9nm0H40MmM0+bfoculNxnFdND9q0q9mLlqDG/ q5AKfGHWuoUD5/l4T0SD/4NdrvuFnaOR400EyExHx8yRHNNfdwoPmbnIs Q3BdepYlgUD6YiFmGobDrFv5/gyRDpxEFqjbLw1rx/0OtjgF1qCkZIR9T OSDIHcOWr4y8bOz21GQ3wPZvJfvD6JB8NBA0JhQ8gCL1pe4NzltrW3Ebk QBqaKfxil0hj+pUMpjATdvAVPbHjmeN6ztrJx6p/gADF8IBRWnEIdXXIM 7x+viuH0PqoGgqxb7/pUIg8EGHdOOrKW1zDScRlK3thLSneER9m3rpYNK Q==; X-IronPort-AV: E=Sophos;i="5.45,374,1508756400"; d="scan'208";a="202145441" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from uxcn13-ogg-d.uoa.auckland.ac.nz ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Dec 2017 10:32:20 +1300 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.25) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 8 Dec 2017 10:32:20 +1300 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::78f4:a266:466b:508b]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::78f4:a266:466b:508b%14]) with mapi id 15.00.1263.000; Fri, 8 Dec 2017 10:32:20 +1300 From: Peter Gutmann To: "Max Pritikin (pritikin)" , Stephen Farrell CC: "saag@ietf.org" Thread-Topic: [saag] Status of the SCEP RFC draft Thread-Index: AQHTbw4UUnneaIh1UU6hdrWtX9hT6aM3JNSAgAAWrQCAASviVg== Date: Thu, 7 Dec 2017 21:32:19 +0000 Message-ID: <1512682339445.43313@cs.auckland.ac.nz> References: <1512618517258.43968@cs.auckland.ac.nz> <637c3766-b479-d38b-2948-1e30dcf85c35@cs.tcd.ie>, <0DC39419-3923-4448-A785-A61920CB3B42@cisco.com> In-Reply-To: <0DC39419-3923-4448-A785-A61920CB3B42@cisco.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 21:32:26 -0000 Max Pritikin (pritikin) writes:=0A= =0A= >in the latest draft only Peter is listed as an author. =0A= =0A= Just to clarify this a bit, the previous authors asked that their names be = =0A= removed from the top because they were no longer involved with the work =0A= and/or didn't want to keep getting bugged about it. It wasn't an attempt= =0A= to claim ownership of the spec, and I hope the acknowledgements make it =0A= clear who the original authors were. If it's not clear, let me know so I= =0A= can fix it.=0A= =0A= Peter.=0A= From nobody Fri Dec 8 05:13:14 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D31C127058 for ; Fri, 8 Dec 2017 05:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 APCJASvsFOUz for ; Fri, 8 Dec 2017 05:13:08 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 35A8B12704B for ; Fri, 8 Dec 2017 05:13:08 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id w10so25759373qtb.10 for ; Fri, 08 Dec 2017 05:13:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/hfpTUgNJ14t4dLZX0pE2HszrkJdIMGYQdOqq5XBQdc=; b=MKVl/I1jGDUo3eNcrr1mn9Gm5zSKp8IoA5Kysc+HDm3x1bqx0vCKziEvakTT+bC4h5 CnlNX/KPq5RhhqKzKb6w0DRF99cCpr7DIghXDiYkMLRVMCXKvAb2kmQh9dGTEmacH4/A AHS0F74pAgYBseFlZrAZ8a8gkhdGTidmRq2NHh2O85iYdJyZ1kdI5wIrtuNwdD8STRbh 2F2Tgu90IWVJF10e/jfy/byu0zql8dFymp1h70jR3QkAV9JVn5K6zHbUXzGtemp77reN L+sGt07bPyD/rDIOsx6SjpAwNGXf09VxwVKIVGGXe+b8a/49TFFaJ7eWX9+D/dOnVpeo QxDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/hfpTUgNJ14t4dLZX0pE2HszrkJdIMGYQdOqq5XBQdc=; b=KpFTkrOvaxS6ih/DLWKzknKJ5vwItctko6K6mzaMg4Gb8L1rjHPEAea38+zJs3I8vp HcIM7RskofHIOKE4ijQG6uSLRmaTOk7ObvFCdY2W8yrm7POwyjYtB22xpCTPc53qjTyv NEuKgQxUh47i5S7CwcCBlPNgY9v2qNA7cP51j1lmxxW/JA4Re9rxlgZqwqeTDfSF6vz6 rOFHQrZTk0LQCY0EFYaeyedxYVCj9ILndWE/H0SRQu5ywalX8UX1autMNmHNfeUQ3cQX lc6bL6GQbW8kgm4ioTCGOUFMGj5Pym84LPG+Cx8IxIqfild+UKm17X7ZCDp9G+1b9oAe DOmw== X-Gm-Message-State: AKGB3mJQw0+6ESSQ65LGZZxHkAT3fmLXMtRiydtxJnltorofpQdetWTx 70JH725XFnslDBiyD20ULHK07Soc X-Google-Smtp-Source: AGs4zMYuqIlkWE8FOcR8Ff8iD8tlaepQSLCDZHh89wiR3aG99CZAY9BFNqzew/XS+/gBaZjaAG5SnA== X-Received: by 10.200.46.167 with SMTP id h36mr15575538qta.267.1512738787141; Fri, 08 Dec 2017 05:13:07 -0800 (PST) Received: from [10.111.222.236] (209-6-112-84.s338.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.112.84]) by smtp.gmail.com with ESMTPSA id g8sm4356783qth.68.2017.12.08.05.13.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Dec 2017 05:13:05 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: <1512682339445.43313@cs.auckland.ac.nz> Date: Fri, 8 Dec 2017 08:13:04 -0500 Cc: "Max Pritikin (pritikin)" , Stephen Farrell , "saag@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2CB43D39-AB8C-47F9-8E8D-745938E2E370@gmail.com> References: <1512618517258.43968@cs.auckland.ac.nz> <637c3766-b479-d38b-2948-1e30dcf85c35@cs.tcd.ie> <0DC39419-3923-4448-A785-A61920CB3B42@cisco.com> <1512682339445.43313@cs.auckland.ac.nz> To: Peter Gutmann Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 13:13:13 -0000 Sent from my mobile device > On Dec 7, 2017, at 4:32 PM, Peter Gutmann wrot= e: >=20 > Max Pritikin (pritikin) writes: >=20 >> in the latest draft only Peter is listed as an author.=20 >=20 > Just to clarify this a bit, the previous authors asked that their names be= =20 > removed from the top because they were no longer involved with the work=20= > and/or didn't want to keep getting bugged about it. It wasn't an attempt > to claim ownership of the spec, and I hope the acknowledgements make it=20= > clear who the original authors were. If it's not clear, let me know so I > can fix it. More importantly, do they still like this approach or do they want their nam= es added back? Kathleen=20 >=20 > Peter. >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Fri Dec 8 18:23:46 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E35F127869 for ; Fri, 8 Dec 2017 18:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 hKnSKXn35KSm for ; Fri, 8 Dec 2017 18:23:42 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 71E47127871 for ; Fri, 8 Dec 2017 18:23:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1512786222; x=1544322222; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Mq/BY2wjM2QRUCanI6B95t4ZTA+vxuF6vMy8gmriHjg=; b=wQuyw8pYDK1VpbXTllk5htRpaBDrlRT3RfIBEX6N0M2e9DCrWPaN6Y+R fSBznSXNl6noPXc2HcJ95//r2+cZ0/Mtnp/QxRkZCU2YPN3xoAxuRmSIw Mub5Cu6nhIvzQ7khDxunfYeqtKPDovfmdqHWO/zYMopfZoVjSOGM5df5d s8De54XeVnh+H1khDHvvhv3Myw6q0gX1vc3FXzIE6OYuzAo/zFUdFkhcK FGhVe5pCLxsn01tWFqDflgQdCuClQGQ7Vb2hCI1/mbo1mRRX3oc8zAXFL lXYfweUMS6CNTkyOmlVVRw3RmEg8szh6HaqKw2PJuqlNGnyWdjvmbB1wu g==; X-IronPort-AV: E=Sophos;i="5.45,380,1508756400"; d="scan'208";a="202384148" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-d.UoA.auckland.ac.nz) ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Dec 2017 15:23:14 +1300 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 9 Dec 2017 15:23:13 +1300 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::78f4:a266:466b:508b]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::78f4:a266:466b:508b%14]) with mapi id 15.00.1263.000; Sat, 9 Dec 2017 15:23:13 +1300 From: Peter Gutmann To: Kathleen Moriarty CC: "Max Pritikin (pritikin)" , Stephen Farrell , "saag@ietf.org" Thread-Topic: [saag] Status of the SCEP RFC draft Thread-Index: AQHTbw4UUnneaIh1UU6hdrWtX9hT6aM3JNSAgAAWrQCAASviVoAALSIAgAG2msY= Date: Sat, 9 Dec 2017 02:23:13 +0000 Message-ID: <1512786182178.96741@cs.auckland.ac.nz> References: <1512618517258.43968@cs.auckland.ac.nz> <637c3766-b479-d38b-2948-1e30dcf85c35@cs.tcd.ie> <0DC39419-3923-4448-A785-A61920CB3B42@cisco.com> <1512682339445.43313@cs.auckland.ac.nz>, <2CB43D39-AB8C-47F9-8E8D-745938E2E370@gmail.com> In-Reply-To: <2CB43D39-AB8C-47F9-8E8D-745938E2E370@gmail.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 02:23:45 -0000 Kathleen Moriarty writes:=0A= =0A= >More importantly, do they still like this approach or do they want their= =0A= >names added back?=0A= =0A= They were pretty clear about it at the time... I felt somewhat uncomfortabl= e=0A= about it because I didn't want to appear to be claiming ownership, I'd be= =0A= happy to re-add a name or names if the authors want. Or Alan Smithee :-).= =0A= =0A= Peter.=0A= From nobody Sat Dec 9 00:31:33 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE82A124BFA for ; Sat, 9 Dec 2017 00:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 Fp4tvJnZsc6r for ; Sat, 9 Dec 2017 00:31:31 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7FB124BE8 for ; Sat, 9 Dec 2017 00:31:31 -0800 (PST) Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id A78FA1022405E for ; Sat, 9 Dec 2017 00:31:30 -0800 (PST) To: saag@ietf.org References: <1512618517258.43968@cs.auckland.ac.nz> From: Dan Harkins Message-ID: <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> Date: Sat, 9 Dec 2017 00:31:30 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1512618517258.43968@cs.auckland.ac.nz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 08:31:33 -0000   You mention the "extremely wide" use of SCEP after you suggest that it needs standards track status. If people have been able to implement it after all these years what's the compelling case to get an RFC as a stable reference? To avoid apologetic reference? Not too compelling!   Given its limitations, I question why anyone would want to implement SCEP when a superior alternative, EST (RFC 7030), exists. I understand Apple implemented SCEP for it's MDM solution. Not having any insight into Apple's decision making I can only surmise why they would implement an inferior certificate enrollment protocol, and that surmising is that the reason was not technical.   SCEP deserves historic status because at the time it was proposed (a historic moment back in the late 20th century) it was the best protocol to solve the problem, and now it's not. Standards Track would enable SCEP to be referenced by future Standards Track protocols and that would be really bad. All references to IETF standards for certificate enrollment protocols going forward should be to EST (RFC 7030).   Dan. On 12/6/17 7:48 PM, Peter Gutmann wrote: > After 18 years in the draft stage, this is finally ready for publication. The > one sticking point is its status, which I think should be Standards Track but > others think should be Historic. > > The problem with Historic is two-fold, firstly RFC 2026 defines historic as "A > specification that has been superseded by a more recent specification or is > for any other reason considered to be obsolete is assigned to the "Historic" > level", which is in both cases the exact opposite of what SCEP is, it's not > superseded and it's in wider and more active use than the marked-as-standards- > track CMP and CMC. > > The second is that SCEP is in extremely wide, and active use, and is > referenced in numerous other industry standards (usually with an apologetic > note about having to refer to a draft :-). For example Apple's OTA profile > configuration and delivery protocol only supports SCEP, and it seems to be the > standard MDM mechanism in enterprise environments. Microsoft has supported it > as standard since Server 2003 via NDES and that's then used to provision > mobile devices, as well as routers, firewalls, ... not to mention its use in > SCADA, ICS, embedded, etc. There are (at least) a billion+ devices running > SCEP today. Like C, it'll probably be around forever because so much > infrastructure depends on it. > > In addition there are new implementations as recently as the last six months, > and more expected over time since it's pretty much the only protocol there is > for automated cert provisioning of devices, or at least the only one that's > widely deployed and that works. > > So both from the RFC 2026 and the pragmatic point of view, I think this should > be published as standards-track. It's definitely not Historic in either > sense. > > Peter. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Sat Dec 9 05:04:28 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD6C1243F3 for ; Sat, 9 Dec 2017 05:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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=redhoundsoftware.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 gm6aS09bsAGS for ; Sat, 9 Dec 2017 05:04:25 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 DB66F128C83 for ; Sat, 9 Dec 2017 05:04:24 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id k19so29995623qtj.6 for ; Sat, 09 Dec 2017 05:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=+hQ3JD0YpFrjquinZrxhXk19vOblD2jfL8QEn5aP2+8=; b=vJi/mNXHXZEQHudvbjp+LMCEFbKIWjQPKUT7uPf2RyUVT+IJUKG0m0BffR4QbEf9z/ 8/2ukps3hGUmYODieJvNvfT+iasC8JzpOYTR93ETJD+mctFYNu0SjG1E+79HsQ61n+IU 6YlP3M+U2t+ThIiiUTK3uxaUTTBLxk76Sgs1w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=+hQ3JD0YpFrjquinZrxhXk19vOblD2jfL8QEn5aP2+8=; b=PZcMY//3KWl++7KGsQex6v8oCIUm8M7XMVwBF4eDLBqCmLp5F4KLOPHKm+OfVjOxJ1 AyT/NK+XJkCS4Ea78Ep4bHJAF2JpzJJT6yoB5hc+P4ONVfVHT1WpS8K/srqNNdCuvMB9 dLUqwiKxahTNLCpVLyKfO88ojJDES6Vl4DPIq14/8O9ndGUqFvXt2dym+gc6SI8QHF73 kvfRZh1uWJp2aKqjRnlkqM1kfJoDQ8x1IB6RKe29rzC1CJ9/OI/JaSVjh/Mu5xquxScB kkFQu/w5goDXuBdaMkTxDbwmPCUazOCerF1PGxABcCMEbLDggbTwgmJnE5CewcUJYaa2 DmRw== X-Gm-Message-State: AKGB3mK5z4M80QrjsKOjKxL2MuezefK9aX44YBubog3PXZt8IiHFSxTs IByjz/q5zqcSYo6mfushf2jhbwCC X-Google-Smtp-Source: AGs4zMazPakNaJTycTQ9Al0i7ZnibGn1KkdZYO5x2jkV8DFPsJMsViJ0ungFFCb7BYcr2tLhUuSQrg== X-Received: by 10.237.34.51 with SMTP id n48mr19886077qtc.300.1512824663888; Sat, 09 Dec 2017 05:04:23 -0800 (PST) Received: from [192.168.2.246] (pool-173-66-76-215.washdc.fios.verizon.net. [173.66.76.215]) by smtp.googlemail.com with ESMTPSA id w41sm1480074qtc.19.2017.12.09.05.04.19 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 09 Dec 2017 05:04:22 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.7.6.170621 Date: Sat, 09 Dec 2017 08:04:16 -0500 From: Carl Wallace To: Dan Harkins , Message-ID: Thread-Topic: [saag] Status of the SCEP RFC draft References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> In-Reply-To: <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 13:04:27 -0000 Inline... On 12/9/17, 3:31 AM, "saag on behalf of Dan Harkins" wrote: > > You mention the "extremely wide" use of SCEP after you suggest that it >needs standards track status. If people have been able to implement it >after >all these years what's the compelling case to get an RFC as a stable >reference? To avoid apologetic reference? Not too compelling! [CW] It's not just to avoid an "apologetic reference", though it's certainly easier to reference RFCXXXX than to remember "nourse" and "23". There are some algorithm updates in the new draft as well. > > Given its limitations, I question why anyone would want to implement >SCEP >when a superior alternative, EST (RFC 7030), exists. I understand Apple >implemented SCEP for it's MDM solution. Not having any insight into >Apple's >decision making I can only surmise why they would implement an inferior >certificate enrollment protocol, and that surmising is that the reason was >not technical. [CW] As Peter noted, Apple is not the only legacy SCEP to consider. There are other OS APIs that provide SCEP support but not EST and some CA products that support SCEP but not EST. > > SCEP deserves historic status because at the time it was proposed (a >historic >moment back in the late 20th century) it was the best protocol to solve >the >problem, and now it's not. Standards Track would enable SCEP to be >referenced >by future Standards Track protocols and that would be really bad. All >references >to IETF standards for certificate enrollment protocols going forward >should be >to EST (RFC 7030). [CW] It's doubtful that the the ACME folks would agree 7030 is the right reference for certificate enrollment and in some environments the best way to reference 7030 would be via 7894. There are a variety of certificate management protocols in use now, including some in still being developed. Marking SCEP as historic would not clarify the landscape in the least, nor serve to focus implementation/usage on 7030. > > Dan. > >On 12/6/17 7:48 PM, Peter Gutmann wrote: >> After 18 years in the draft stage, this is finally ready for >>publication. The >> one sticking point is its status, which I think should be Standards >>Track but >> others think should be Historic. >> >> The problem with Historic is two-fold, firstly RFC 2026 defines >>historic as "A >> specification that has been superseded by a more recent specification >>or is >> for any other reason considered to be obsolete is assigned to the >>"Historic" >> level", which is in both cases the exact opposite of what SCEP is, it's >>not >> superseded and it's in wider and more active use than the >>marked-as-standards- >> track CMP and CMC. >> >> The second is that SCEP is in extremely wide, and active use, and is >> referenced in numerous other industry standards (usually with an >>apologetic >> note about having to refer to a draft :-). For example Apple's OTA >>profile >> configuration and delivery protocol only supports SCEP, and it seems to >>be the >> standard MDM mechanism in enterprise environments. Microsoft has >>supported it >> as standard since Server 2003 via NDES and that's then used to provision >> mobile devices, as well as routers, firewalls, ... not to mention its >>use in >> SCADA, ICS, embedded, etc. There are (at least) a billion+ devices >>running >> SCEP today. Like C, it'll probably be around forever because so much >> infrastructure depends on it. >> >> In addition there are new implementations as recently as the last six >>months, >> and more expected over time since it's pretty much the only protocol >>there is >> for automated cert provisioning of devices, or at least the only one >>that's >> widely deployed and that works. >> >> So both from the RFC 2026 and the pragmatic point of view, I think this >>should >> be published as standards-track. It's definitely not Historic in either >> sense. >> >> Peter. >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag From nobody Sat Dec 9 07:35:37 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46DC126BF6 for ; Sat, 9 Dec 2017 07:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, 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 X-1VIMoDgTzR for ; Sat, 9 Dec 2017 07:35:35 -0800 (PST) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.200.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16D2C1293D6 for ; Sat, 9 Dec 2017 07:35:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 2911B51883; Sat, 9 Dec 2017 15:35:34 +0000 (UTC) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo03-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PptR__Y1DWhU; Sat, 9 Dec 2017 15:35:34 +0000 (UTC) Received: from macbook-air-2.lan (66-215-86-135.dhcp.psdn.ca.charter.com [66.215.86.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 48F5D5165B; Sat, 9 Dec 2017 15:35:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: <4DFF11D3-95DE-4DA7-B11A-F53D8C0BBC0B@vpnc.org> Date: Sat, 9 Dec 2017 07:35:28 -0800 Cc: "saag@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <079DAA75-15B0-472C-8EC8-1532CADDD769@oxy.edu> References: <1512618517258.43968@cs.auckland.ac.nz> <4DFF11D3-95DE-4DA7-B11A-F53D8C0BBC0B@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 15:35:37 -0000 +1 > On Dec 7, 2017, at 7:14 AM, Paul Hoffman = wrote: >=20 > +1 to standards track. This is not a shining moment of glory for the = IETF, but we need to be honest about its status. >=20 > --Paul Hoffman >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag Personal email. hbhotz@oxy.edu From nobody Sat Dec 9 09:12:11 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853C1126D74 for ; Sat, 9 Dec 2017 09:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xkjC3tT2H83 for ; Sat, 9 Dec 2017 09:12:08 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9871200B9 for ; Sat, 9 Dec 2017 09:12:08 -0800 (PST) Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id C684110224054; Sat, 9 Dec 2017 09:12:07 -0800 (PST) To: Carl Wallace , saag@ietf.org References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> From: Dan Harkins Message-ID: <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> Date: Sat, 9 Dec 2017 09:12:05 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 17:12:09 -0000 On 12/9/17 5:04 AM, Carl Wallace wrote: >> SCEP deserves historic status because at the time it was proposed (a >> historic >> moment back in the late 20th century) it was the best protocol to solve >> the >> problem, and now it's not. Standards Track would enable SCEP to be >> referenced >> by future Standards Track protocols and that would be really bad. All >> references >> to IETF standards for certificate enrollment protocols going forward >> should be >> to EST (RFC 7030). > [CW] It's doubtful that the the ACME folks would agree 7030 is the right > reference for certificate enrollment and in some environments the best way > to reference 7030 would be via 7894. There are a variety of certificate > management protocols in use now, including some in still being developed. > Marking SCEP as historic would not clarify the landscape in the least, nor > serve to focus implementation/usage on 7030.   At the mic in an ACME session I asked why they were rolling their own and the answer was that EST did not support verification. Which is true but not really a valid answer because after rolling their own they still had to add verification to it so they could've just used EST and added their verification as an extension. Then I was told that they were rolling their own because they didn't like ASN.1. Isn't the PKCS#10 you send ASN.1, I asked? Well, we can't get rid of it entirely.... But since both of those bad and non-technical answers would've applied to SCEP as well this is really not a reason to go Standards Track with SCEP.   Dan. From nobody Sat Dec 9 09:24:28 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6706126D05 for ; Sat, 9 Dec 2017 09:24:26 -0800 (PST) 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=redhoundsoftware.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 B_ButHvt6Zwg for ; Sat, 9 Dec 2017 09:24:25 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 39543120725 for ; Sat, 9 Dec 2017 09:24:25 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id c13so2504187qke.2 for ; Sat, 09 Dec 2017 09:24:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=yK5vSuPt7iIi256/Br10udHffB7naMbQeskGfw1aogg=; b=eb7vem+4aKi5Fo/KMvkdusy0ougzx9a2vkhRsxFxccGCxRcLgqRPz8+sJ7ZpeFB/kY 5vdi01YjHbJ7+kyn/QXcXX0dy8D7zjy+sW0V/rKwloDli+JvpaxU7iSatircOEUkKUzb mpMBWj/dKB9pJNA9L/3GkgeIaaiXFckehee2E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=yK5vSuPt7iIi256/Br10udHffB7naMbQeskGfw1aogg=; b=aLwkKNxGkj5mWs+4gSZGzusdRa/HfeAFQZVoLgdoBW9uYBdAkB81RfCLc174YkrYHn FrnitNKtSdr6w0Hfeg00RRGGH9E8oMLDmPBPnrOY2O2G8RteqkXGcV2AW1x/LmiaN9pH w9cWHdbw3ScKyyjigASUnrsKEqIVztCd+yVL5kXAKLogmFcg2rLUOKsk8bANTPPsIWFM gQ7BS3AbEYuxi7CGGN/qoUU4NUd9MYWDKYIQPyHHa4EHTB5j+lRgW+/4E2jPiFGVvtUF qfWAQMCApCM9NhkBgpBwgZsor82oBYG0Fh8ihO0h37TBYTBBtf9EhewE08LnVsFPS7SA xVwA== X-Gm-Message-State: AKGB3mIgUdubveL8UnGcOlm9R0UQJTe2OEQQe3yriV1SF+ewyX1cm2fK VFfCS0AoS17VrP6l5fc4WFZ3FVV3 X-Google-Smtp-Source: AGs4zMZGfSqjHly7N13S6A3vTCsUdXxre5Kts+fSC44YIXdeJVasrMb5hopPIisZ2MU7g19aqFvUKg== X-Received: by 10.55.25.18 with SMTP id k18mr40823544qkh.336.1512840264244; Sat, 09 Dec 2017 09:24:24 -0800 (PST) Received: from [192.168.2.246] (pool-173-66-76-215.washdc.fios.verizon.net. [173.66.76.215]) by smtp.googlemail.com with ESMTPSA id x23sm1761247qkb.4.2017.12.09.09.24.17 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 09 Dec 2017 09:24:19 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.7.6.170621 Date: Sat, 09 Dec 2017 12:24:11 -0500 From: Carl Wallace To: Dan Harkins , Message-ID: Thread-Topic: [saag] Status of the SCEP RFC draft References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> In-Reply-To: <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 17:24:27 -0000 > > At the mic in an ACME session I asked why they were rolling their own >and >the answer was that EST did not support verification. Which is true but >not >really a valid answer because after rolling their own they still had to >add >verification to it so they could've just used EST and added their >verification >as an extension. Then I was told that they were rolling their own >because they >didn't like ASN.1. Isn't the PKCS#10 you send ASN.1, I asked? Well, we >can't >get rid of it entirely.... But since both of those bad and non-technical >answers >would've applied to SCEP as well this is really not a reason to go >Standards >Track with SCEP. [CW] I agree this is not a reason for SCEP to go Standards track. The large deployed base is the primary reason. My point was that EST is not and will not be the lone way forward and thus has no bearing on SCEP's status. > > > From nobody Sun Dec 10 09:23:51 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A61126FDC for ; Sun, 10 Dec 2017 09:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=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 hvmDmWnXmw8s for ; Sun, 10 Dec 2017 09:23:47 -0800 (PST) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 7C81D1200C1 for ; Sun, 10 Dec 2017 09:23:47 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 0A10B37410ED for ; Sun, 10 Dec 2017 17:23:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id w0HQJ25mdTJm for ; Sun, 10 Dec 2017 12:23:41 -0500 (EST) Received: from Maxs-MacBook-Pro.local (cpe-67-245-75-79.nyc.res.rr.com [67.245.75.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id A45223740FCF for ; Sun, 10 Dec 2017 12:23:40 -0500 (EST) To: saag@ietf.org References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> From: "Dr. Pala" Organization: OpenCA Labs Message-ID: Date: Sun, 10 Dec 2017 12:23:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050909080607060706060409" Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 17:23:50 -0000 This is a cryptographically signed message in MIME format. --------------ms050909080607060706060409 Content-Type: multipart/alternative; boundary="------------6EF21C3860AFE07106B4ECA5" Content-Language: en-US This is a multi-part message in MIME format. --------------6EF21C3860AFE07106B4ECA5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, I just want to add to the conversation that the discussion around the=20 status of SCEP in the PKIX WG brought the group to decide that it should = not be a standard track but historical. At that time, the argument of=20 not duplicating protocols made sense since the selected way forward for=20 certificate management was CMC. Please also understand that SCEP was a one-vendor submitted protocol=20 (CISCO) that was not submitted for discussion when the WG was working on = the topic and that was presented at a later time when not much=20 discussion around it was even possible because of the existing deployment= =2E This said, one main argument that should still be considered very=20 carefully today, IMHO, is to avoid the duplication of functionalities=20 across standards. Although today it seems that duplication of=20 functionalities/protocols is not a concern (ACME is a very fitting=20 example where the push for a "sponsored" solution overthrown the=20 argument for having multiple standards that basically do the same=20 thing), I would argue that avoiding it is still a valuable principle=20 because of the following points: * *Having multiple standards that basically provide the same functionalities hurt interoperability*. In particular, for developers who might have to interact with different ecosystem, they will be required to write more code and have more complex implementation for apparently no good reasons. Having different standards for different ecosystem invalidates the concept of having standards in the first place as everybody will be doing things in their own different way. * *Having multiple standards require more effort when new functionalities need to be added and/or fixed*. Duplicate work is required to advance the status of different documents and fix possible issues that can be found at a later time. The work might be spread across different WGs and requires more coordination that does not come easily at IETF. Personally, I was under the impression that EST was the selected way=20 forward in this case (as Max Pritikin said) and that SCEP would be=20 archived as historic - I am a bit surprised to see this topic being=20 resumed again. Going back and forth with decisions that were already=20 taken seems to foster confusion.* If the above consideration still holds (EST as the way forward), then IF = there is no real NEW substantial technical work that will be=20 added/discussed to the current version of SCEP, the right choice here=20 would be, IMO, to go for historic. *Even in that case, I would say that=20 new efforts should be put toward EST and not SCEP. Whatever the decision of the AD / WG is regarding this topic (i.e.,=20 historic vs. standard track), I would suggest that the points listed=20 above should be properly and explicitly addressed in the decision. Just my 2 cents, Cheers, Max On 12/9/17 12:24 PM, Carl Wallace wrote: >> At the mic in an ACME session I asked why they were rolling their ow= n >> and >> the answer was that EST did not support verification. Which is true bu= t >> not >> really a valid answer because after rolling their own they still had t= o >> add >> verification to it so they could've just used EST and added their >> verification >> as an extension. Then I was told that they were rolling their own >> because they >> didn't like ASN.1. Isn't the PKCS#10 you send ASN.1, I asked? Well, we= >> can't >> get rid of it entirely.... But since both of those bad and non-technic= al >> answers >> would've applied to SCEP as well this is really not a reason to go >> Standards >> Track with SCEP. > [CW] I agree this is not a reason for SCEP to go Standards track. The > large deployed base is the primary reason. My point was that EST is not= > and will not be the lone way forward and thus has no bearing on SCEP's > status. >> >> > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------6EF21C3860AFE07106B4ECA5 Content-Type: multipart/related; boundary="------------6071915894620EE0648B7BCB" --------------6071915894620EE0648B7BCB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi all,

I just want to add to the conversation that the discussion around the status of SCEP in the PKIX WG brought the group to decide that it should not be a standard track but historical. At that time, the argument of not duplicating protocols made sense since the selected way forward for certificate management was CMC.

Please also understand that SCEP was a one-vendor submitted protocol (CISCO) that was not submitted for discussion when the WG was working on the topic and that was presented at a later time when not much discussion around it was even possible because of the existing deployment.

This said, one main argument that should still be considered very carefully today, IMHO, is to avoid the duplication of functionalities across standards. Although today it seems that duplication of functionalities/protocols is not a concern (ACME is a very fitting example where the push for a "sponsored" solution overthrown the argument for having multiple standards that basically do the same thing), I would argue that avoiding it is still a valuable principle because of the following points:

  • Having multiple standards that basically provide the same functionalities hurt interoperability. In particular, for developers who might have to interact with different ecosystem, they will be required to write more code and have more complex implementation for apparently no good reasons. Having different standards for different ecosystem invalidates the concept of having standards in the first place as everybody will be doing things in their own different way.

  • Having multiple standards require more effort when new functionalities need to be added and/or fixed. Duplicate work is required to advance the status of different documents and fix possible issues that can be found at a later time. The work might be spread across different WGs and requires more coordination that does not come easily at IETF.
Personally, I was under the impression that EST was the selected way forward in this case (as Max Pritikin said) and that SCEP would be archived as historic - I am a bit surprised to see this topic being resumed again. Going back and forth with decisions that were already taken seems to foster confusion.

If the above consideration still holds (EST as the way forward), then IF there is no real NEW substantial technical work that will be added/discussed to the current version of SCEP, the right choice here would be, IMO, to go for historic. Even in that case, I would say that new efforts should be put toward EST and not SCEP.

Whatever the decision of the AD / WG is regarding this topic (i.e., historic vs. standard track), I would suggest that the points listed above should be properly and explicitly addressed in the decision.
Just my 2 cents,

Cheers,
Max


On 12/9/17 12:24 PM, Carl Wallace wrote:
 At the mic in an ACME session I asked why they were rolling their own
and
the answer was that EST did not support verification. Which is true but
not
really a valid answer because after rolling their own they still had to
add
verification to it so they could've just used EST and added their
verification
as an extension. Then I was told that they were rolling their own
because they
didn't like ASN.1. Isn't the PKCS#10 you send ASN.1, I asked? Well, we
can't
get rid of it entirely.... But since both of those bad and non-technical
answers
would've applied to SCEP as well this is really not a reason to go
Standards
Track with SCEP.

[CW] I agree this is not a reason for SCEP to go Standards track. The
large deployed base is the primary reason. My point was that EST is not
and will not be the lone way forward and thus has no bearing on SCEP's
status.





_______________________________________________
saag mailing list
saag@=
ietf.org
https://www.ietf.org/mailman/listinfo/saag

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------6071915894620EE0648B7BCB Content-Type: image/png; name="opdmicbghinbholi.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="opdmicbghinbholi.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------6071915894620EE0648B7BCB-- --------------6EF21C3860AFE07106B4ECA5-- --------------ms050909080607060706060409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyAwggUyMIIEGqADAgECAhEAu2YCW4tRQdGHMc0S/FQsNDANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTcxMjAxMDAw MDAwWhcNMTgxMjAxMjM1OTU5WjAkMSIwIAYJKoZIhvcNAQkBFhNkaXJlY3RvckBvcGVuY2Eu b3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyEDKYfy+DFhtDn8bIXyP25Xe DjUIkMQDm90A1JPoQ4tuTk6kXwulPvAmvtLGuRAzEqFpV/fqz4sAlx8FgxvRZ5PunZ1H1/lJ CNEdir53Xv8TEf+R/n+Ca5RNUR+GhS72zhp9xx8uDRZds2DeXvW9uhYp9nsbX6rWIFT5YfWF 1SukFXwXSnHuXc9nDT6p0Kp6UNzusn/lMhXhIwgpNA26/mHAdScYyMoB4yaZeMpdZN75XGWO slhXcXdeGJo93E48kffdu0yo4WTbpLwhs/IrkG4OXB1N3Bf+9oHZwVun1hlCZEfuSit0mvrx x8wzPCPiggXu6j6VqPoJqecV6xKCHwIDAQABo4IB6TCCAeUwHwYDVR0jBBgwFoAUgq9sjPjF /pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFEPV9allspkmYqkQRx2BlAdbOrjhMA4GA1UdDwEB /wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggr BgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2g S4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3BlbmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEA g+REupW946f7esdYmE1QxsYlkubErxz8JLovVDSKTHwxR1/VxF/B7rGeiSPBHTmKQYwlWCrp eHZNfzaDDkDamwLXm7v4+brNfQKRpOLnYPQQffp7xim72INakLgts8d5I7bic785dj4M5JP4 XA2qUD9wduwNwquua6v7zM3chpoRjapumzLNDDr47GccOKAZYaaqFwbpwJPQYuiC07WWnn7g FzdNKYN6VM6Re6wVEHP6fEvNrleV0pf1iFjLKugnriGKL9wj6xX25JsMmGmqZcfdpnkTE4Zf eQBEZVnn8s7HBX+MA/K+YnHxRwA2c5XwNbEhZ2rvh2uFIMXBDlt+tDCCBeYwggPOoAMCAQIC EGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQ PTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivl JTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG 9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoS WY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQAB o4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKv bIz4xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEA MBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9k b2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcB AQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFk ZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJ KoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo 7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaB Q+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKS TvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+E2pvOUtY +hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnMrwfHM5td hYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9hz9D0S0U4 jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5PDEJ M/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJU mpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTK TlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIEODCCBDQCAQEw ga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01P RE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAu2YC W4tRQdGHMc0S/FQsNDANBglghkgBZQMEAgEFAKCCAlswGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMjEwMTcyMzM5WjAvBgkqhkiG9w0BCQQxIgQgCo2N IqJk+QfcL2cVkd7C2RQiJsgbx8lQZ/4OsT1dXv0wbAYJKoZIhvcNAQkPMV8wXTALBglghkgB ZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGX MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJT QSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALtmAluLUUHR hzHNEvxULDQwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALtmAluLUUHRhzHNEvxULDQwDQYJKoZIhvcNAQEB BQAEggEAOVWBqKvwh+LHFidPnjQZTPFbGsjbQDsdx0Gi8/Vexmrv+By5KA9vuHs2Ejpkq4JI ikCRGsVAY0En5nqyYAWTcRTim0Kqv4mfUxtla+sFA0nMTeQQiF7I2gh8xpKyVpSB2XhM9jqM KMcjl6SKEnJj37hQR1VJxVEPEa3qtwrAVsM2sbYBMputA+WvkfEI+xVwPUVzzMbJb8/xqv9Q W0AD+VvJmB6T+NFrEqRYqOYOlDz+ypHEtqt1VEHcA6OMxqZCf380vYGd2dHPvpbmViUNK0Vz yQ5yU4t2VPR36FNRRM4RPL059PVEyDv4ag5yyf7tbkdshfVKucTHxjamj+bpYAAAAAAAAA== --------------ms050909080607060706060409-- From nobody Sun Dec 10 11:29:06 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B56B128CFF for ; Sun, 10 Dec 2017 11:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BbN-CeMAHUy for ; Sun, 10 Dec 2017 11:28:58 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31CA8128CF0 for ; Sun, 10 Dec 2017 11:28:57 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7B2C920008 for ; Sun, 10 Dec 2017 14:32:05 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9F06480712 for ; Sun, 10 Dec 2017 14:28:56 -0500 (EST) From: Michael Richardson To: saag@ietf.org In-Reply-To: References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 19:29:00 -0000 --=-=-= Content-Type: text/plain I think that SCEP should be passed into RFC status. I think that Dan's arguments about marking it Historic are valid. I believe that the IESG can mark any document as Historic; so it might be that the appropriate process is to make it Draft Standard and then Historic if publishing a Historic document seems too daft. Given that SCEP it out there and in active use, I think that having it on rfc-editor.org and able to receive errata is the rationalization for doing this. I don't think we should spend too much effort on the document though. (Though the same arguments might apply to IKEv1 XAUTH!) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlotivYACgkQgItw+93Q 3WWxBQf+LylxnIcwTnDGpQoEG1Xh6RBwVQ6rbdz+kbdbQ7ONRIIAhf3j0PPK214H +p7UW6ysrJzJabILRFnyl9KUUoooeJDF0/orOMkua0T0uyCCT9ruJvWg6cX8Jmor nEJjdzM3FH++2KrY92O+2whN+cmVYbm/KRVql+Xsa0EAE4a5KfHjdwaUQtAEmnnP IMKsjKrFTwpFGByNxEkkPGOg1GENvaBe1Beo3JI9Ei/kWL0pqf8xjH20uqpi5BID d8d9ozLLhompdOgQ7XDh0vfzFJ+kg1nKMUBsbr15PaVosYZXdipuOHyvX/p6YPB4 BFpK8X51xjq31a4c3CaI+H4RqJJxfw== =zk74 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Dec 10 12:35:05 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071B8127201 for ; Sun, 10 Dec 2017 12:35:04 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 e_OX_if20F21 for ; Sun, 10 Dec 2017 12:35:02 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 48E95126D85 for ; Sun, 10 Dec 2017 12:35:01 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBAKX51K013108; Sun, 10 Dec 2017 20:35:00 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=KSmFMaTMBOR3dEb48Si6bEznpU/jrJQt7md+TgdxLE8=; b=GJbAEduy8Y2R+9ll8RXnxoaBVEYgyZos7Y+MWq1hRE+ntZ2zMGnutk9TzinDMl+eTdFm D83FI5Bvr7UdEIKLZ4+qCNigoMdGrs8+Vj8JfCUu++OUwcZKa2piUaIAA0Isky97e0VV goGQqflT+FwxtJWaWunxAm3osvaWghck1MuXi7lsxFLCtG1Tkh8dFgbwCpzAPLPHt5Wq Hw52mG7QLOrFCiOqjgFZI5DhSbtMQu900j+XXaNKKBKbXGjTgHO2UuaJECqMoN6I+rya dUU0n9cieZC4+6X8x7nnc/CrBGehaedY+6/3f+RuGkH0ux20QrepxDM28GQyklm4kMll MA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2er5juv34v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 10 Dec 2017 20:35:00 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vBAKUrfI012336; Sun, 10 Dec 2017 15:35:00 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2erc20mu6t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 10 Dec 2017 15:34:59 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 10 Dec 2017 15:34:59 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 10 Dec 2017 15:34:58 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Sun, 10 Dec 2017 15:34:59 -0500 From: "Salz, Rich" To: Michael Richardson , "saag@ietf.org" Thread-Topic: [saag] Status of the SCEP RFC draft Thread-Index: AQHTbw4UUnneaIh1UU6hdrWtX9hT6aM7Be4AgABMNgCAAf3OAIAAEnMA Date: Sun, 10 Dec 2017 20:34:58 +0000 Message-ID: References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <25087.1512934136@obiwan.sandelman.ca> In-Reply-To: <25087.1512934136@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.43.46] Content-Type: text/plain; charset="utf-8" Content-ID: <060DC0E81D706F45898D3818004B496B@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-10_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=752 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712100307 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-10_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=671 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712100308 Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 20:35:04 -0000 ICANCj4gICAgIEdpdmVuIHRoYXQgU0NFUCBpdCBvdXQgdGhlcmUgYW5kIGluIGFjdGl2ZSB1c2Us IEkgdGhpbmsgdGhhdCBoYXZpbmcgaXQgb24NCiAgICByZmMtZWRpdG9yLm9yZyBhbmQgYWJsZSB0 byByZWNlaXZlIGVycmF0YSBpcyB0aGUgcmF0aW9uYWxpemF0aW9uIGZvciBkb2luZw0KICAgIHRo aXMuDQogDQpBZ3JlZS4NCg0K From nobody Sun Dec 10 16:15:42 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BA1124207 for ; Sun, 10 Dec 2017 16:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 Rf2AuUFu9LbT for ; Sun, 10 Dec 2017 16:15:38 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 E87E41200F1 for ; Sun, 10 Dec 2017 16:15:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1512951338; x=1544487338; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=AmN25O7o7YVfO1t0+Q7l1kVXIkEOHTJarahLNXkan88=; b=bwCz87e837VD2TL7BHQnFEjijRLzoFQKLmuQG82r6n1G+V27F7bHCqU0 VSI3ySRsLIvSlxR26v2hxpTrI5yWzUcWUuttJRj2ottLxC4kS0N3juqqz ChdM4VKEfHoUT6eN/C/0blO+nuwfpm+lZndj98uXoRzomCle1NS1ZK/pN hd9ywDSSOJYHapnyTjm6F1+KNUaVnjttcR/d7tHkHaquL6IV/am8epxbR xr0tq62Zg3SgtYYnTUun/bt3Kalfs81LWqg/E2vwD5E9BnGfgmVfZJ9QV gzO61o8mkMpAJjBNVTVy57VjHwZMFj/jlMaND1IBEY+1lYdG26OlG0Mu7 A==; X-IronPort-AV: E=Sophos;i="5.45,391,1508756400"; d="scan'208";a="202740628" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.8 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-e.UoA.auckland.ac.nz) ([10.6.2.8]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Dec 2017 13:15:34 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.8) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 11 Dec 2017 13:15:33 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Mon, 11 Dec 2017 13:15:33 +1300 From: Peter Gutmann To: Dan Harkins , "saag@ietf.org" Thread-Topic: [saag] Status of the SCEP RFC draft Thread-Index: AQHTbw4UUnneaIh1UU6hdrWtX9hT6aM52C8AgANx0fM= Date: Mon, 11 Dec 2017 00:15:33 +0000 Message-ID: <1512951319125.76833@cs.auckland.ac.nz> References: <1512618517258.43968@cs.auckland.ac.nz>, <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> In-Reply-To: <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 00:15:41 -0000 Dan Harkins writes:=0A= =0A= Just a background note for those who aren't aware of this, Dan is one of th= e=0A= co-authors of EST / RFC 7030, thus presumably the repeated mention of that= =0A= specific RFC while completely omitting to mention the various other protoco= ls=0A= like CMP and CMC that do the same thing. I don't have an issue with that,= =0A= "everyone should be using my pet protocol" is a perfectly good motivation := -),=0A= but I just wanted to put the comments in perspective.=0A= =0A= However, to avoid turning this into a "my protocol is better than your=0A= protocol" argument, lets set EST aside and use another protocol that does t= he=0A= same thing, CMP, principally because AFAIK the authors aren't on this list = so=0A= it's not a personal issue for anyone. Dan's comments are identical whether= =0A= you say "EST" or "CMP" or "CMC" or "Xenroll" or "ACME" or whatever that XML= =0A= mechanism for requesting certs is called, if it even has a name.=0A= =0A= So:=0A= =0A= >Given its limitations, I question why anyone would want to implement SCEP= =0A= >when a superior alternative, CMP, exists.=0A= =0A= You're mistaking "more complex" for "superior". Like the traditional Unix= =0A= utility, SCEP was designed to do one thing, provision a device with a=0A= certificate, and do it well. To the credit of its authors, it does a reall= y=0A= good job at this. Nearly twenty years later, apart from the archaic use of= =0A= MD5 and single DES, the same thing that was originally published is what's = in=0A= the current draft. You can take any PKCS #7 library (although now it's cal= led=0A= CMS) and roll a SCEP implementation in a couple of hours (it's just signed= =0A= encrypted PKCS #7). My implementation, in its basic interoperable form, is = a=0A= few pages of code, and from memory it worked the first time I ran it agains= t a=0A= server.=0A= =0A= CMP, in contrast, is an absolute mess, containing every feature that everyo= ne=0A= on the standards committee could think of, in some cases several times over= in=0A= different locations. The implementation requires a quarter of a megabyte o= f=0A= code. Interoperability out of the box is pretty much impossible, there are= so=0A= many features and options and poorly-explained mechanisms that the only way= we=0A= could get two implementations to talk to each other was by finding out who= =0A= wrote the other implementation and asking them what they were doing for eac= h=0A= option in the spec.=0A= =0A= (For more on this, see=0A= https://www.usenix.org/legacy/events/sec03/tech/full_papers/gutmann/gutmann= _html/index.html,=0A= specifically "5.2 Problems with CMP", and that's the abbreviated version).= =0A= =0A= Finally, for its use in SCADA, a CMP implementation is so big and bloated a= nd=0A= requires so much manual configuration for all the options that it's a compl= ete=0A= a non-starter for embedded use. SCEP, which only does the one thing that m= ost=0A= vendors care about in this case, "get a certificate onto this box", is a fi= re-=0A= and-forget solution.=0A= =0A= And this is why both CMC and CMP have failed in the real world (CMC is used= by=0A= Microsoft because it's their protocol, CMP is used by some telcos for phone= =0A= network provisioning, typically by making sure they have the same=0A= implementation running as both client and server so they can actually talk = to=0A= each other), while SCEP has seen large amounts of use throughout the indust= ry.=0A= SCEP is simple, effective, and gets the job done.=0A= =0A= >I understand Apple implemented SCEP for it's MDM solution. Not having any= =0A= >insight into Apple's decision making I can only surmise why they would=0A= >implement an inferior certificate enrollment protocol, and that surmising = is=0A= >that the reason was not technical.=0A= =0A= Unfortunately there's no secret conspiracy behind it, the reason is purely= =0A= technical (or at least very pragmatic). If you just want to provision a=0A= device with certificates in the most straightforward manner possible, SCEP = is=0A= hard to beat. It's simple to implement, easy to interop with, gets the job= =0A= done, and is supported out of the box by the (at the time, and probably sti= ll=0A= the case) standard corporate/business server.=0A= =0A= >SCEP deserves historic status because at the time it was proposed (a histo= ric=0A= >moment back in the late 20th century) it was the best protocol to solve th= e=0A= >problem, and now it's not. =0A= =0A= The industry seems to view this very differently, given the broad deploymen= t=0A= of SCEP and the failure to launch of any of its alternatives. If CMP reall= y=0A= was superior (in the sense of giving users what they want), we wouldn't be= =0A= having this discussion.=0A= =0A= Peter.= From nobody Sun Dec 10 16:27:20 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD341127078 for ; Sun, 10 Dec 2017 16:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 0oWXdfF28HoD for ; Sun, 10 Dec 2017 16:27:16 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99372124207 for ; Sun, 10 Dec 2017 16:27:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 026D3BE51; Mon, 11 Dec 2017 00:27:14 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOy70rDaIu52; Mon, 11 Dec 2017 00:27:12 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AE8C5BE2E; Mon, 11 Dec 2017 00:27:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1512952032; bh=eRWxYCImV5Cz1lPGY0sk1YkS+dB4a2KgDjXXrhaizq8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=fD8YJt4xM0KtS9CEq5cHf8Ga7ypwHfpaFIUhbOALaGwsoAtjqffiGH50fLgtm0RBG 4MEeO3GyZpTcKBcA3UDg2hg+nBOtLEvgWFTy+9bqMaCAn2TQ4xVELRjuN7/Er7snWh JO9ESjESET9vQXsBMC4NmlByoL5gPqAlYLSF9KEk= To: Peter Gutmann , Dan Harkins , "saag@ietf.org" References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <1512951319125.76833@cs.auckland.ac.nz> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <6e1cbbd2-4965-29fa-91a9-69355ae121c3@cs.tcd.ie> Date: Mon, 11 Dec 2017 00:27:12 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1512951319125.76833@cs.auckland.ac.nz> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Wlgw0SU79xIetnFdMChk3Ow1acfPFfXRR" Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 00:27:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Wlgw0SU79xIetnFdMChk3Ow1acfPFfXRR Content-Type: multipart/mixed; boundary="jRKGXW1d56C136S6XKq3dxRaJsgShwmkB"; protected-headers="v1" From: Stephen Farrell To: Peter Gutmann , Dan Harkins , "saag@ietf.org" Message-ID: <6e1cbbd2-4965-29fa-91a9-69355ae121c3@cs.tcd.ie> Subject: Re: [saag] Status of the SCEP RFC draft References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <1512951319125.76833@cs.auckland.ac.nz> In-Reply-To: <1512951319125.76833@cs.auckland.ac.nz> --jRKGXW1d56C136S6XKq3dxRaJsgShwmkB Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable CMP co-author here... On 11/12/17 00:15, Peter Gutmann wrote: > lets set EST aside and use another protocol that does the > same thing, CMP, principally because AFAIK the authors aren't on this l= ist so > it's not a personal issue for anyone I don't think there's anything much personal here, for me at least - I've gotten over the mistakes a bunch of us (incl. me) made 20+ years ago for then-understandable and now-boring reasons. More usefully, I hope I've also learned from those mistakes;-) Separately, as it happens I don't think a supposed beauty contest between ACME/CMC/CMP/EST/SCEP will be of any benefit for anyone. Go right ahead if that's what floats your various boats I guess, but fwiw that seems pointless to me. S. --jRKGXW1d56C136S6XKq3dxRaJsgShwmkB-- --Wlgw0SU79xIetnFdMChk3Ow1acfPFfXRR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaLdDgAAoJEC88hzaAX42ityUIAJFXGxQbni/DUe8Bc/L4N6aX akJlW4U4tD9kS/99WpuTh+ZbhHdyqjw5k50kbMXt0pmyWuMsLJwQRDt2yRFYm3I/ EEyp5T/Ai2wq1QkFvrOo1fPaVzlb/smnbkGCn+JItZ1pRZLAVuCQi2vvwYF5mGJ7 SynVriAUG5ZMqIp+UJWMzUh5oieY4LnfhFPfdQ6LXFl3EkIsNqA0tm+KFhiDRmvO /RP7PwM3tN4s8P25wmumsctn2/xBziLrAxUjWHTkintBlbmNEsU4B4RwvuuxeT1A nuwKq3+KgpDuQQmdYq8LzHYUjIh1pkTmVICCLaqtxibPFip8goL1lUuIyReqcoc= =14XN -----END PGP SIGNATURE----- --Wlgw0SU79xIetnFdMChk3Ow1acfPFfXRR-- From nobody Sun Dec 10 16:28:26 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5812B1270AE for ; Sun, 10 Dec 2017 16:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 Wy_O5r7WqQoj for ; Sun, 10 Dec 2017 16:28:23 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 728E0126DCA for ; Sun, 10 Dec 2017 16:28:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1512952102; x=1544488102; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=UwHBcPjkwsGohZv493Ry20EtZZZYrpGF5hF1abcyyTQ=; b=i68Am5h+xwFDQ5xsWPGnCaCcsGxRr2YTM8CFXCkjNRkfwNLgMgvIRRzX zK6swje2bd1+BGb/MzVIIdBMyVvfITJ2QrmX+C6LsMVLxaqxpKRkUtJaA X60pZNFcvMFeU/if5WBy/RO8GpcvDnABqFVJ/6ezjZ9RAYlzxY5zT/Ffl FYf6B7RvBzUTjwNrIbMrP28DLYDQ/L7p0A57Nv9rd/cdGpL9Gop5Qgkho 5dA8Bfd06aC22Ule+pbnXduWWyJqXz9NlN3Si6dn9VmmnOz54RE74PmHB zHJgXEu5iDYeiNplXX/5FvNaGFR+LMen82xJipiKgmNp9SRTFjyxp1nsp w==; X-IronPort-AV: E=Sophos;i="5.45,391,1508756400"; d="scan'208";a="202742844" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.8 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-e.UoA.auckland.ac.nz) ([10.6.2.8]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Dec 2017 13:28:20 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.28) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 11 Dec 2017 13:28:20 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Mon, 11 Dec 2017 13:28:20 +1300 From: Peter Gutmann To: "Dr. Pala" , "saag@ietf.org" Thread-Topic: [saag] Status of the SCEP RFC draft Thread-Index: AQHTbw4UUnneaIh1UU6hdrWtX9hT6aM52C8AgABMNQCAAEU+gIAAA2GAgAGSL4CAAU7l1Q== Date: Mon, 11 Dec 2017 00:28:19 +0000 Message-ID: <1512952085878.6345@cs.auckland.ac.nz> References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 00:28:24 -0000 Dr. Pala writes:=0A= =0A= Dr. Pala writes:=0A= =0A= >Whatever the decision of the AD / WG is regarding this topic (i.e., histor= ic=0A= >vs. standard track), I would suggest that the points listed above should b= e=0A= >properly and explicitly addressed in the decision.=0A= =0A= If we were to seriously address them then we'd need to make CMC and CMP, wh= ich=0A= have failed in the marketplace, Historic, and SCEP, which has succeeded,=0A= Standards-track. Then there's ACME, whose principal selling point seems to= be=0A= that it's what you use to talk to Let's Encrypt, and EST, which is mostly= =0A= Cisco's pet standard [0], neither of which look like they're gaining much= =0A= traction outside of those areas. So you've got two Standards-tracks to=0A= Historic, two where the jury is still out but given the history of CMC and = CMP=0A= I'm not holding out much hope, and SCEP to Standards-track.=0A= =0A= Somehow I can't see that happening :-).=0A= =0A= Peter.=0A= =0A= [0] Apologies to Cisco folks, I know you guys are really keen on this but i= t's=0A= hard to work up much enthusiasm for yet another standard that does pret= ty=0A= much the same thing as CMC and CMP have already done.=0A= From nobody Sun Dec 10 19:32:38 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06F2126C26 for ; Sun, 10 Dec 2017 19:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 hwoMgDi4hIBK for ; Sun, 10 Dec 2017 19:32:34 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3ECD124B18 for ; Sun, 10 Dec 2017 19:32:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5736; q=dns/txt; s=iport; t=1512963154; x=1514172754; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=9yRO+mEdff8V61y1nYw+ezCsig06rSxkjZllj2wPHgw=; b=X/0cInoTBqVf2A+olD0JXdVydY9kcUdpI4jFtmd75bB0QVAREDEDxE2O qz6Jd44BPwxxsq/JBJCzldf5IvEP8Yeh5Zwp6zd3LXlhGnZeogb7GCR6i ctyxPDiFENr5gMO/pyAYilYzY0k5MF7J/uExElmJjr+dIMBFPp7RdRkLA g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAQAB+y1a/4wNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N7iiGOfIF9lwyCFQoYC4UYAhqERT8YAQEBAQEBAQE?= =?us-ascii?q?Bax0LhSIBAQEBAwEBIRE6BhEEAgEIEQQBAQECAhQPAwICAiULFAEICAIEEwgTi?= =?us-ascii?q?g0QpxSCJ4pjAQEBAQEBAQEBAQEBAQEBAQEBARoFgQ+CWYILgVaBaYMrhQlkgke?= =?us-ascii?q?CYwWjEQKVFpNsljECERkBgToBHzmBT28VOoIphFV4h1yBDoEVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,391,1508803200"; d="scan'208";a="42873063" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Dec 2017 03:32:33 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id vBB3WX7l002703 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 Dec 2017 03:32:33 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 10 Dec 2017 21:32:32 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1320.000; Sun, 10 Dec 2017 21:32:32 -0600 From: "Panos Kampanakis (pkampana)" To: "saag@ietf.org" Thread-Topic: [saag] Status of the SCEP RFC draft Thread-Index: AQHTcMgkxA9PjrmEOEKL5XG57gzaIqM9f6Iw Date: Mon, 11 Dec 2017 03:32:32 +0000 Message-ID: <007e47dfc6734dc38b489adc1d80b84d@XCH-ALN-010.cisco.com> References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> In-Reply-To: <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.208.131] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 03:32:37 -0000 KzEgb24gU0NFUCBiZWNvbWluZyBhbiBSRkMsICsxIG9uIGl0IGJlaW5nIGhpc3RvcmljLiANCkl0 IGRlZmluaXRlbHkgc2hvdWxkIGhhdmUgYmVlbiBTdGFuZGFyZHMgVHJhY2sgYXQgdGhlIHRpbWUs IGJ1dCB0aGF0IGRvZXMgbm90IG1lYW4gaXQgc3RpbGwgbmVlZHMgdG8uIA0KDQpUaGUgbm91cnNl LXNjZXAtMjMgdXNlZCB0byBzYXkgImZ1bGx5IHN1cHBvcnQgYWxnb3JpdGhtIGFnaWxpdHkgYnV0 IHRoZSByZXF1ZXN0ZXIgaGFzIHRvIHVzZSBhIGtleSB0eXBlIHRoYXQgaXMgc3VwcG9ydGVkIGJ5 IHRoZSBzZXJ2ZXIuICBSU0EgaXMgdGhlIG9ubHkgYWxnb3JpdGhtIHN1cHBvcnRlZCBieSBjdXJy ZW50IGltcGxlbWVudGF0aW9ucy4iIEkgZG9uJ3Qgc2VlIHRoYXQgaW4gZHJhZnQtZ3V0bWFubi1z Y2VwLTA3LCBidXQgSSBkb24ndCBrbm93IG9mIG1hbnkgU0NFUCBpbXBsZW1lbnRhdGlvbnMgdGhh dCBzdXBwb3J0IEVDQyB0b2RheSBlaXRoZXIuIEkgYWxzbyBkb24ndCBrbm93IGhvdyBtYW55IGlt cGxlbWVudGF0aW9ucyB0b2RheSBkaXN0aW5ndWlzaCBiZXR3ZWVuIGF1dGhlbnRpY2F0aW9uIGFu ZCBhdXRob3JpemF0aW9uIHdpdGgganVzdCB0aGUgQ2hhbGxlbmdlIHBhc3N3b3JkLiANCg0KUmVn YXJkbGVzcywgaW5kZWVkIFNDRVAgd2lsbCBleGlzdCBmb3IgYSB2ZXJ5IGxvbmcgdGltZSwgYW5k IHNob3VsZCBiZSBhIGhpc3RvcmljIFJGQy4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBzYWFnIFttYWlsdG86c2FhZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgRGFuIEhhcmtpbnMNClNlbnQ6IFNhdHVyZGF5LCBEZWNlbWJlciAwOSwgMjAxNyAzOjMyIEFN DQpUbzogc2FhZ0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzYWFnXSBTdGF0dXMgb2YgdGhlIFND RVAgUkZDIGRyYWZ0DQoNCg0KIMKgIFlvdSBtZW50aW9uIHRoZSAiZXh0cmVtZWx5IHdpZGUiIHVz ZSBvZiBTQ0VQIGFmdGVyIHlvdSBzdWdnZXN0IHRoYXQgaXQgbmVlZHMgc3RhbmRhcmRzIHRyYWNr IHN0YXR1cy4gSWYgcGVvcGxlIGhhdmUgYmVlbiBhYmxlIHRvIGltcGxlbWVudCBpdCBhZnRlciBh bGwgdGhlc2UgeWVhcnMgd2hhdCdzIHRoZSBjb21wZWxsaW5nIGNhc2UgdG8gZ2V0IGFuIFJGQyBh cyBhIHN0YWJsZSByZWZlcmVuY2U/IFRvIGF2b2lkIGFwb2xvZ2V0aWMgcmVmZXJlbmNlPyBOb3Qg dG9vIGNvbXBlbGxpbmchDQoNCiDCoCBHaXZlbiBpdHMgbGltaXRhdGlvbnMsIEkgcXVlc3Rpb24g d2h5IGFueW9uZSB3b3VsZCB3YW50IHRvIGltcGxlbWVudCBTQ0VQIHdoZW4gYSBzdXBlcmlvciBh bHRlcm5hdGl2ZSwgRVNUIChSRkMgNzAzMCksIGV4aXN0cy4gSSB1bmRlcnN0YW5kIEFwcGxlIGlt cGxlbWVudGVkIFNDRVAgZm9yIGl0J3MgTURNIHNvbHV0aW9uLiBOb3QgaGF2aW5nIGFueSBpbnNp Z2h0IGludG8gQXBwbGUncyBkZWNpc2lvbiBtYWtpbmcgSSBjYW4gb25seSBzdXJtaXNlIHdoeSB0 aGV5IHdvdWxkIGltcGxlbWVudCBhbiBpbmZlcmlvciBjZXJ0aWZpY2F0ZSBlbnJvbGxtZW50IHBy b3RvY29sLCBhbmQgdGhhdCBzdXJtaXNpbmcgaXMgdGhhdCB0aGUgcmVhc29uIHdhcyBub3QgdGVj aG5pY2FsLg0KDQogwqAgU0NFUCBkZXNlcnZlcyBoaXN0b3JpYyBzdGF0dXMgYmVjYXVzZSBhdCB0 aGUgdGltZSBpdCB3YXMgcHJvcG9zZWQgKGEgaGlzdG9yaWMgbW9tZW50IGJhY2sgaW4gdGhlIGxh dGUgMjB0aCBjZW50dXJ5KSBpdCB3YXMgdGhlIGJlc3QgcHJvdG9jb2wgdG8gc29sdmUgdGhlIHBy b2JsZW0sIGFuZCBub3cgaXQncyBub3QuIFN0YW5kYXJkcyBUcmFjayB3b3VsZCBlbmFibGUgU0NF UCB0byBiZSByZWZlcmVuY2VkIGJ5IGZ1dHVyZSBTdGFuZGFyZHMgVHJhY2sgcHJvdG9jb2xzIGFu ZCB0aGF0IHdvdWxkIGJlIHJlYWxseSBiYWQuIEFsbCByZWZlcmVuY2VzIHRvIElFVEYgc3RhbmRh cmRzIGZvciBjZXJ0aWZpY2F0ZSBlbnJvbGxtZW50IHByb3RvY29scyBnb2luZyBmb3J3YXJkIHNo b3VsZCBiZSB0byBFU1QgKFJGQyA3MDMwKS4NCg0KIMKgIERhbi4NCg0KT24gMTIvNi8xNyA3OjQ4 IFBNLCBQZXRlciBHdXRtYW5uIHdyb3RlOg0KPiBBZnRlciAxOCB5ZWFycyBpbiB0aGUgZHJhZnQg c3RhZ2UsIHRoaXMgaXMgZmluYWxseSByZWFkeSBmb3IgDQo+IHB1YmxpY2F0aW9uLiBUaGUgb25l IHN0aWNraW5nIHBvaW50IGlzIGl0cyBzdGF0dXMsIHdoaWNoIEkgdGhpbmsgDQo+IHNob3VsZCBi ZSBTdGFuZGFyZHMgVHJhY2sgYnV0IG90aGVycyB0aGluayBzaG91bGQgYmUgSGlzdG9yaWMuDQo+ DQo+IFRoZSBwcm9ibGVtIHdpdGggSGlzdG9yaWMgaXMgdHdvLWZvbGQsIGZpcnN0bHkgUkZDIDIw MjYgZGVmaW5lcyANCj4gaGlzdG9yaWMgYXMgIkEgc3BlY2lmaWNhdGlvbiB0aGF0IGhhcyBiZWVu IHN1cGVyc2VkZWQgYnkgYSBtb3JlIHJlY2VudCANCj4gc3BlY2lmaWNhdGlvbiBvciBpcyBmb3Ig YW55IG90aGVyIHJlYXNvbiBjb25zaWRlcmVkIHRvIGJlIG9ic29sZXRlIGlzIGFzc2lnbmVkIHRv IHRoZSAiSGlzdG9yaWMiDQo+IGxldmVsIiwgd2hpY2ggaXMgaW4gYm90aCBjYXNlcyB0aGUgZXhh Y3Qgb3Bwb3NpdGUgb2Ygd2hhdCBTQ0VQIGlzLCANCj4gaXQncyBub3Qgc3VwZXJzZWRlZCBhbmQg aXQncyBpbiB3aWRlciBhbmQgbW9yZSBhY3RpdmUgdXNlIHRoYW4gdGhlIA0KPiBtYXJrZWQtYXMt c3RhbmRhcmRzLSB0cmFjayBDTVAgYW5kIENNQy4NCj4NCj4gVGhlIHNlY29uZCBpcyB0aGF0IFND RVAgaXMgaW4gZXh0cmVtZWx5IHdpZGUsIGFuZCBhY3RpdmUgdXNlLCBhbmQgaXMgDQo+IHJlZmVy ZW5jZWQgaW4gbnVtZXJvdXMgb3RoZXIgaW5kdXN0cnkgc3RhbmRhcmRzICh1c3VhbGx5IHdpdGgg YW4gDQo+IGFwb2xvZ2V0aWMgbm90ZSBhYm91dCBoYXZpbmcgdG8gcmVmZXIgdG8gYSBkcmFmdCA6 LSkuICBGb3IgZXhhbXBsZSANCj4gQXBwbGUncyBPVEEgcHJvZmlsZSBjb25maWd1cmF0aW9uIGFu ZCBkZWxpdmVyeSBwcm90b2NvbCBvbmx5IHN1cHBvcnRzIA0KPiBTQ0VQLCBhbmQgaXQgc2VlbXMg dG8gYmUgdGhlIHN0YW5kYXJkIE1ETSBtZWNoYW5pc20gaW4gZW50ZXJwcmlzZSANCj4gZW52aXJv bm1lbnRzLiAgTWljcm9zb2Z0IGhhcyBzdXBwb3J0ZWQgaXQgYXMgc3RhbmRhcmQgc2luY2UgU2Vy dmVyIA0KPiAyMDAzIHZpYSBOREVTIGFuZCB0aGF0J3MgdGhlbiB1c2VkIHRvIHByb3Zpc2lvbiBt b2JpbGUgZGV2aWNlcywgYXMgDQo+IHdlbGwgYXMgcm91dGVycywgZmlyZXdhbGxzLCAuLi4gbm90 IHRvIG1lbnRpb24gaXRzIHVzZSBpbiBTQ0FEQSwgSUNTLCANCj4gZW1iZWRkZWQsIGV0Yy4gIFRo ZXJlIGFyZSAoYXQgbGVhc3QpIGEgYmlsbGlvbisgZGV2aWNlcyBydW5uaW5nIFNDRVAgDQo+IHRv ZGF5LiAgTGlrZSBDLCBpdCdsbCBwcm9iYWJseSBiZSBhcm91bmQgZm9yZXZlciBiZWNhdXNlIHNv IG11Y2ggaW5mcmFzdHJ1Y3R1cmUgZGVwZW5kcyBvbiBpdC4NCj4NCj4gSW4gYWRkaXRpb24gdGhl cmUgYXJlIG5ldyBpbXBsZW1lbnRhdGlvbnMgYXMgcmVjZW50bHkgYXMgdGhlIGxhc3Qgc2l4IA0K PiBtb250aHMsIGFuZCBtb3JlIGV4cGVjdGVkIG92ZXIgdGltZSBzaW5jZSBpdCdzIHByZXR0eSBt dWNoIHRoZSBvbmx5IA0KPiBwcm90b2NvbCB0aGVyZSBpcyBmb3IgYXV0b21hdGVkIGNlcnQgcHJv dmlzaW9uaW5nIG9mIGRldmljZXMsIG9yIGF0IA0KPiBsZWFzdCB0aGUgb25seSBvbmUgdGhhdCdz IHdpZGVseSBkZXBsb3llZCBhbmQgdGhhdCB3b3Jrcy4NCj4NCj4gU28gYm90aCBmcm9tIHRoZSBS RkMgMjAyNiBhbmQgdGhlIHByYWdtYXRpYyBwb2ludCBvZiB2aWV3LCBJIHRoaW5rIA0KPiB0aGlz IHNob3VsZCBiZSBwdWJsaXNoZWQgYXMgc3RhbmRhcmRzLXRyYWNrLiAgSXQncyBkZWZpbml0ZWx5 IG5vdCANCj4gSGlzdG9yaWMgaW4gZWl0aGVyIHNlbnNlLg0KPg0KPiBQZXRlci4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2FhZyBtYWlsaW5n IGxpc3QNCj4gc2FhZ0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NhYWcNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnNhYWcgbWFpbGluZyBsaXN0DQpzYWFnQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhYWcNCg== From nobody Sun Dec 10 21:07:15 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2438126DFB for ; Sun, 10 Dec 2017 21:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4FgW75Gk4mB for ; Sun, 10 Dec 2017 21:07:12 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE9D1200CF for ; Sun, 10 Dec 2017 21:07:11 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id EC48E7A3309 for ; Mon, 11 Dec 2017 05:07:10 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: <007e47dfc6734dc38b489adc1d80b84d@XCH-ALN-010.cisco.com> Date: Mon, 11 Dec 2017 00:07:09 -0500 Content-Transfer-Encoding: quoted-printable Reply-To: saag@ietf.org Message-Id: <0FE9366C-28D8-4544-8655-5C3AAACDC535@dukhovni.org> References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <007e47dfc6734dc38b489adc1d80b84d@XCH-ALN-010.cisco.com> To: saag@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 05:07:14 -0000 > On Dec 10, 2017, at 10:32 PM, Panos Kampanakis (pkampana) = wrote: >=20 > Regardless, indeed SCEP will exist for a very long time, and should be = a historic RFC IMHO it makes little sense to mark something "historic", if, as Peter says, it is not only currently practiced, but one of the most widely practiced protocols in this space, and this is not about to change it seems. If the quantum crypto apocalypse is to be upon us as soon as some speculate it might be, SCEP might be a dominant protocol right up until both RSA and ECC are made obsolete. --=20 Viktor. From nobody Sun Dec 10 23:31:51 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B985127876 for ; Sun, 10 Dec 2017 23:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0ZZBpXca_g8 for ; Sun, 10 Dec 2017 23:31:48 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 2689812785F for ; Sun, 10 Dec 2017 23:31:48 -0800 (PST) Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id A875C10224054; Sun, 10 Dec 2017 23:31:47 -0800 (PST) To: Peter Gutmann , "saag@ietf.org" References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <1512951319125.76833@cs.auckland.ac.nz> From: Dan Harkins Message-ID: Date: Sun, 10 Dec 2017 23:31:45 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1512951319125.76833@cs.auckland.ac.nz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 07:31:49 -0000 On 12/10/17 4:15 PM, Peter Gutmann wrote: > Dan Harkins writes: > > Just a background note for those who aren't aware of this, Dan is one of the > co-authors of EST / RFC 7030, thus presumably the repeated mention of that > specific RFC while completely omitting to mention the various other protocols > like CMP and CMC that do the same thing. I don't have an issue with that, > "everyone should be using my pet protocol" is a perfectly good motivation :-), > but I just wanted to put the comments in perspective.   Damn. Busted. The jig is up. I blame google.   But if we want to impugn the motives of people, then what do we say about someone who removes the authors of a protocol (who indicated Informational or Historic on *their document*, I might add), indicates himself as the new "author" (not editor), and then declares that *his* protocol deserves Standards Track. I don't have an issue with "I want to have more Standard Track RFCs with my name on it", it's a perfectly good motivation :-), but I just wanted to put the comments in perspective. (To quote you, including the smiley face). > However, to avoid turning this into a "my protocol is better than your > protocol" argument, lets set EST aside and use another protocol that does the > same thing, CMP, principally because AFAIK the authors aren't on this list so > it's not a personal issue for anyone. Dan's comments are identical whether > you say "EST" or "CMP" or "CMC" or "Xenroll" or "ACME" or whatever that XML > mechanism for requesting certs is called, if it even has a name. > > So: > i >> Given its limitations, I question why anyone would want to implement SCEP >> when a superior alternative, CMP, exists. > You're mistaking "more complex" for "superior". Like the traditional Unix > utility, SCEP was designed to do one thing, provision a device with a > certificate, and do it well. To the credit of its authors, it does a really > good job at this. Nearly twenty years later, apart from the archaic use of > MD5 and single DES, the same thing that was originally published is what's in > the current draft. You can take any PKCS #7 library (although now it's called > CMS) and roll a SCEP implementation in a couple of hours (it's just signed > encrypted PKCS #7). My implementation, in its basic interoperable form, is a > few pages of code, and from memory it worked the first time I ran it against a > server.   Well since you outed me on EST let me tell you that I was in the group at Cisco 20 years ago that came up with SCEP. This was a few years before -00 of SCEP. I can't claim credit, it was more some of my co-workers (Xiaoyi, principally) that should be credited (likewise I can't really take credit for EST as my co-editors deserve much more credit). But we did it then not as a generic MDM protocol but to get a certificate for a router on a network that trusted more than the Internet. And it worked well enough for that use case. And it worked with with all we knew at the time, which was RSA. SCEP does not work with ECC. That's a significant drawback. Also, EST has a way for the policy preferences of the CA/RA to be expressed to the client before the PKCS#10 is generated. This can be used to say, for instance, "the RSA public key in your CSR MUST be 4096 bits" or "the curve you use when generating your public key MUST be NIST's p384 curve", something not possible with SCEP. EST really is a better protocol and it has nothing to do with "mine" versus "yours".   How long did it take for you to implement EST? I'm sure it was less than SCEP. The "basic implementation" should be very short, /simpleEnroll is really simple after all.   Dan. From nobody Mon Dec 11 08:58:11 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6DB12711D for ; Mon, 11 Dec 2017 08:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 3Yaoq73AW_CZ for ; Mon, 11 Dec 2017 08:58:09 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35AEB1271FD for ; Mon, 11 Dec 2017 08:58:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 98CCB30058E for ; Mon, 11 Dec 2017 11:58:05 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ThBxJbQ58d-B for ; Mon, 11 Dec 2017 11:58:04 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 8A4EC300582 for ; Mon, 11 Dec 2017 11:58:04 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_E922B02E-7FD7-4FA7-94DA-229888D454F7" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 11 Dec 2017 11:58:04 -0500 References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> To: IETF SAAG In-Reply-To: <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> Message-Id: <6B06606F-6B2D-4264-8588-FD9A340D73A3@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 16:58:10 -0000 --Apple-Mail=_E922B02E-7FD7-4FA7-94DA-229888D454F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think that SCEP should be published as historic or informational RFC. = I think that standards track is inappropriate because the IETF was never = given an opportunity to review and improve the specification. If the document does get published as an RFC, we should encourage the = original authors to put their names on it. Russ=20 --Apple-Mail=_E922B02E-7FD7-4FA7-94DA-229888D454F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I think that SCEP should be published as historic or = informational RFC.  I think that standards track is inappropriate = because the IETF was never given an opportunity to review and improve = the specification.

If the document does get published as an RFC, we should = encourage the original authors to put their names on it.

Russ 
= --Apple-Mail=_E922B02E-7FD7-4FA7-94DA-229888D454F7-- From nobody Mon Dec 11 09:05:24 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309471272E1 for ; Mon, 11 Dec 2017 09:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 YQdrsXQfAkqh for ; Mon, 11 Dec 2017 09:05:20 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 D6B2112711B for ; Mon, 11 Dec 2017 09:05:20 -0800 (PST) Received: from [169.254.16.167] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vBBH3gUa045457 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 11 Dec 2017 10:03:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.16.167] From: "Paul Hoffman" To: "IETF SAAG" Date: Mon, 11 Dec 2017 09:05:18 -0800 Message-ID: In-Reply-To: <6B06606F-6B2D-4264-8588-FD9A340D73A3@vigilsec.com> References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6B06606F-6B2D-4264-8588-FD9A340D73A3@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 17:05:22 -0000 We don't get to decide what "informational" or "historic" means for the RFC series: those are defined by a standard, RFC 2026. 4.2.2 Informational An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see section 4.2.3). Specifications that have been prepared outside of the Internet community and are not incorporated into the Internet Standards Process by any of the provisions of section 10 may be published as Informational RFCs, with the permission of the owner and the concurrence of the RFC Editor. . . . 4.2.4 Historic A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. (Purists have suggested that the word should be "Historical"; however, at this point the use of "Historic" is historical.) Note: Standards track specifications normally must not depend on other standards track specifications which are at a lower maturity level or on non standards track specifications other than referenced specifications from other standards bodies. (See Section 7.) --Paul Hoffman From nobody Mon Dec 11 10:46:28 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194911287A0 for ; Mon, 11 Dec 2017 10:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=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 7fNZjL1jVvjh for ; Mon, 11 Dec 2017 10:46:24 -0800 (PST) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 20FB1128768 for ; Mon, 11 Dec 2017 10:46:24 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id D025F3741092 for ; Mon, 11 Dec 2017 18:46:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eibYfMXG5gMB for ; Mon, 11 Dec 2017 13:46:21 -0500 (EST) Received: from Maxs-MBP.hsd1.co.comcast.net (c-71-237-53-128.hsd1.co.comcast.net [71.237.53.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 439AF3740BF6 for ; Mon, 11 Dec 2017 13:46:21 -0500 (EST) To: "saag@ietf.org" References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> <1512952085878.6345@cs.auckland.ac.nz> From: "Dr. Pala" Organization: OpenCA Labs Message-ID: Date: Mon, 11 Dec 2017 11:46:20 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1512952085878.6345@cs.auckland.ac.nz> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060308010504000708090709" Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 18:46:26 -0000 This is a cryptographically signed message in MIME format. --------------ms060308010504000708090709 Content-Type: multipart/alternative; boundary="------------D736B36158C3964FB576C88F" Content-Language: en-US This is a multi-part message in MIME format. --------------D736B36158C3964FB576C88F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Peter, all, I think that in this brief response is the real point here: what do we=20 want to plan for the future ? Since it seems we have many different=20 solutions, is anybody interested in addressing the interoperability=20 issues across ecosystems (isn't it the point of having standards in the=20 first place?) ? Maybe a discussion about the possibility of having a=20 common standard that could replace what we have today and that can be=20 used across ecosystem might be appropriate at this point... ? I personally think that CMP might have "failed" (there are, IMHO, large=20 deployments that use it, so it is not just vaporware...) just because of = its face complexity (i.e., many options) and maybe the lack of open=20 source implementation (I am not sure about this point - does anybody=20 have references to OS implementation of CMC / CMP ?). Would it be time=20 to analyze what went wrong in those RFCs and maybe update them to=20 reflect the options that make sense today (i.e., CMC/CMP v2). Just my 2 cents... Cheers, Max On 12/10/17 5:28 PM, Peter Gutmann wrote: > Dr. Pala writes: > > Dr. Pala writes: > >> Whatever the decision of the AD / WG is regarding this topic (i.e., hi= storic >> vs. standard track), I would suggest that the points listed above shou= ld be >> properly and explicitly addressed in the decision. > If we were to seriously address them then we'd need to make CMC and CMP= , which > have failed in the marketplace, Historic, and SCEP, which has succeeded= , > Standards-track. Then there's ACME, whose principal selling point seem= s to be > that it's what you use to talk to Let's Encrypt, and EST, which is most= ly > Cisco's pet standard [0], neither of which look like they're gaining mu= ch > traction outside of those areas. So you've got two Standards-tracks to= > Historic, two where the jury is still out but given the history of CMC = and CMP > I'm not holding out much hope, and SCEP to Standards-track. > > Somehow I can't see that happening :-). > > Peter. > > [0] Apologies to Cisco folks, I know you guys are really keen on this b= ut it's > hard to work up much enthusiasm for yet another standard that does= pretty > much the same thing as CMC and CMP have already done. --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------D736B36158C3964FB576C88F Content-Type: multipart/related; boundary="------------F82EA5697A7CC0BB152DFCBC" --------------F82EA5697A7CC0BB152DFCBC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Peter, all,

I think that in this brief response is the real point here: what do we want to plan for the future ? Since it seems we have many different solutions, is anybody interested in addressing the interoperability issues across ecosystems (isn't it the point of having standards in the first place?) ? Maybe a discussion about the possibility of having a common standard that could replace what we have today and that can be used across ecosystem might be appropriate at this point... ?

I personally think that CMP might have "failed" (there are, IMHO, large deployments that use it, so it is not just vaporware...) just because of its face complexity (i.e., many options) and maybe the lack of open source implementation (I am not sure about this point - does anybody have references to OS implementation of CMC / CMP ?). Would it be time to analyze what went wrong in those RFCs and maybe update them to reflect the options that make sense today (i.e., CMC/CMP v2).

Just my 2 cents...

Cheers,
Max


On 12/10/17 5:28 PM, Peter Gutmann wrote:
Dr. Pala <director@openca.org> writes:

Dr. Pala <director@openca.org> writes:


Whatever the decision of the AD / WG is regarding =
this topic (i.e., historic
vs. standard track), I would suggest that the points listed above should =
be
properly and explicitly addressed in the decision.

If we were to seriously address them then we'd need to make CMC and CMP, =
which
have failed in the marketplace, Historic, and SCEP, which has succeeded,
Standards-track.  Then there's ACME, whose principal selling point seems =
to be
that it's what you use to talk to Let's Encrypt, and EST, which is mostly=

Cisco's pet standard [0], neither of which look like they're gaining much=

traction outside of those areas.  So you've got two Standards-tracks to
Historic, two where the jury is still out but given the history of CMC an=
d CMP
I'm not holding out much hope, and SCEP to Standards-track.

Somehow I can't see that happening :-).

Peter.

[0] Apologies to Cisco folks, I know you guys are really keen on this but=
 it's
    hard to work up much enthusiasm for yet another standard that does pr=
etty
    much the same thing as CMC and CMP have already done.

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------F82EA5697A7CC0BB152DFCBC Content-Type: image/png; name="iaocmhkdadojfiab.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="iaocmhkdadojfiab.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------F82EA5697A7CC0BB152DFCBC-- --------------D736B36158C3964FB576C88F-- --------------ms060308010504000708090709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyAwggUyMIIEGqADAgECAhEAu2YCW4tRQdGHMc0S/FQsNDANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTcxMjAxMDAw MDAwWhcNMTgxMjAxMjM1OTU5WjAkMSIwIAYJKoZIhvcNAQkBFhNkaXJlY3RvckBvcGVuY2Eu b3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyEDKYfy+DFhtDn8bIXyP25Xe DjUIkMQDm90A1JPoQ4tuTk6kXwulPvAmvtLGuRAzEqFpV/fqz4sAlx8FgxvRZ5PunZ1H1/lJ CNEdir53Xv8TEf+R/n+Ca5RNUR+GhS72zhp9xx8uDRZds2DeXvW9uhYp9nsbX6rWIFT5YfWF 1SukFXwXSnHuXc9nDT6p0Kp6UNzusn/lMhXhIwgpNA26/mHAdScYyMoB4yaZeMpdZN75XGWO slhXcXdeGJo93E48kffdu0yo4WTbpLwhs/IrkG4OXB1N3Bf+9oHZwVun1hlCZEfuSit0mvrx x8wzPCPiggXu6j6VqPoJqecV6xKCHwIDAQABo4IB6TCCAeUwHwYDVR0jBBgwFoAUgq9sjPjF /pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFEPV9allspkmYqkQRx2BlAdbOrjhMA4GA1UdDwEB /wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggr BgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2g S4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3BlbmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEA g+REupW946f7esdYmE1QxsYlkubErxz8JLovVDSKTHwxR1/VxF/B7rGeiSPBHTmKQYwlWCrp eHZNfzaDDkDamwLXm7v4+brNfQKRpOLnYPQQffp7xim72INakLgts8d5I7bic785dj4M5JP4 XA2qUD9wduwNwquua6v7zM3chpoRjapumzLNDDr47GccOKAZYaaqFwbpwJPQYuiC07WWnn7g FzdNKYN6VM6Re6wVEHP6fEvNrleV0pf1iFjLKugnriGKL9wj6xX25JsMmGmqZcfdpnkTE4Zf eQBEZVnn8s7HBX+MA/K+YnHxRwA2c5XwNbEhZ2rvh2uFIMXBDlt+tDCCBeYwggPOoAMCAQIC EGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQ PTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivl JTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG 9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoS WY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQAB o4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKv bIz4xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEA MBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9k b2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcB AQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFk ZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJ KoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo 7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaB Q+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKS TvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+E2pvOUtY +hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnMrwfHM5td hYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9hz9D0S0U4 jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5PDEJ M/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJU mpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTK TlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIEODCCBDQCAQEw ga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01P RE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAu2YC W4tRQdGHMc0S/FQsNDANBglghkgBZQMEAgEFAKCCAlswGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMjExMTg0NjIwWjAvBgkqhkiG9w0BCQQxIgQgWXS1 6+eSzt7Ef4krWngkArWfms0XmXx54GHkKhv04LQwbAYJKoZIhvcNAQkPMV8wXTALBglghkgB ZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGX MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJT QSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALtmAluLUUHR hzHNEvxULDQwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALtmAluLUUHRhzHNEvxULDQwDQYJKoZIhvcNAQEB BQAEggEAd2vhJTU18J6zqgMcz53uGSG8Pqy0wVmih68mkLVM+8Ir4TimrW2NW17+CbIQkcDA zWH3mwla8AVvlytSYP0bh9fPZy0vAqHYF/f4p6+50OpMGz5ta/fDGUKpyylQrLZ/A+BVRVfg if6CnjFH6FV0pisIwbNvawOKgKwTHuTyWsHRFct5mPp6j1eWx049EaXRSqncqiabnDWofqhg AeDGzAiD7qoixyzThZwrf8NcKaTMbsQqM4ejqPMWX/6sZ5knXxCCKaQIcoUdayrC6PWQQXtK RA/Fm0jBAuXAgwxYqHSGxH56rvySGCX9CFGRALMe9vDL1Ao0NgwDu5d7CuIjyAAAAAAAAA== --------------ms060308010504000708090709-- From nobody Mon Dec 11 11:51:57 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C93312726E for ; Mon, 11 Dec 2017 11:51:55 -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, 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 (2048-bit key) header.d=akamai.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 1ZdLOltH8SFK for ; Mon, 11 Dec 2017 11:51:53 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 47AAC124D68 for ; Mon, 11 Dec 2017 11:51:53 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBBJl81Y019145; Mon, 11 Dec 2017 19:51:51 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=mxkEabvX+37CXcLKZx7vBz7Bch+MDZUm2pOHyDqLRPU=; b=D2YRAKM7R9MyvG1YSAshDC1806k0msr1aPCFEWjArXT7Zm9NA3vgjz78BqFYSGzBLa1g e2jKr3Gb4+WUir6u0UU/iMIdcZaEHN/gockF8oQOAS3zWPseljAEK9Whb7y4iqo1fY78 SfPiG3c003mHxSHwyY+tlg8C3YbIeVJ56wFwULpov5hUGWh9tr4LwSOKhg4JaXHZLoQ4 2dlDpookdO3opImJwAYOqfvheJCS/p86FqQqpSHD1t/JuPgSvGnEXMrd54YX+zikrXzd mtiJTQy1Tn0VzCApssbWIiFsuOvCh+UvWCyYBtfw+rLLO4EyggbuxRXB1jIWA69VnysR Yw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2er8rk6q3v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Dec 2017 19:51:50 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vBBJoiRc019977; Mon, 11 Dec 2017 14:51:49 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2erc20rv39-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 11 Dec 2017 14:51:49 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 11 Dec 2017 14:51:48 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 11 Dec 2017 14:51:48 -0500 From: "Salz, Rich" To: "Dr. Pala" , "saag@ietf.org" Thread-Topic: [saag] Status of the SCEP RFC draft Thread-Index: AQHTbw4UUnneaIh1UU6hdrWtX9hT6aM7Be4AgABMNgCAAEU9gIAAA2KAgAGSLoCAAHangIABMsgAgAASSwA= Date: Mon, 11 Dec 2017 19:51:48 +0000 Message-ID: <6399716C-BD6C-49A0-A346-9AC431241B51@akamai.com> References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> <1512952085878.6345@cs.auckland.ac.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.47.49] Content-Type: multipart/alternative; boundary="_000_6399716CBD6C49A0A3469AC431241B51akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-11_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=494 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712110283 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-11_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=439 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712110282 Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 19:51:55 -0000 --_000_6399716CBD6C49A0A3469AC431241B51akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgaGF2ZSBkb2N1bWVudGVkIG1hbnkgb3RoZXIgcHJvdG9jb2xzIGJlY2F1c2UgaXQgd2FzIHdv cnRoIGhhdmluZyB0aGVtIGFzIFJGQ+KAmXMuICBTaW1vbiBKb3NlZnNzb24gaGFzIGFsbW9zdCBt YWRlIGEg4oCcY290dGFnZSBpbmR1c3RyeeKAnSBvdXQgb2YgaXQuDQoNCkJ1dCBJIGRpZG7igJl0 IGtub3cgdGhhdCB0aGUgSUVURiBkaWRu4oCZdCBoYXZlIGEgY2hhbmNlIHRvIHdvcmsgb24gU0NF UC4NCg0KSSBhbSBpbiBmYXZvciBvZiBhbiBpbmZvcm1hdGlvbmFsIFJGQy4NCg0K --_000_6399716CBD6C49A0A3469AC431241B51akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb3VyaWVyO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xv cjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2Nv bG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGhhdmUgZG9j dW1lbnRlZCBtYW55IG90aGVyIHByb3RvY29scyBiZWNhdXNlIGl0IHdhcyB3b3J0aCBoYXZpbmcg dGhlbSBhcyBSRkPigJlzLiZuYnNwOyBTaW1vbiBKb3NlZnNzb24gaGFzIGFsbW9zdCBtYWRlIGEg 4oCcY290dGFnZSBpbmR1c3RyeeKAnSBvdXQgb2YgaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkJ1dCBJIGRpZG7igJl0IGtub3cgdGhhdCB0aGUgSUVURiBkaWRu4oCZdCBoYXZlIGEgY2hhbmNl IHRvIHdvcmsgb24gU0NFUC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBpbiBmYXZvciBv ZiBhbiBpbmZvcm1hdGlvbmFsIFJGQy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tdG9wOjcuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6399716CBD6C49A0A3469AC431241B51akamaicom_-- From nobody Mon Dec 11 13:04:32 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCB91289C3 for ; Mon, 11 Dec 2017 13:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.501 X-Spam-Level: X-Spam-Status: No, score=-5.501 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_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 PsMLzQKlrkyi for ; Mon, 11 Dec 2017 13:04:28 -0800 (PST) Received: from st13p27im-asmtp004.me.com (st13p27im-asmtp004.me.com [17.162.190.113]) (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 E8F21128ACA for ; Mon, 11 Dec 2017 13:04:26 -0800 (PST) Received: from process-dkim-sign-daemon.st13p27im-asmtp004.me.com by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P0T00200EHGQR00@st13p27im-asmtp004.me.com> for saag@ietf.org; Mon, 11 Dec 2017 21:04:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1513026266; bh=il0jDG/JrUWDaucNz6yFJjFKRPE3yixQuXGPuBWBogY=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=eeIIv1w8qr3w/2iEuHML622jJjG1mq08CzsYvb1z5k2OqOxZe8V64Va3QXOdIDBfX RkZJbgHhQ/J6KXMGvYxTv7f7iGj3OA4wn3uYF9aVsYkKQYj4qQOIusWDJo4ZiTZAh7 1baAcnluEJrv9t49zuQUmjdYLuxQkfY3l5vLbYxoW3F/LppjR2V9qA5v0qbxktLKuy HygIveRtWr0YMb+oc7zcf5iZUVkUEkB4b+pLZz0/UHxwuhVE/RYr3DRXwKnGx/yRQu I/qdJjoEMQ6+0gE74Xn+R/vFK0OaUB1Q3WF86MPKJ2CTr5kkx2SY15AfsLfmu77Zoc thKqjEmC0iXUg== Received: from icloud.com ([127.0.0.1]) by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P0T00Z01EJCNJ10@st13p27im-asmtp004.me.com> for saag@ietf.org; Mon, 11 Dec 2017 21:04:26 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-11_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1712110300 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Jon Callas In-reply-to: <6399716C-BD6C-49A0-A346-9AC431241B51@akamai.com> Date: Mon, 11 Dec 2017 13:04:23 -0800 Content-transfer-encoding: quoted-printable Message-id: <840AAD22-8A8A-4482-AEF6-B695B5B2E8A7@icloud.com> References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> <1512952085878.6345@cs.auckland.ac.nz> <6399716C-BD6C-49A0-A346-9AC431241B51@akamai.com> To: "saag@ietf.org" X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 21:04:31 -0000 I want to comment on an aspect of the conversation that is not about = SCEP per se, but the larger issue of what standards are and do. There's = been discussion about what's a better standard, or what people should be = doing as far as this standard or that one. That's the place where I want = to make the comment. I believe that the purpose of a standard, and thus a standards body is = to promote interoperability. I came to this belief as part of = participation in the IETF, and it is an opinion that I got from senior = people in the IETF over the years. This opinion is analogous to a descriptivist view of what dictionaries = do. I think it's an apt analogy; a standard tells you how to interpret a = message as well as how to construct a message for others to interpret. = That's really what the protocol is. It might very well be that there are other protocols that do similar = things, and it might even be true that the other protocols are better. = Even if it is true, it's also irrelevant in many cases.=20 I think that if there's a community of interest for a protocol, then a = standards body ought to support that standard. My reason is simple =E2=80=94= if that body doesn't support it, then some other body will, or worse = the protocol will be documented in some other way. In either event, I = think this hurts the reputation of the standards body. If the standards = body doesn't support the standard, they'll receive criticism that = they're "not in touch with reality" or "political" or both, or other = slurs. In many, most, or perhaps all of these cases, that criticism is = even well-founded. Not supporting a protocol that has a community of = interest is pretty much "not in touch with reality" even if it's a small = community and thus a small reality. And not supporting one because = there's a "better" one is precisely being political; it's a = prescriptivist view of what I think should be a descriptivist task. In language, while I'm a descriptivist when it comes to dictionaries, I = firmly believe in style guides and stronger documents. I think that = dictionaries should describe, and that description can (should?) = (SHOULD?) also describe a controversy. If there's a competing protocol that is better, then that conversation = should happen outside the standard. I'm happy to hear why I should use = protocol FOO over protocol BAR, but if I need to implement BAR then any = discussion of FOO is at best informational. If I need to talk to some = service that speaks BAR, it might be better if it spoke FOO, but it = doesn't. Similarly, a protocol being historic is something of an editorial = decision, and I think that if there's any sort of controversy, then it's = not really historic. If the answer to, "Do you think that BAR ought to = be declared historic?" is "what's protocol BAR again?" then the answer = is probably yes, it can be made historic. If it's actively being used in = any sort of community of interest, then it's not. Even (or especially) = if it hasn't been changed, it's not historic if people are using it. To sum up and apply my observations, yes, I think SCEP ought to be = standards-track, and not historic. Jon= From nobody Mon Dec 11 14:32:13 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D638124234 for ; Mon, 11 Dec 2017 14:32:11 -0800 (PST) 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 (2048-bit key) header.d=akamai.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 Srm3vGm7O9GV for ; Mon, 11 Dec 2017 14:32:09 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 BD7591200F1 for ; Mon, 11 Dec 2017 14:32:09 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBBMVZNU024690; Mon, 11 Dec 2017 22:32:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=gT3IRPipYk2LeN5SpRsJQ82gFD+6lb1KdVMG/n4ch3Q=; b=Vs/j3mupYFJoutXMYEMAjt+nqLd/Mpn/tnDYyYbJn0DiXIdsJ68SF0NUmXfibz+5XMY6 O2K0c4Wincuyc5h9LW0UeIJ9XJxNfxo19RFNs2myG6iezAbt+LDZa04tBKI6Nq26NY9i FzMTScf0beOjH9W6PAQ/kNruNRSdYRj2inIn2yR6L9xiyjecWQTtYEGMeUsZEWUZy2Ua xaJ0MBQ2NAv1fN/Mt+x52JNfiIi7L5XXJJhAgZHV/mhwNqjXvD3TkiSbn41F5hTYCUwH /6bCLxSHIioWsx+Xnt9XYiHZwrfWWeoez3b1lWpwS6SGd3RjQ3Zr/1MesG7q5VV0oOuu MQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2er885yghd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Dec 2017 22:32:07 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vBBMVBs6017663; Mon, 11 Dec 2017 17:32:06 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2erc1xscj3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 11 Dec 2017 17:32:06 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 11 Dec 2017 17:32:05 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 11 Dec 2017 17:32:05 -0500 From: "Salz, Rich" To: Jon Callas , "saag@ietf.org" Thread-Topic: [saag] Status of the SCEP RFC draft Thread-Index: AQHTbw4UUnneaIh1UU6hdrWtX9hT6aM7Be4AgABMNgCAAEU9gIAAA2KAgAGSLoCAAHangIABMsgAgAASSwCAABRHgIAAGIAA Date: Mon, 11 Dec 2017 22:32:05 +0000 Message-ID: <91B7C40D-1801-4899-B4E9-09976D2C029D@akamai.com> References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> <1512952085878.6345@cs.auckland.ac.nz> <6399716C-BD6C-49A0-A346-9AC431241B51@akamai.com> <840AAD22-8A8A-4482-AEF6-B695B5B2E8A7@icloud.com> In-Reply-To: <840AAD22-8A8A-4482-AEF6-B695B5B2E8A7@icloud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.4] Content-Type: text/plain; charset="utf-8" Content-ID: <83C6370E301C5B458B8C4275D7DCF0C8@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-11_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=711 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712110321 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-11_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=644 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712110321 Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 22:32:12 -0000 PiAgICAgVG8gc3VtIHVwIGFuZCBhcHBseSBteSBvYnNlcnZhdGlvbnMsIHllcywgSSB0aGluayBT Q0VQIG91Z2h0IHRvIGJlIHN0YW5kYXJkcy10cmFjaywgYW5kIG5vdCBoaXN0b3JpYy4NCiAgIA0K QnV0IGlmIFJ1c3MgaXMgY29ycmVjdCwgdGhlbiBJbmZvcm1hdGlvbmFsIOKAkyBkb2N1bWVudGlu ZyBzb21ldGhpbmcgZG9uZSBvdXRzaWRlIG9mIHRoZSBJRVRGIOKAkyBpcyBtb3JlIGFjY3VyYXRl LiAgRG8geW91IGRpc2FncmVlPw0KDQo= From nobody Mon Dec 11 17:50:54 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8B91270B4 for ; Mon, 11 Dec 2017 17:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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=sn3rd.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 t8_5dH71gdaL for ; Mon, 11 Dec 2017 17:50:51 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 6E30A126D05 for ; Mon, 11 Dec 2017 17:50:51 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id i40so43667311qti.8 for ; Mon, 11 Dec 2017 17:50:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=CwtoB3MtohMjROBX4dfOxajMzewLqgc7Bku+RTG5yDk=; b=bYiXFp9ASTcBei2SHgheeakgd7PWneb7H/SZDl7haw87YtHDD9JfonAQb5nPVRRmGL M68v9oLqKvkyfZxKJDLxUQFBkzA5vbOH+XF20l+YDgKKStQLuS2H5jZugLA0SgPlZr2l 0uxBtwnHbR+UkzSe9mG59eS1BO3DZK3pujMgQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=CwtoB3MtohMjROBX4dfOxajMzewLqgc7Bku+RTG5yDk=; b=M9a5VUvlJQitlKGhGaeaXmTBua81QRV9jpYaL5nsHPurfEH/kdVPKs8RWPlMIJhqHU MDskcq25tGr4Kaz87AGFm69K+9sbVdEqUjnHgNv99wR7nHYlVazGOaKxDLENbkg4Bnl+ n1uDSYypEHD3wQGdZCbWo6cYfwpazfP/hSMxOF5H3crK1jN/yKxBFkX6pxzQiaLiRc6p 7IHBZLN4Kl76rMdTK+We+dKaZpMJjh9LcjrA6bS6mIG1VftFp/7oprKR2cQXk17+rdDS MvyK1+GlmtW/uVqCbNToNlfPkiO1i8H8xWXjWT3kwO7tDU1FpBH2Vhe5QuKZZ/JEeTYg 8heQ== X-Gm-Message-State: AKGB3mLoTotPZxM5wVpbOKTSVfyB5drNxO0sYcyBOGPwiJXsiqc2PXOH Mzn9GGX11LvyuPaWXjBosn/X3mSIPUU= X-Google-Smtp-Source: ACJfBouCghdk1oxpLqaDkGFCdHigmNdUArehvd+SVZLr7HKEEULCzXnsaQ37yjLZa8LeeHn09gUGyA== X-Received: by 10.55.109.194 with SMTP id i185mr3443676qkc.73.1513043450106; Mon, 11 Dec 2017 17:50:50 -0800 (PST) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id a17sm5584075qkj.6.2017.12.11.17.50.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Dec 2017 17:50:49 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 11 Dec 2017 20:50:48 -0500 References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> <1512952085878.6345@cs.auckland.ac.nz> <6399716C-BD6C-49A0-A346-9AC431241B51@akamai.com> <840AAD22-8A8A-4482-AEF6-B695B5B2E8A7@icloud.com> <91B7C40D-1801-4899-B4E9-09976D2C029D@akamai.com> To: "saag@ietf.org" In-Reply-To: <91B7C40D-1801-4899-B4E9-09976D2C029D@akamai.com> Message-Id: <30C85592-D5CE-4A32-A6A1-CA22AEEB86A2@sn3rd.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 01:50:54 -0000 As somebody who thought they=E2=80=99d brokering a deal to get SCEP = published something like 7 years ago, I=E2=80=99m glad we=E2=80=99re = finally here/there. =20 1. Historic vs Informational vs Standard track Back when the deal got brokered to get it published the deal was for = informational, but it switched somewhere along the way to historic. I = think historic was based on the fact that the specification was = considered to be obsolete because of all the *other* IETF standards = track enrollment protocols available (so many flowers blooming!). The = thing though is that the specification, at least, has had quite a number = of changes since then [0]. We were able to control ourselves and not = make changes to SSL3 so it could go as historic [1], but not so much = with this specification. I can see that some folks might think the = Historic designation might be crazy, but I could live with it or = informational. Note that I believe all of RSA's PKCS specifications published through = the IETF stream were informational. 2. Change control And that brings up another point that I think needs to be made clear. = Often, RSA has explicitly granted change control to the IETF. Because = SCEP started out as "Cisco Systems' Simple Certificate Enrollment = Protocol=E2=80=9D and was that way up until draft-nourse-scep-22 is = Cisco doing the same here? And, I gotta chuckle that the top hit @ Cisco for SCEP points to a = draft-nourse [2] ;) 3. Pre-5378 bolier plate I gotta ask about the dropped pre-5378 boiler plate. Was approval = obtained from each of the previous authors: Xiaoyi Liu, Cheryl Madson, = David McGrew, Andrew Nourse, Jan Vilhuber, and Max Pritikin? It=E2=80=99s= annoying process mumbo-jumbo but because I couldn=E2=80=99t get an = answer from everybody the pre-5378 boiler plate had to be included in = the SSL RFC: https://datatracker.ietf.org/doc/rfc6101/. spt [0] = https://www.ietf.org/rfcdiff?url1=3Ddraft-nourse-scep-23&url2=3Ddraft-gutm= ann-scep-07 [1] https://datatracker.ietf.org/doc/rfc6101/ [2] = https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrast= ructure-pki/116167-technote-scep-00.html?dtid=3Dosscdc000283 > On Dec 11, 2017, at 17:32, Salz, Rich wrote: >=20 >> To sum up and apply my observations, yes, I think SCEP ought to be = standards-track, and not historic. >=20 > But if Russ is correct, then Informational =E2=80=93 documenting = something done outside of the IETF =E2=80=93 is more accurate. Do you = disagree? >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Mon Dec 11 18:48:58 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98E21270A0 for ; Mon, 11 Dec 2017 18:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 qIKjbINktxne for ; Mon, 11 Dec 2017 18:48:54 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 ED65A126D05 for ; Mon, 11 Dec 2017 18:48:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1513046933; x=1544582933; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=lbszsSjKBJA2B64N9OMZNbdRj7BEgvTaBMXF8SceSYg=; b=rcFU/bV8c7UDQcw1oPOflIJDk23WFzQFVA9rz9A8WQSPmwPx3rJp6OUD x09YwJEt32TLHEZyib42xtZs03i+OR3fomjdQFBOuEHiLDMaH/ZViZ/7V yy1LqMB9ipG/bAdWGoEHeLtwz2e9WpNlvdH/dfOolVy/CvNt7zighWTcM shiV2TfehRjRKRuH9Fxx1sAxUEo7V0qjPRk2CkedZ4rbU7f9NFVfE/LCA zQhDoZuCaNBeq/3mg7l8Nx0qpeL9War/8ZrfntzcfRVjlAUPlLvWyLr5L c/olcniwGqc9pFHfQEmEqwc3KIYgJ0A/DXrl3Vp19IkBnHjK5mAIFCe0P Q==; X-IronPort-AV: E=Sophos;i="5.45,393,1508756400"; d="scan'208";a="203019112" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from uxcn13-tdc-d.uoa.auckland.ac.nz ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 12 Dec 2017 15:48:47 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 12 Dec 2017 15:48:46 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Tue, 12 Dec 2017 15:48:46 +1300 From: Peter Gutmann To: "Dr. Pala" , "saag@ietf.org" Thread-Topic: Certificate provisioning protocols Thread-Index: AQHTcvM6BGtTEFgPeUqcXwszdQJWyA== Date: Tue, 12 Dec 2017 02:48:46 +0000 Message-ID: <1513046926828.69595@cs.auckland.ac.nz> References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> <1512952085878.6345@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [saag] Certificate provisioning protocols X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 02:48:57 -0000 [Subject changed to more accurately reflect the discussion]=0A= =0A= Dr. Pala writes:=0A= =0A= >I personally think that CMP might have "failed" (there are, IMHO, large = =0A= >deployments that use it, so it is not just vaporware...) just because of = =0A= >its face complexity (i.e., many options) and maybe the lack of open source= =0A= >implementation (I am not sure about this point - does anybody have =0A= >references to OS implementation of CMC / CMP ?). Would it be time to =0A= >analyze what went wrong in those RFCs and maybe update them to reflect the= =0A= >options that make sense today (i.e., CMC/CMP v2).=0A= =0A= Somehow I don't think that'll work. The problem with the more complex/=0A= heavyweight protocols is that they were designed to be all things to all = =0A= people, when in most cases the marketplace just wanted a way to get a =0A= certificate onto a device. So the question "can we redesign X to make it = =0A= easier to work with" assumes that people want X in the first place =0A= (consider the equivalent "can we redesign X.400 to make it easier to work = =0A= with?"). If all you want to do is get a cert onto a device, SCEP is hard t= o =0A= beat. Sure, everyone can think of things to tack onto it and come up with = =0A= missing bells and whistles, but you can't really strip anything out without= =0A= breaking the security guarantees, and if you add more bits to it you could = =0A= just be adding unwanted bloat.=0A= =0A= There is an open-source CMP implementation, and has been for years. The = =0A= typical experience with it (and this is a paraphrasing of a number of =0A= conversations) goes something like this:=0A= =0A= User: We're using SCEP.=0A= Me: Why not switch to CMP, it's a one-line code change?=0A= User: Why would we want to switch to CMP?=0A= Me: (Sales pitch for all the things CMP does).=0A= User: Yeah... on further consideration we've decided to stay with SCEP, but= =0A= thanks for the offer.=0A= =0A= If your goal is to provision a device with a certificate, you can't get any= =0A= simpler than:=0A= =0A= sign( encrypt( gimme a cert ) )=0A= =0A= which is exactly what SCEP is. I'm not saying it's the perfect protocol, = =0A= but it's the simplest, most straightforward way to implement "gimme a cert"= =0A= (particularly when compared to CMC, CMP, ACME, EST, and XML). It's also th= e =0A= one that's easiest to deploy, when I was doing my implementation the =0A= deployment consisted of "can you open a port to the Windows server" (which = =0A= has a full-featured GUI interface to a SCEP CA server with everything you = =0A= need) [0]. If you want to play with a client, there's JSCEP.=0A= =0A= With the others, I wouldn't even know where to start. EST has a reference= =0A= implementation (concidentally by Dan Harkins, see the earlier exchange) tha= t =0A= was last touched four years ago and has a single contributor, zero pull =0A= requests, zero comments, and a single commit after the initial one =0A= (https://github.com/danharkins/est), and for CMC and CMP there's nothing = =0A= (interop'ing against my own code doesn't really count) [1]. So even if you= =0A= really wanted to deploy protocol X, there's not much to go with, or if ther= e =0A= is it's reasonably well hidden.=0A= =0A= To wind up this rather rambly post, it's not a question of deciding which = =0A= protocol to fix and what needs fixing, it's figuring out what users want an= d =0A= what the most efficient way is to get it to them. Whether by accident or b= y=0A= design, SCEP seems to have managed that, presumably because it was designed= =0A= bottom-up, "here's a problem, how do we solve it", rather than top-down,=0A= "let's put everything we can think of into a protocol and see if users want= =0A= it".=0A= =0A= Peter.=0A= =0A= [0] This is a slight fib, the first server I talked to was a PLC monitor = =0A= running a SCEP server, but the first server that'd be recognisable as = =0A= such would be Windows Server.=0A= [1] There are a few bits of abandonware that need to be linked to ten-year-= =0A= old copies of libfoo around, but I'm not counting those.=0A= =0A= =0A= From nobody Mon Dec 11 19:14:20 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB0112922E for ; Mon, 11 Dec 2017 19:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 xjeFH8_036QY for ; Mon, 11 Dec 2017 19:14:17 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 7056D128DF3 for ; Mon, 11 Dec 2017 19:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1513048457; x=1544584457; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=rCuIJSfM/fCTti4I/aFhCJTMVTJbhRgp55oKPx0iU+Q=; b=RViERV3SgDVvxV7S/wzFbFDaN+LYDzH2Hlpl2LZ/RuHELMPyiPAkO4l1 fjedtNkkI7qD3gCxG0u3b99xFBJvlZtngrF+IzfBCkzdEaBaQcE0qyCNs ANzdQ9idGBMUoIT52bm4gvq1p31w7doEc30Bj1PDjPw4sxu5B5bSqCBZs 4WA8NiQjMYJTIBPU2RHhb6nQwrXhhU6EBZzEvLyoI0RTE+1DKmKGgp9Pb mCMswrLpNFl8ST+EXk8PDQV8BXy8Lgulb3gpowYWkgRaWPHkKZIqUXCPB gUqtqiDTU5hQ3MH9ybskpGNp0YsaixWtC5ULBAsdAX/Pw4jMdZ//2KmDy g==; X-IronPort-AV: E=Sophos;i="5.45,393,1508756400"; d="scan'208";a="203023854" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 12 Dec 2017 16:14:15 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.22) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 12 Dec 2017 16:14:15 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Tue, 12 Dec 2017 16:14:15 +1300 From: Peter Gutmann To: Dan Harkins , "saag@ietf.org" Thread-Topic: [saag] Status of the SCEP RFC draft Thread-Index: AQHTbw4UUnneaIh1UU6hdrWtX9hT6aM52C8AgANx0fP//6IngIACItjd Date: Tue, 12 Dec 2017 03:14:14 +0000 Message-ID: <1513048454590.36550@cs.auckland.ac.nz> References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <1512951319125.76833@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 03:14:19 -0000 [Most people will probably just want to skip to the last paragraph].=0A= =0A= Dan Harkins writes:=0A= =0A= >But if we want to impugn the motives of people, then what do we say about= =0A= >someone who removes the authors of a protocol =0A= =0A= As I've already explained previously, I removed the names of the authors fr= om=0A= the masthead at their request. If you look at the -00 draft it has all the= =0A= original names. As it progressed, the various people involved contacted me= =0A= and requested that, for various reasons, their names be removed. They're a= ll =0A= still listed in the acknowledgements.=0A= =0A= Just to repeat this a third time in case it's still not clear:=0A= =0A= I removed the names of the original authors from the masthead AT THE =0A= EXPLICIT WRITTEN REQUEST OF THE PEOPLE INVOLVED.=0A= =0A= I'd have preferred to keep them there, but they gave valid reasons for=0A= not having their names listed, and I honoured those requests.=0A= =0A= >indicates himself as the new "author" (not editor), =0A= =0A= Are we reading the same document? The one I've just got from the IETF says= :=0A= =0A= The editor would like to thank all of the previous editors, authors=0A= and contributors: Cheryl Madson, Xiaoyi Liu, David McGrew, David=0A= Cooper, Andy Nourse, Max Pritikin, Jan Vilhuber, and others for their=0A= work maintaining the draft over the years. Numerous other people=0A= have contributed during the long life cycle of the draft and all=0A= deserve thanks. =0A= =0A= >and then declares that *his* protocol deserves Standards Track.=0A= =0A= I'm not sure how "Status of the SCEP RFC draft" (look up a bit at subject = =0A= line of this email) has become "my protocol".=0A= =0A= That's zero for three so far. What else?=0A= =0A= >How long did it take for you to implement EST? I'm sure it was less than = =0A= >SCEP.=0A= =0A= Uhh, are we talking about the same thing here? SCEP is a PKCS #10 inside= =0A= a PKCS #7. EST takes all the complexity of CMC, which is already vastly=0A= more complex than SCEP, then adds more complexity of its own (why? CMC=0A= already has more than enough stuff in it), and finally throws in HTTP and = =0A= TLS as well for no reason I can understand since CMC already has its own = =0A= security mechanisms. So you're expecting that =0A= =0A= SCEP > CMC + EST extras + HTTP + TLS?=0A= =0A= While this has been fun ("you do walk into these things, don't you =0A= Baldrick?"), I really, really don't want to continue such a pointless debat= e =0A= (given the number of incorrect claims in the message I'm replying to, I fel= t =0A= I had to respond at least to that).=0A= =0A= As Paul Hoffman has pointed out, RFC 2026 probably makes it Informational. = =0A= I'd prefer Standards-track because it causes less problems with downrefs = =0A= from other industry standards, but I can live with Informational if that's = =0A= what the docs say it should be.=0A= =0A= Peter.= From nobody Mon Dec 11 19:43:15 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9157A1293E3 for ; Mon, 11 Dec 2017 19:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 WHdKY16iUepL for ; Mon, 11 Dec 2017 19:43:11 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 348D31293DB for ; Mon, 11 Dec 2017 19:43:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1513050191; x=1544586191; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=M0c+aJBRwzYd1Pca/2ys+3Ha8TVicgSaDvkE1FUc1pQ=; b=j3jLvE8gz2rjKxC5xsci3ZCJ/o1ZufssEf1ffJU7GbiYnmgKBuikKuKv wM9WiWHqMLy0AK/06L7EQf6rAUmigllMsDLia73OT2XVkcnS8DGH68CvO QcumYKp2ldguzSyfHNVgRUMQFRVMeYSH4su6VNwno3oQ9edsaynIZAtaf 7v8Qpg9joK64I5wrWPGq8zaGEM/qY83weV+EcQ2AGBnfwDtjvJd+df/WX Pv6N9uZU/CsJsez8tE8vqrbn5+1KA2vUw+gMTc+Sbul+9qZk1WIc4f7Rj ovtALHoq3xcdAh5BlZzdHVXHD6fRY5VyENNBiPZTHriInCGzHHAwhQp9C w==; X-IronPort-AV: E=Sophos;i="5.45,393,1508756400"; d="scan'208";a="203029298" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from uxcn13-ogg-d.uoa.auckland.ac.nz ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 12 Dec 2017 16:43:08 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 12 Dec 2017 16:43:08 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Tue, 12 Dec 2017 16:43:08 +1300 From: Peter Gutmann To: Sean Turner , "saag@ietf.org" Thread-Topic: [saag] Status of the SCEP RFC draft Thread-Index: AQHTbw4UUnneaIh1UU6hdrWtX9hT6aM52C8AgABMNQCAAEU+gIAAA2GAgAGSL4CAAU7l1YAAWooAgAASSgCAABRIgIAAGIGAgAA3hQCAAPfrwQ== Date: Tue, 12 Dec 2017 03:43:07 +0000 Message-ID: <1513050187576.97593@cs.auckland.ac.nz> References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> <1512952085878.6345@cs.auckland.ac.nz> <6399716C-BD6C-49A0-A346-9AC431241B51@akamai.com> <840AAD22-8A8A-4482-AEF6-B695B5B2E8A7@icloud.com> <91B7C40D-1801-4899-B4E9-09976D2C029D@akamai.com>, <30C85592-D5CE-4A32-A6A1-CA22AEEB86A2@sn3rd.com> In-Reply-To: <30C85592-D5CE-4A32-A6A1-CA22AEEB86A2@sn3rd.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 03:43:14 -0000 Sean Turner writes:=0A= =0A= >The thing though is that the specification, at least, has had quite a =0A= >number of changes since then=0A= =0A= The bits-on-the-wire is still identical, the reason so much of the text has= =0A= changed is because the document grew by accretion and the rewrite was an=0A= attempt to... well, as the appendix says:=0A= =0A= This specification has spent more than seventeen years in the draft=0A= stage. [...] To fit this role, extra features were bolted on in a=0A= haphazard manner through the addition of a growing list of appendices=0A= and by inserting additional, often conflicting, paragraphs in various=0A= locations in the body text. Since existing features were never=0A= updated as newer ones were added, the specification accumulated large=0A= amounts of historical baggage over time. =0A= =0A= [More text that basically says "this update cleans things up"]=0A= =0A= So it's the same on-the-wire protocol, just with the text describing it =0A= cleaned up.=0A= =0A= >Note that I believe all of RSA's PKCS specifications published through the= =0A= >IETF stream were informational.=0A= =0A= Ah, fair enough. As I mentioned previously, I can live with Informational= =0A= if that's what the rules say.=0A= =0A= >And that brings up another point that I think needs to be made clear. =0A= >Often, RSA has explicitly granted change control to the IETF. Because SCE= P =0A= >started out as "Cisco Systems' Simple Certificate Enrollment Protocol=94 a= nd =0A= >was that way up until draft-nourse-scep-22 is Cisco doing the same here?= =0A= =0A= When I revived the draft, I posted messages to everywhere I could think of= =0A= that had SCEP people (the old SCEP mailing list, the JSCEP list, and there= =0A= was something done at an IETF) and asked if anyone had any objections if I = =0A= continued with the work. It was pretty informal.=0A= =0A= (There was discussion about it with the original authors who could still be= =0A= contacted, but it was all in private email, if any of the original authors= =0A= want to speak out publicly, feel free).=0A= =0A= >I gotta ask about the dropped pre-5378 boiler plate. Was approval obtaine= d =0A= >from each of the previous authors: Xiaoyi Liu, Cheryl Madson, David McGrew= , =0A= >Andrew Nourse, Jan Vilhuber, and Max Pritikin? It=92s annoying process = =0A= >mumbo-jumbo but because I couldn=92t get an answer from everybody the pre-= 5378 =0A= >boiler plate had to be included in the SSL RFC: =0A= >https://datatracker.ietf.org/doc/rfc6101/.=0A= =0A= Some of the authors can't be contacted any more (some of the removal reques= ts =0A= I mentioned in a previous message were things like "X left the company Y = =0A= years ago, please remove their name"), so in general, "no". However given = =0A= that 5378 dates from the time of draft-nourse-scep-xx, wouldn't it already = =0A= fall under 5378?=0A= =0A= Just as an FYI, there wasn't any explicit move from boilerplate-X to =0A= boilerplate-Y, the draft just contains whatever xml2rfc puts in there by=0A= default. I really don't mind what boilerplate it comes with, as long as = =0A= it's not too much of a headache to deal with via xml2rfc, which from memory= =0A= dings you for the use of outdated boilerplate.=0A= =0A= Peter.= From nobody Mon Dec 11 23:49:48 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A18812940E for ; Mon, 11 Dec 2017 23:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 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_H2=-2.8, 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=icloud.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 VzAV3pAibK5S for ; Mon, 11 Dec 2017 23:49:45 -0800 (PST) Received: from st13p27im-asmtp004.me.com (st13p27im-asmtp004.me.com [17.162.190.113]) (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 4F19B12940C for ; Mon, 11 Dec 2017 23:49:45 -0800 (PST) Received: from process-dkim-sign-daemon.st13p27im-asmtp004.me.com by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P0U01200864T000@st13p27im-asmtp004.me.com> for saag@ietf.org; Tue, 12 Dec 2017 07:49:43 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1513064983; bh=QX58dz2eaT85DgDvUENaojyVoLNWYeJkryP4x+gC50c=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=CiQdNDqH8OmMPq2F440z97H1OyAqypnn4FA8fe81FqTSd6HtEQ5lrnkII8japkgCf nvp8WsmYC8Gm4lHg2dpvqp0vJ3Si7i097PtgyHXgwPUB9xT4voTH8FVAPGdAyq1ns9 +KKiRroH1u+LzKnN8T7pMdakjX7ER1DYTIGDh/oGEKmsJdQKZxLHENNijOQYRVIQ3L fyDi1pcV+esrxORKwCBFWsE6T5aKn2NQ1mI02YD93i2Hh/KYkbYE2j6QLWgGVWyfUU aH8gJ7284jdLdHzwY2n3r93gbxYdq+LbZzkQQgfzwCenJgdfB6aOrH5n918mTwYI2h sJadwJ1VUwsZQ== Received: from icloud.com ([127.0.0.1]) by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P0U00RLD8ESQH30@st13p27im-asmtp004.me.com>; Tue, 12 Dec 2017 07:49:42 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-12_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1712120117 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Jon Callas In-reply-to: <91B7C40D-1801-4899-B4E9-09976D2C029D@akamai.com> Date: Mon, 11 Dec 2017 23:49:39 -0800 Cc: Jon Callas , "saag@ietf.org" Content-transfer-encoding: quoted-printable Message-id: <5ADD71EF-5C63-4A2A-BF72-3812ACD6102C@icloud.com> References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> <1512952085878.6345@cs.auckland.ac.nz> <6399716C-BD6C-49A0-A346-9AC431241B51@akamai.com> <840AAD22-8A8A-4482-AEF6-B695B5B2E8A7@icloud.com> <91B7C40D-1801-4899-B4E9-09976D2C029D@akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 07:49:46 -0000 > On Dec 11, 2017, at 2:32 PM, Salz, Rich wrote: >=20 >> To sum up and apply my observations, yes, I think SCEP ought to be = standards-track, and not historic. >=20 > But if Russ is correct, then Informational =E2=80=93 documenting = something done outside of the IETF =E2=80=93 is more accurate. Do you = disagree? >=20 Well, many protocols developed outside of the IETF are on Standards = Track.=20 I tend to think of informational RFCs as being =E2=80=94 something not = quite real. On the other hand, as noted, SCEP as a protocol is pretty = much done. If the IETF isn't going to be doing any work on it, then = maybe informational is the proper thing. Jon From nobody Tue Dec 12 05:26:59 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B35129457 for ; Tue, 12 Dec 2017 05:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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=sn3rd.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 CjTpuSJX5Vpz for ; Tue, 12 Dec 2017 05:26:56 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 601F1129453 for ; Tue, 12 Dec 2017 05:26:56 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id r39so47056839qtr.13 for ; Tue, 12 Dec 2017 05:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fVMOzMV4iFo0eIIz7RO+M4at3vNWNbON/ZmYKy9F5wE=; b=QLb02akHE3QrldQtqYuYk15xHfdKemzPCACcJAa2MzkP4RXZhm7H5Wrc5t49shdusT xCeUmLyVtKnnmRH3lr6vkvM9TUqtCCkZhfLbnJXf3rVAGViMdmyUr7jtPdwHtx9gp66E B919FTHpKTb/ThGPtXtnx3Ls0JuH8hyXrytgM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fVMOzMV4iFo0eIIz7RO+M4at3vNWNbON/ZmYKy9F5wE=; b=Hwfwb/qHOZfbvUkuSSaxZjl4eTMQu1yreZIbbWzJ1KYyN4mvHpOrO0APlL1BRQ7qFm e7xobGYWeA01IIE6qGO4we0T4v7GzGISUNY7p/Ii0hDaUX2y/DL1Kpbl9Jx67d2KaSkb dRidY/uOagajVWs32TmV0doRIJTSSWYBj2vvebzrj1fpgVK2TTCsMStBbt1+DiSNJu0v pSdwe1l6VTuIyXISfztZ9KlJUnF4HoMVTOcuy5RxcCKGedkPbGbiuamBwlHIpWHtbSFJ Qid+CyUikpvLtPk6OWR2GB/ldvRHfZaeIA5iW7uVqski4Cv2gzkOQDwzHgjZS3kRlouy QDGg== X-Gm-Message-State: AKGB3mL6TBFwmmKKvjQ7PzdNGJSvUacKHVoJ3WWFw2OzEF0CCxWTv2qQ OE+VnDLLcOmdo39mf42gkigwSQ== X-Google-Smtp-Source: ACJfBoum99JZCeeb1eocFXM9SLeN2lGbrp7iX+V7v2P76+N7Er6AyeqCXbxsWxZGiuORIAFuqLtyWQ== X-Received: by 10.55.207.216 with SMTP id v85mr5249174qkl.331.1513085215422; Tue, 12 Dec 2017 05:26:55 -0800 (PST) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id c1sm5863500qta.52.2017.12.12.05.26.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Dec 2017 05:26:54 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <1513050187576.97593@cs.auckland.ac.nz> Date: Tue, 12 Dec 2017 08:26:53 -0500 Cc: "saag@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> <1512952085878.6345@cs.auckland.ac.nz> <6399716C-BD6C-49A0-A346-9AC431241B51@akamai.com> <840AAD22-8A8A-4482-AEF6-B695B5B2E8A7@icloud.com> <91B7C40D-1801-4899-B4E9-09976D2C029D@akamai.com> <30C85592-D5CE-4A32-A6A1-CA22AEEB86A2@sn3rd.com> <1513050187576.97593@cs.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 13:26:58 -0000 > On Dec 11, 2017, at 22:43, Peter Gutmann = wrote: >=20 > Sean Turner writes: >=20 >> The thing though is that the specification, at least, has had quite a=20= >> number of changes since then >=20 > The bits-on-the-wire is still identical, the reason so much of the = text has > changed is because the document grew by accretion and the rewrite was = an > attempt to... well, as the appendix says: >=20 > This specification has spent more than seventeen years in the draft > stage. [...] To fit this role, extra features were bolted on in a > haphazard manner through the addition of a growing list of = appendices > and by inserting additional, often conflicting, paragraphs in = various > locations in the body text. Since existing features were never > updated as newer ones were added, the specification accumulated = large > amounts of historical baggage over time.=20 >=20 > [More text that basically says "this update cleans things up"] >=20 > So it's the same on-the-wire protocol, just with the text describing = it=20 > cleaned up. This is excellent news! >> Note that I believe all of RSA's PKCS specifications published = through the=20 >> IETF stream were informational. >=20 > Ah, fair enough. As I mentioned previously, I can live with = Informational > if that's what the rules say. Yeah I=E2=80=99m coming around to Informational. >> And that brings up another point that I think needs to be made clear. = =20 >> Often, RSA has explicitly granted change control to the IETF. = Because SCEP=20 >> started out as "Cisco Systems' Simple Certificate Enrollment = Protocol=E2=80=9D and=20 >> was that way up until draft-nourse-scep-22 is Cisco doing the same = here? >=20 > When I revived the draft, I posted messages to everywhere I could = think of > that had SCEP people (the old SCEP mailing list, the JSCEP list, and = there > was something done at an IETF) and asked if anyone had any objections = if I=20 > continued with the work. It was pretty informal. >=20 > (There was discussion about it with the original authors who could = still be > contacted, but it was all in private email, if any of the original = authors > want to speak out publicly, feel free). Since, this has been going on for so long - I suspect that if there was = an issue they=E2=80=99d speak up; they=E2=80=99re not shy ;) >> I gotta ask about the dropped pre-5378 boiler plate. Was approval = obtained=20 >> from each of the previous authors: Xiaoyi Liu, Cheryl Madson, David = McGrew,=20 >> Andrew Nourse, Jan Vilhuber, and Max Pritikin? It=E2=80=99s annoying = process=20 >> mumbo-jumbo but because I couldn=E2=80=99t get an answer from = everybody the pre-5378=20 >> boiler plate had to be included in the SSL RFC:=20 >> https://datatracker.ietf.org/doc/rfc6101/. >=20 > Some of the authors can't be contacted any more (some of the removal = requests=20 > I mentioned in a previous message were things like "X left the company = Y=20 > years ago, please remove their name"), so in general, "no". However = given=20 > that 5378 dates from the time of draft-nourse-scep-xx, wouldn't it = already=20 > fall under 5378? >=20 > Just as an FYI, there wasn't any explicit move from boilerplate-X to=20= > boilerplate-Y, the draft just contains whatever xml2rfc puts in there = by > default. I really don't mind what boilerplate it comes with, as long = as=20 > it's not too much of a headache to deal with via xml2rfc, which from = memory > dings you for the use of outdated boilerplate. It ought to be easy, mind you I avoid xml2rfc like the plague. But, I = think in your xml you just need to make the following change to make the = boilerplate appear: OLD: NEW: Based on: https://tools.ietf.org/tools/templates/mib-doc-template-xml.txt spt > Peter. From nobody Tue Dec 12 06:37:01 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071FB12943F for ; Tue, 12 Dec 2017 06:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=fugue-com.20150623.gappssmtp.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 yJPjGNUh0MdZ for ; Tue, 12 Dec 2017 06:36:58 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 0F820126BF7 for ; Tue, 12 Dec 2017 06:36:57 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id f2so47678631qtj.4 for ; Tue, 12 Dec 2017 06:36:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5HBh5sDnfgwieJhN/dvlLsbUgFK6+8pSNS5Mc+niFFY=; b=VTBSJFKi2u3MdCRyifXdJBJtaxjY4ybG05nu4hvgWz0dbhfSIVoTANqKR99WmvrOSq 4stthqYs8/N7S+Cv59zHor73Kz0R/FIUPA75u8oTxU9hXTK1lvJGF9iUo3QOIPsFn1gi 6WoOQB+nM20+wLU0kHjrI5+D1PadFwU+SizyNAb/8IWguAN+kgp1t8Nz0mVbFkj6K9iz rjmDlLn2Zr3Z2A4CCPQ38it77H4oohuVuCx0g5pYO8N+iusFE7Gq5daSoNpypzP9sIhH BkUFaTqVvqt8TMEJzU+gXb27SLV5tC5Kovo1W+XCS63C3lfShTTFdgyVdnZF11eFmEzk KLsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5HBh5sDnfgwieJhN/dvlLsbUgFK6+8pSNS5Mc+niFFY=; b=IvSnWyrvFX6Y+sRQJdDthgZVsrqv8ja111xOwm/Xy25gRCu25AA0hUMOlWAJxvSCE/ LZYovSzlxeHhkhPPwiiQWAP2+PQRKix6cOApc11XWNjHnl7DN3tYKzTfXikmssdGPeuh Ygfma9wxo3aSyFHQj22UqsGK/uBaZvga+dmdFvsk9hpoEwmm+WNYIEPj6UmfEhMuhPP8 K9bgOcfoSB/J3QQvIeB55sGcDyvvHH211oPH9JbIV7tlAh6otOKsOTPyiRArcnp00PUf OXiErBDW2R3vZDPV5nbXrFYBVYYbX42mahikXbel6RNWEZs4TaArTw08J+3bIx1fhbwX 54Bw== X-Gm-Message-State: AKGB3mKD8srOfd5AETvZGPZ05YMWODVSW9SA01ZvJC9PO41T1KEXg6nD YaTpPPqCKJioatVodkmAXSA+sQ== X-Google-Smtp-Source: ACJfBouCVd882xThrVDg7b8wcnZM/GrUMJBwCqplDEpIRz+QEvlNMEf0nUN+OLMFoCK47d2oYeA0XA== X-Received: by 10.55.73.13 with SMTP id w13mr5414109qka.201.1513089416752; Tue, 12 Dec 2017 06:36:56 -0800 (PST) Received: from [10.0.30.153] (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id u3sm5785045qka.39.2017.12.12.06.36.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Dec 2017 06:36:55 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6A21601E-3C40-43B6-9446-185EE11C1F05" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 12 Dec 2017 09:36:52 -0500 In-Reply-To: <5ADD71EF-5C63-4A2A-BF72-3812ACD6102C@icloud.com> Cc: "Salz, Rich" , "saag@ietf.org" To: Jon Callas References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> <1512952085878.6345@cs.auckland.ac.nz> <6399716C-BD6C-49A0-A346-9AC431241B51@akamai.com> <840AAD22-8A8A-4482-AEF6-B695B5B2E8A7@icloud.com> <91B7C40D-1801-4899-B4E9-09976D2C029D@akamai.com> <5ADD71EF-5C63-4A2A-BF72-3812ACD6102C@icloud.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 14:37:00 -0000 --Apple-Mail=_6A21601E-3C40-43B6-9446-185EE11C1F05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 12, 2017, at 2:49 AM, Jon Callas wrote: > I tend to think of informational RFCs as being =E2=80=94 something not = quite real. On the other hand, as noted, SCEP as a protocol is pretty = much done. If the IETF isn't going to be doing any work on it, then = maybe informational is the proper thing. The rule historically, at least for the history when I was on the IESG, = which isn't all that historical, is that if the IETF is going to change = the protocol, then it's a standard, but if we want to publish what is = deployed, for whatever reason (usually as a baseline for further work, = but I think this use case also qualifies), we publish it as = informational. Not because it's not a standard, but because it's not a = standard the IETF developed. --Apple-Mail=_6A21601E-3C40-43B6-9446-185EE11C1F05 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 12, 2017, at 2:49 AM, Jon Callas <joncallas@icloud.com> wrote:
I tend to think of informational RFCs as = being =E2=80=94 something not quite real. On the other hand, as noted, = SCEP as a protocol is pretty much done. If the IETF isn't going to be = doing any work on it, then maybe informational is the proper = thing.

The rule historically, at least for the = history when I was on the IESG, which isn't all that historical, is that if the IETF is going to = change the protocol, then it's a standard, but if we want to publish = what is deployed, for whatever reason (usually as a baseline for further = work, but I think this use case also qualifies), we publish it as = informational.   Not because it's not a standard, but because it's = not a standard the IETF developed.

= --Apple-Mail=_6A21601E-3C40-43B6-9446-185EE11C1F05-- From nobody Tue Dec 12 06:51:07 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0AF129483 for ; Tue, 12 Dec 2017 06:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=redhoundsoftware.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 nrjLbOnxt99n for ; Tue, 12 Dec 2017 06:51:04 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 700A9129480 for ; Tue, 12 Dec 2017 06:51:04 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id m59so47758124qte.11 for ; Tue, 12 Dec 2017 06:51:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=DzvoHZi6Zj6ZikgLGBM4whf0IzjX8vcds9yXu8BnoJI=; b=Zq+rEmmBaLmikvPHxQXUuF0VQE3m/RbzKc+lyBbVAPZqyzIKrMH8IhuGxYkc/K9WgE mZrmFimWwP33hkQsbMEbECJtJIQs/OHUrbkt8kHQH1pc/AKXnrslEjfBrl4oOWOYGXAb mmD97lQtwSaE3lXCv4ue9C6Y9aaaDXCU+NkmM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=DzvoHZi6Zj6ZikgLGBM4whf0IzjX8vcds9yXu8BnoJI=; b=ZYfMb1MT8oDvrihN6Cb1fP4Bp5gzSOM49djaAV0lC97c9KJ3oqxKB44HUjUn99FhPB +v9yoCgVVgdf94DYiSm/CFxLCbULo3VZENjjdBWL/4eLmz1+ua67+/0fUtIer4ptaHrM 8lHXqgqmmEMQM8O/4dVtu/RtEd98wYcb8COf90gQ/gXazT7a7eT+VRS9XdIKCEeYs8WZ nVy8dKK5asRUvT9cWeJdRITk6jYUr5Kxj3uHK8fMDZOA1/X6BiPzH22DQvtRpY7PDjfe JAsw+WuPreYJhv+dDTO3cR231RnLBv6YdGHnjrQVAIBSvnFFfXWzokQ8MkCb/ubTvF36 +CxA== X-Gm-Message-State: AKGB3mJO0mJY4whvIzylXd8BfHvNuyxtDd5F7OdTQ4s7qBIhyMUNO/pU 1iiW/b1GFOoQzjJagxwdnidC/g== X-Google-Smtp-Source: ACJfBou0F9Xau9d17owCFFfyK6KI6rutLqv7vROhZU8x75YfurM6S5ZYWN6DjvkIaboxdSmcHuNpHg== X-Received: by 10.55.178.68 with SMTP id b65mr5800505qkf.139.1513090263505; Tue, 12 Dec 2017 06:51:03 -0800 (PST) Received: from [192.168.2.27] (pool-173-66-76-215.washdc.fios.verizon.net. [173.66.76.215]) by smtp.googlemail.com with ESMTPSA id s4sm5614484qkd.66.2017.12.12.06.51.01 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 12 Dec 2017 06:51:02 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.7.6.170621 Date: Tue, 12 Dec 2017 09:50:57 -0500 From: Carl Wallace To: Ted Lemon , Jon Callas CC: "saag@ietf.org" Message-ID: Thread-Topic: [saag] Status of the SCEP RFC draft References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> <1512952085878.6345@cs.auckland.ac.nz> <6399716C-BD6C-49A0-A346-9AC431241B51@akamai.com> <840AAD22-8A8A-4482-AEF6-B695B5B2E8A7@icloud.com> <91B7C40D-1801-4899-B4E9-09976D2C029D@akamai.com> <5ADD71EF-5C63-4A2A-BF72-3812ACD6102C@icloud.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3595917062_7181882" Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 14:51:06 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3595917062_7181882 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable From: saag on behalf of Ted Lemon Date: Tuesday, December 12, 2017 at 9:36 AM To: Jon Callas Cc: "saag@ietf.org" Subject: Re: [saag] Status of the SCEP RFC draft > On Dec 12, 2017, at 2:49 AM, Jon Callas wrote: >> I tend to think of informational RFCs as being =E2=80=94 something not quite r= eal. On >> the other hand, as noted, SCEP as a protocol is pretty much done. If the= IETF >> isn't going to be doing any work on it, then maybe informational is the >> proper thing. >=20 > The rule historically, at least for the history when I was on the IESG, w= hich > isn't all that historical, is that if the IETF is going to change the > protocol, then it's a standard, but if we want to publish what is deploye= d, > for whatever reason (usually as a baseline for further work, but I think = this > use case also qualifies), we publish it as informational. Not because i= t's > not a standard, but because it's not a standard the IETF developed. >=20 > [CW] While Informational seems like a better fit than Historic, the "not = IETF > developed" notion seems odd for a draft with over 30 IETF Internet Draft > revisions with some significant differences between low version numbers a= nd > later versions (I.e., addition of GetCACaps, at a minimum). Even the draf= t > that is the subject of this thread is introducing some changes to the spe= c > within the IETF context (i.e., adding new algorithms and deprecating old)= . >=20 --B_3595917062_7181882 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

From: saag <saag-= bounces@ietf.org> on behalf of Ted Lemon <mellon@fugue.com>
Date: <= /span> Tuesday, December 12, 2017 at 9:36 AM
To: Jon Callas <joncalla= s@icloud.com>
Cc: "saag@ietf.org" <saag@ietf.org>
Subject: Re= : [saag] Status of the SCEP RFC draft

On Dec 12, 2017, at 2= :49 AM, Jon Callas <joncal= las@icloud.com> wrote:
I tend to think of informational RFCs as be= ing — something not quite real. On the other hand, as noted, SCEP as a= protocol is pretty much done. If the IETF isn't going to be doing any work = on it, then maybe informational is the proper thing.

The rule historically, at least for the history when I w= as on the IESG, which isn't all that historical, is tha= t if the IETF is going to change the protocol, then it's a standard, but if = we want to publish what is deployed, for whatever reason (usually as a basel= ine for further work, but I think this use case also qualifies), we publish = it as informational.   Not because it's not a standard, but because it'= s not a standard the IETF developed.

[CW] While Informational seems like a b= etter fit than Historic, the "not IETF developed" notion seems odd for a dra= ft with over 30 IETF Internet Draft revisions with some significant differen= ces between low version numbers and later versions (I.e., addition of GetCAC= aps, at a minimum). Even the draft that is the subject of this thread is int= roducing some changes to the spec within the IETF context (i.e., adding new = algorithms and deprecating old).

 --B_3595917062_7181882-- From nobody Tue Dec 12 19:39:21 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691D21273E2 for ; Tue, 12 Dec 2017 19:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 D6dAV4qfzM_e for ; Tue, 12 Dec 2017 19:39:17 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 B8B7A126CBF for ; Tue, 12 Dec 2017 19:39:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1513136356; x=1544672356; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zx4yV4CiObongYs1MfqKTO4JsWdGOy3RCTTpHdXV04M=; b=qVD5pcMvHw3xA5kUekij6iEd40f+VqvH1DNu0MLtk1MgN97GKbveFcNV rK0hVGfn9awTGQ5IwL+c/Tp7//cBIXLxaHby0PfK1Sy24wwUquJpZPXEX Qyw7BMEi6G+cVCA7BOD52f9GO0IrrtHJRHsw+f+XBxkuM9AKkGw5Shqv6 wsnXTw88yRm1uIhr9wb9ZmBOH2JhauNWuJByVfhdP0tQZdxzoHZ2Cv7YA x6O+xvYa61NbkgMiV8stzXOGAMDdn9cYdd6KqX2hCzlA5qJFJAj4cQaei 1SKPqtTAcLeClUraInyWWdNanvs5YOKfpp9iYXJtFjOlZVeu4HjKEFk22 w==; X-IronPort-AV: E=Sophos;i="5.45,396,1508756400"; d="scan'208";a="203260722" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from uxcn13-ogg-b.uoa.auckland.ac.nz ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Dec 2017 16:39:13 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.3) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 13 Dec 2017 16:39:13 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Wed, 13 Dec 2017 16:39:12 +1300 From: Peter Gutmann To: Sean Turner CC: "saag@ietf.org" Thread-Topic: [saag] Status of the SCEP RFC draft Thread-Index: AQHTbw4UUnneaIh1UU6hdrWtX9hT6aM52C8AgABMNQCAAEU+gIAAA2GAgAGSL4CAAU7l1YAAWooAgAASSgCAABRIgIAAGIGAgAA3hQCAAPfrwf//ypGAgAHHt6I= Date: Wed, 13 Dec 2017 03:39:11 +0000 Message-ID: <1513136348753.3364@cs.auckland.ac.nz> References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> <1512952085878.6345@cs.auckland.ac.nz> <6399716C-BD6C-49A0-A346-9AC431241B51@akamai.com> <840AAD22-8A8A-4482-AEF6-B695B5B2E8A7@icloud.com> <91B7C40D-1801-4899-B4E9-09976D2C029D@akamai.com> <30C85592-D5CE-4A32-A6A1-CA22AEEB86A2@sn3rd.com> <1513050187576.97593@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 03:39:19 -0000 Sean Turner writes:=0A= =0A= >I think in your xml you just need to make the following change to make the= =0A= >boilerplate appear:=0A= >=0A= >OLD:=0A= >=0A= >=0A= >=0A= >NEW:=0A= >=0A= >=0A= =0A= Ah, that's easy enough, thanks. I'll make that change and also reclassify = it=0A= as Informational, so category=3D"info".=0A= =0A= One question, to anyone in general, the draft currently has:=0A= =0A= Sample SCEP Messages=0A= =0A= (Omitted from the drafts to keep the size down).=0A= =0A= What are people's thoughts on including samples like this? I'd definitely= =0A= like to do it because, as the text says, it "gives implementers something t= o=0A= aim for", but it's also going to blow the document size out enormously. Wh= en=0A= the S/MIME samples were created they were put in a separate, 135-page RFC,= =0A= presumably to avoid doing the same to the base S/MIME / CMS RFCs. For SCEP= ,=0A= because of the sign( encrypt( request ) ) form for requests and responses a= nd=0A= the presence of certs and attributes, the pretty-printed form will run to= =0A= 40-50 pages at least.=0A= =0A= What's the thinking on including sample messages? In base64-encoded form? = As=0A= broken-down pretty-printed structures? Link to some web site somewhere?=0A= =0A= Peter.=0A= From nobody Tue Dec 12 20:06:45 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4479128D0D for ; Tue, 12 Dec 2017 20:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdiFRQ08-nw1 for ; Tue, 12 Dec 2017 20:06:41 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76EE11200F3 for ; Tue, 12 Dec 2017 20:06:41 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 12 Dec 2017 20:04:58 -0800 From: Jim Schaad To: 'Peter Gutmann' , 'Sean Turner' CC: References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> <1512952085878.6345@cs.auckland.ac.nz> <6399716C-BD6C-49A0-A346-9AC431241B51@akamai.com> <840AAD22-8A8A-4482-AEF6-B695B5B2E8A7@icloud.com> <91B7C40D-1801-4899-B4E9-09976D2C029D@akamai.com> <30C85592-D5CE-4A32-A6A1-CA22AEEB86A2@sn3rd.com> <1513050187576.97593@cs.auckland.ac.nz>, <1513136348753.3364@cs.auckland.ac.nz> In-Reply-To: <1513136348753.3364@cs.auckland.ac.nz> Date: Tue, 12 Dec 2017 20:06:11 -0800 Message-ID: <027e01d373c7$b7d608e0$27821aa0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJICfxZFNYifoQOvFO0olqkGbOF0gFT4r69AlF0NYsCKsmpCgFfn+XtArJG0ZcBsI0kSQJMdG1sAqlSsVEB5l7btQE+kRxXArE1DH8DIBQcYgGuf4vCAcRqSIihb+70IA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 04:06:44 -0000 > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Peter Gutmann > Sent: Tuesday, December 12, 2017 7:39 PM > To: Sean Turner > Cc: saag@ietf.org > Subject: Re: [saag] Status of the SCEP RFC draft > > Sean Turner writes: > > >I think in your xml you just need to make the following change to make > >the boilerplate appear: > > > >OLD: > > > > > > > >NEW: > > > > >docName="draft-gutmann-scep-07"> > > Ah, that's easy enough, thanks. I'll make that change and also reclassify it as > Informational, so category="info". > > One question, to anyone in general, the draft currently has: > > Sample SCEP Messages > > (Omitted from the drafts to keep the size down). > > What are people's thoughts on including samples like this? I'd definitely like to > do it because, as the text says, it "gives implementers something to aim for", > but it's also going to blow the document size out enormously. When the > S/MIME samples were created they were put in a separate, 135-page RFC, > presumably to avoid doing the same to the base S/MIME / CMS RFCs. For > SCEP, because of the sign( encrypt( request ) ) form for requests and responses > and the presence of certs and attributes, the pretty-printed form will run to > 40-50 pages at least. > > What's the thinking on including sample messages? In base64-encoded form? > As broken-down pretty-printed structures? Link to some web site somewhere? My view would be a couple of very simple examples to show major concepts in the document. Base64 is better for me because I can run it through my code and see what happens, this also implies needing any keys used as well. If you want to do a more complete set of examples (and I would encourage you), then a pointer to a web site someplace would be my preference. Jim > > Peter. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Wed Dec 13 09:05:25 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6A31270B4 for ; Wed, 13 Dec 2017 09:05:24 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 HkpxEQ_QdVn8 for ; Wed, 13 Dec 2017 09:05:23 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 2231012706D for ; Wed, 13 Dec 2017 09:05:23 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id m59so4494901qte.11 for ; Wed, 13 Dec 2017 09:05:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cbwhtvsuDKTJ+dDLs3dVRhjwc6Z6N7u9gR99cLvHBoA=; b=L/H8BmjNEV94en8mZGsEb1CuLdMu6EGdFsZf0TSYGR1hFNADDNkpp5V7bL4Gyb9BF8 1u+gBnxGbxLAnYnpm5B0b/OfPGEY3H+HWwmnKxc7tBCc5y8Sq0PVkqJHaZo6OzhyJoNw edCn20H997ZxNR4jFTDaI1owYfNnlCe8qNiA0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cbwhtvsuDKTJ+dDLs3dVRhjwc6Z6N7u9gR99cLvHBoA=; b=oW2pywnZ+9xktDAqh3oY9YKXigjj00FXFCbqQRhPOuZ8NcFMxHssF1XTZEkHvljmgd Zsqb/6mjKYYot8eWZXnNqiU/PeF1m1XUls6tg2Cx22WfZ+5frNG3YnyOzBErGMinNRLD GNZS11aU2cbCX7hPSDGcRD4rPT4MTKBmzR8MSZrdH2CE0eQGbeGj4FoWEjcjFEFal/im Jt2SV7LgLSuA3CvYbJta0HNo+pmDZHXTECK6GFDEHTRgACLn9x+iDSP2S3Y2rROizQOU xsjv8Wv/HnFL/NM/lwmzEX6z9tVrwiXFP16eI/JJoTwPf9laDwa3cJzS0nsNtvUbZEEK fIKg== X-Gm-Message-State: AKGB3mLNvCyZMOk/vE3bkCrTGpJ0S3QHjlkSqDHCvSb34ar2mAScBDhJ IPKNFuNZUEnG/bdjc23YS9A63Q== X-Google-Smtp-Source: ACJfBotBih0Sp5b6fPFkQDLy9Wde76XCIxq4x8UIyzYJk+y+EvzjCs0VsCSxD+P10g4jFyYpbcYmig== X-Received: by 10.200.36.134 with SMTP id s6mr11541582qts.276.1513184722328; Wed, 13 Dec 2017 09:05:22 -0800 (PST) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id b65sm1399938qkb.45.2017.12.13.09.05.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 09:05:21 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <027e01d373c7$b7d608e0$27821aa0$@augustcellars.com> Date: Wed, 13 Dec 2017 12:05:20 -0500 Cc: saag@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <785110B0-7D99-4B31-98F3-F344B7F4A668@sn3rd.com> References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> <1512952085878.6345@cs.auckland.ac.nz> <6399716C-BD6C-49A0-A346-9AC431241B51@akamai.com> <840AAD22-8A8A-4482-AEF6-B695B5B2E8A7@icloud.com> <91B7C40D-1801-4899-B4E9-09976D2C029D@akamai.com> <30C85592-D5CE-4A32-A6A1-CA22AEEB86A2@sn3rd.com> <1513050187576.97593@cs.auckland.ac.nz> <1513136348753.3364@cs.auckland.ac.nz> <027e01d373c7$b7d608e0$27821aa0$@augustcellars.com> To: Peter Gutmann X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 17:05:24 -0000 > On Dec 12, 2017, at 23:06, Jim Schaad wrote: > > My view would be a couple of very simple examples to show major concepts in > the document. +1 spt From nobody Wed Dec 13 18:21:32 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8221200F1; Wed, 13 Dec 2017 18:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 1yMecKFGujHV; Wed, 13 Dec 2017 18:21:23 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 63958127517; Wed, 13 Dec 2017 18:21:23 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yxy3h1npfzCt4; Thu, 14 Dec 2017 03:21:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1513218080; bh=gWH4ePG+U+FIuTSGgFFV+6Vo/jBrE/JZDApx7cBZFso=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=WFkC248HXe8q853r7C4QdvKyBvQtsyDPSbERDwPc4UZxg3vohjvughgFR87yLTzMv XnwqrqAtfScCxIYuuMRjpq8tm3dtofXlkAkq7qJD0wYqhCk3+yFa4RNzIwiGhhOLw7 w7b9s4xeMTNNPkMIOZwnfDtPryYDHr/Bf4YObeC8= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id l-2JW9aQsRVD; Thu, 14 Dec 2017 03:21:18 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 14 Dec 2017 03:21:17 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 161F070A3FA; Wed, 13 Dec 2017 21:21:17 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 161F070A3FA Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 12AE24070CE2; Wed, 13 Dec 2017 21:21:17 -0500 (EST) Date: Wed, 13 Dec 2017 21:21:16 -0500 (EST) From: Paul Wouters To: Brian Witten cc: "patient@ietf.org" , saag@ietf.org In-Reply-To: Message-ID: References: , , , , , , User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [saag] [Patient] Internet Draft posted as requested -:$ X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 02:21:26 -0000 On Wed, 13 Dec 2017, Brian Witten wrote: [ Adding saag@ietf.org for now, as I don't think many of the security people made it to the new patient list yet ] > I wanted to get the Internet Draft ( https://www.ietf.org/id/draft-witten-protectingendpoints-00.txt ) This document confuses me. - It does not specify a new protocol - It does not specify a concrete problem (use cases) - It does not specify any kind of architecture The Abstract states: This document describes the logic for third-party and network security to complement strong cryptographic protocols, and presents data, including independently verifiable data, helping scale the importance of blocking attacks that might be hiding in encrypted network traffic. This report includes data from multiple sources. Some of that data is verifiable. What logic does it specify? What complementing security does it specify? The conclusion states: Precluding network based protection for endpoints is not consistent with the imperative to treat mass surveillance as an attack. Mass hacking of endpoints is surveillance by another means. Equating the number of compromised hosts with the number of visible hosts to a pervasive monitoring agent makes no sense. But more importantly, you state that pervasive monitoring should make way for network based monitoring (or rather, "voluntary" host based extrusion of privacy to (un)trusted third parties). This obvious comes with a huge problem of designing an "opt-in" protocol that a nation state can abuse to be "never opt-out" As much as I don't like draft-mm-wg-effect-encrypt for fear of security companies grasping at it for a justification of pushing back against end to end encryption, if you read that document, it does a much better job of neutrally informing people of the issues of deplying endpoint encryption (which I prefer to call "pervasive privacy"). If you remove that content from your document, nothing much is left. I know from your presentations and conversations that you believe hosts securly connecting to a proxy is not good enough to solve the issues you deem exist. Your document should instead focus on that. Which current IETF protocols are in use to achieve endhost security, why are these no longer feasable, what changes do you need to make this work. You don't need to present statistics about security failures. So far, I am still not convinced that a SOCKS proxy or even a DNS proxy, connected via a VPN, is not sufficient to filter out malicious data. Again, from your conversations and presentations (not from this document) I know you are looking at endnodes giving out private key material to a trusted third party. Convince me why this is required from a protocol point of view, not a business model point of view. The fact that your collegue's email showed leakage of such "protection" system by leaking https://clicktime.symantec.com/ links in response to an ietf email does not help be gain confidence that I should change a security protocol to facilitate the protocol modifications presented at the BOF. Paul From nobody Wed Dec 13 18:30:53 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA5412711D; Wed, 13 Dec 2017 18:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 OLPOxc5cv3xT; Wed, 13 Dec 2017 18:30:49 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 A2804120727; Wed, 13 Dec 2017 18:30:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1513218648; x=1544754648; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=c3kDmvfDwLOPedQ0xaux0x78GG4x/+p1gTAkDP4OpJ8=; b=uZjKYWpkgjXmsPq6DaNpfsAyyMldfw9wXjFvDrv8fBwsu/jLwEHFhTsk 0tt1y8Fad10at/vBv5HaVqQs53cHWLlw3Crqj4oGiKY191Ei6stCyl09P FQkgLLmiJKQUbel5jiHZdKW/Mpg387nhQRlKcWMBQLZa89GZULdwjtpVD k5WxDNIrXnTIWvHaGHp6WHF3XTJtqBXTR8xnVimm6a7b4caDk3BMgFNT9 0gs2hNBz3fa2ePqB5wVviea/F9ikmPrB5h4cSIORoOWU3wpAoAi6UKXru f0SQ0OzuiphBFEdsXMH+1+RprlmwACFMbuD2FLiE2qtqOygIBHwcn02tt g==; X-IronPort-AV: E=Sophos;i="5.45,399,1508756400"; d="scan'208";a="203473330" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-ogg-a.UoA.auckland.ac.nz) ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 14 Dec 2017 15:30:45 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.22) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 14 Dec 2017 15:30:45 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Thu, 14 Dec 2017 15:30:45 +1300 From: Peter Gutmann To: Paul Wouters , Brian Witten CC: "patient@ietf.org" , "saag@ietf.org" Thread-Topic: [saag] [Patient] Internet Draft posted as requested -:$ Thread-Index: AQHTdIJP2T4pX6sRh0e/IMgxnuIp0qNCHRuj Date: Thu, 14 Dec 2017 02:30:45 +0000 Message-ID: <1513218639499.40211@cs.auckland.ac.nz> References: , , , , , , , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] [Patient] Internet Draft posted as requested -:$ X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 02:30:51 -0000 Paul Wouters writes:=0A= =0A= >This document confuses me.=0A= >=0A= >- It does not specify a new protocol=0A= >- It does not specify a concrete problem (use cases)=0A= >- It does not specify any kind of architecture=0A= =0A= It reads like a blog post.=0A= =0A= In fact, why not post it to the Symantec Security Response blog?=0A= =0A= Peter.=0A= From nobody Wed Dec 13 18:51:43 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C761B1276AF; Wed, 13 Dec 2017 18:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 kjVoGFWV5W_j; Wed, 13 Dec 2017 18:51:39 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A827120727; Wed, 13 Dec 2017 18:51:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 509C4BEBB; Thu, 14 Dec 2017 02:51:36 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmqdVG35bQFt; Thu, 14 Dec 2017 02:51:34 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1B290BE55; Thu, 14 Dec 2017 02:51:34 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1513219894; bh=m/l3dpiOE6f4U7vJYmz3gUac1ICtBW18W+RAI4g28Ww=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=dPx3cL1SRC492JRZ+hmbghzmHK7soYvs+FIEU3Zyy7tb/M91nLf0RnXmIbws5VztB Waigi3sSqHehnoiI9/WQAsj6KHCgwTlx/ELoosnqppUzPW9Zm2h3GLInywiJ1R4xjk fWprSnSo1x71t9RLUn4MRyXF0l3LaDItnCvASirA= To: Paul Wouters , Brian Witten Cc: "patient@ietf.org" , saag@ietf.org References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <570c0df2-afdb-e77c-ab1d-bfaef7d14791@cs.tcd.ie> Date: Thu, 14 Dec 2017 02:51:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NgAvau0geWH2Ll4er4bAef09rf3wOUmPT" Archived-At: Subject: Re: [saag] [Patient] Internet Draft posted as requested -:$ X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 02:51:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NgAvau0geWH2Ll4er4bAef09rf3wOUmPT Content-Type: multipart/mixed; boundary="eDqIGHWLbiV7NjsaqVFs5jM5Eq9QEEnSx"; protected-headers="v1" From: Stephen Farrell To: Paul Wouters , Brian Witten Cc: "patient@ietf.org" , saag@ietf.org Message-ID: <570c0df2-afdb-e77c-ab1d-bfaef7d14791@cs.tcd.ie> Subject: Re: [saag] [Patient] Internet Draft posted as requested -:$ References: In-Reply-To: --eDqIGHWLbiV7NjsaqVFs5jM5Eq9QEEnSx Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable I also had a quick look at the draft. In addition to Paul's questions, I have one more: Where in the draft is there evidence of anything at all that actually argues for the mitm attacks on https that you (Brian) are espousing? There is blatant assertion of irrelevancies, but nothing that I saw that actually makes a logical argument that the mitm attack you want is even useful, never mind necessary. Put another way... to quote the start of the abstract: "This document describes the logic ..." where is the description of anything at all that could be called relevant logic? I failed to find it, sadly. Secondly, and keeping the criticism to the abstract (in what is a target-rich field;-): "This report includes data from multiple sources." is nonsense as none of the "data" from (anonymous!) sources that is presented (and all in a non-verifiable manner [*]) is actually relevant to the claimed thesis that mitm attacks on https are "needed" (for any other reason than presumably selling products and services). Note that I do think it ought be possible to produce evidence that these kinds of mitm attacks are not valueless, [**] but that's not done here, and even if it were, I doubt it'd be worthwhile as a trade-off to choose, given the gigantic costs of breaking security for all the rest of us who want at least commsec that resembles something that works in a known manner. (And who recognise that the state of the art is not perfect.) So this seems to me like an utterly risible failure to make an even vestigially convincing argument for an in-any-case losing argument. Cheers, S. [*] The challenge I made (and that Brian accepted) at ietf-100 was for the proponents of this iteration of breaking https to produce some verifiable evidence that such mitm attacks are at all useful, never mind necessary. As anyone who'll read the 6 pages produced a few months later will see, that challenge remains to be met. [**] It ought be easy to convincingly show that inbound malware detection latency is lower vs. other solutions such as endpoint mechanisms or honeypots in at least some verifiable circumstances. (And even if so, the costs involved aren't worth breaking things so much.) The draft here is clearly light-years from such a demonstration. On 14/12/17 02:21, Paul Wouters wrote: > On Wed, 13 Dec 2017, Brian Witten wrote: >=20 > [ Adding saag@ietf.org for now, as I don't think many of the security > =C2=A0 people made it to the new patient list yet ] >=20 >> I wanted to get the Internet Draft ( >> https://www.ietf.org/id/draft-witten-protectingendpoints-00.txt ) >=20 > This document confuses me. >=20 > - It does not specify a new protocol > - It does not specify a concrete problem (use cases) > - It does not specify any kind of architecture >=20 > The Abstract states: >=20 > =C2=A0=C2=A0 This document describes the logic for third-party and netw= ork > =C2=A0=C2=A0 security to complement strong cryptographic protocols, and= presents > =C2=A0=C2=A0 data, including independently verifiable data, helping sca= le the > =C2=A0=C2=A0 importance of blocking attacks that might be hiding in enc= rypted > =C2=A0=C2=A0 network traffic.=C2=A0 This report includes data from mult= iple sources. > =C2=A0=C2=A0 Some of that data is verifiable. >=20 > What logic does it specify? >=20 > What complementing security does it specify? >=20 > The conclusion states: >=20 > =C2=A0=C2=A0 Precluding network based protection for endpoints is not c= onsistent > =C2=A0=C2=A0 with the imperative to treat mass surveillance as an attac= k.=C2=A0 Mass > =C2=A0=C2=A0 hacking of endpoints is surveillance by another means. >=20 > Equating the number of compromised hosts with the number of visible hos= ts > to a pervasive monitoring agent makes no sense. But more importantly, > you state that pervasive monitoring should make way for network based > monitoring (or rather, "voluntary" host based extrusion of privacy to > (un)trusted third parties). This obvious comes with a huge problem > of designing an "opt-in" protocol that a nation state can abuse to be > "never opt-out" >=20 > As much as I don't like draft-mm-wg-effect-encrypt for fear of security= > companies grasping at it for a justification of pushing back against en= d > to end encryption, if you read that document, it does a much better job= of > neutrally informing people of the issues of deplying endpoint encryptio= n > (which I prefer to call "pervasive privacy"). If you remove that conten= t > from your document, nothing much is left. >=20 > I know from your presentations and conversations that you believe hosts= > securly connecting to a proxy is not good enough to solve the issues yo= u > deem exist. Your document should instead focus on that. Which current > IETF protocols are in use to achieve endhost security, why are these no= > longer feasable, what changes do you need to make this work. You don't > need to present statistics about security failures. >=20 > So far, I am still not convinced that a SOCKS proxy or even a DNS proxy= , > connected via a VPN, is not sufficient to filter out malicious data. >=20 > Again, from your conversations and presentations (not from this documen= t) > I know you are looking at endnodes giving out private key material to > a trusted third party. Convince me why this is required from a protocol= > point of view, not a business model point of view. >=20 > The fact that your collegue's email showed leakage of such "protection"= > system by leaking https://clicktime.symantec.com/ links in response to > an ietf email does not help be gain confidence that I should change a > security protocol to facilitate the protocol modifications presented at= > the BOF. >=20 > Paul >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --eDqIGHWLbiV7NjsaqVFs5jM5Eq9QEEnSx-- --NgAvau0geWH2Ll4er4bAef09rf3wOUmPT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaMec0AAoJEC88hzaAX42iBG4H/0yJX5/rKTFBeB2eexadBhIM XjGXS+kqnyg/PQ6LyXiEqbJ8IOALD+ixCdijoczrWcg7UtkNmK1wB7t6/Z2/KWtA i9w+kAuPVnxfCE+ULN7oPSxCfgSuACLBINrXo0J7dhuQ8wwrKYMH5l8EVNQy/QeI NAayYQ1KEaty68J8Eo1CmIjOnJHf6tlpQn4O1kk9OlFM64zfeB4BD6RdVaz9luih dFiIvKCkNzEZDj0Qddn6FFPEVxWWFFnzzkNqxMcVn9t6OWvh1kFqSQgTHa2fqIr4 RBEkwMY8VEkuqfvAJ6P7cU0CEPnob5jlBVt1knMU+j43RfgwPpaQAKSYytdNNAo= =h4rX -----END PGP SIGNATURE----- --NgAvau0geWH2Ll4er4bAef09rf3wOUmPT-- From nobody Thu Dec 14 03:06:40 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8E0128656 for ; Thu, 14 Dec 2017 03:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, 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 yFuKkQhkiT7O for ; Thu, 14 Dec 2017 03:06:36 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 99CC7124B17 for ; Thu, 14 Dec 2017 03:06:35 -0800 (PST) Received: from [192.168.91.212] ([80.92.123.79]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LiTm8-1f24U11tqW-00cdfU for ; Thu, 14 Dec 2017 12:06:33 +0100 To: saag From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5169ba26-1871-4ffb-c278-aa3ebdb31144@gmx.net> Date: Thu, 14 Dec 2017 12:06:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:dTIAxfLGwflnD+2wVKd3Dj5wwLMj48zlhq08Np9k2UAiVjoDWFf PMyhkA/OZnwdHELO1GSALYwSSIlXLK8HWTcj8WvQSAuGI9XTkJ3TgVIuTuK2rZX3u6qApHJ QaPjLAzrtzyq1wdWgHrgZo+RWlGIFQbIoiB52xFWCqUlExSj6kroruHSRjjBD9vV+kNImV4 aRJec3PM7ijpDSVYIOQvA== X-UI-Out-Filterresults: notjunk:1;V01:K0:R4ODWRO7xik=:+KlhaHgLWR6cXmofGcjF0A 52QF0W/vsoMQRdxLCPTyteB8Kvlwp+wbTjyg6OLKEpg7z3XEYOynN0ykpsdBWddCk7SrwcRll UAadyP1TfYP37a++Pu7KugPtMnJTOvjMXJVCCjKoDnoZLZn7faVDOpEs3NaFWQb9dt/oJgioi TnelQs6NILq6KWyqLtg9aUIpIxrm9KAu06jGeYIZuVcrV3wrd6GB4jxrApPhoeuLLCMNi4Q8T IY30wuoajKIDDzXLZg94qW9DMy/rQaq4Kqet8+vB0Uq1lCfiNG6N5LQBY4CRK8C6I9JmR8RS9 9AJOiELU3165uwKgacM+lthhjWmkeNkWJUqHJ7oZwFKh1aVUgg2GAokiHqy8y2O3EtaaxPGC8 bnkUAdY/6IpIrSU227tim1Rt7U/OyLo8y32bQOylR2HlViLEfiaLHXewhyShMd7LHTabBRtCK sRgjeaCW+7pnh6tnZsNiYoRuSFTI9ra8pIdEXjBKMl03JPb0H57TJje5X8GeS9R4FMVK5xS6h fqXn/vYQucU/t+PejHqND47r9JE0OaRJjYsdJ54fq1SoA+XDaDW4Hrj3RO3utjf7dOr5GXL0m bl7uCQeU4PpPWAa+RQbmcJph3Yqm1wE8HNdWoHbjDuPhl+ZBdwYEvxEeKOlVPyDZnFHBucvx2 VsXMNbG9AfGO/mr93Xzi2KldgIkLKm6gGJvb/YJIGZdu8KeX1Tv4q0oAJXoiEQxXviXjgjGnz Ze+XKrBvdgNPn5WSKxmGcAKBj+nk971tBfDKm6wXAWY0UyxLvltbAqRphecjZ7odSrg7dJams yuvA0a8P9igQnUJIYUfcmWeYZXJQMOXglaI5tsYp1WLuHIHHbA= Archived-At: Subject: [saag] 3rd OAuth Security Workshop (OSW 2018) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 11:06:38 -0000 Hi all, Several of us from the OAuth working group are again organizing a workshop in the week before the London IETF meeting. Here is the webpage: https://st.fbk.eu/osw2018 Why should you care? We organized the first OAuth security workshop in 2015 when a group of researchers from Trier / Germany used formal methods to analyse OAuth. None of us working on the OAuth spec had the time and expertise to use formal methods and we noticed the opportunity to work with this research community to help us build better specifications. At all subsequent OAuth security workshops, including the last one in Zurich - https://zisc.ethz.ch/oauth-security-workshop-2017/, one part of the meeting was dedicated to the discussion of formal methods for protocol analysis. This workshop is therefore a way to bridge the gap between research and standardization with OAuth as an example. The discussed tools are applicable to other IETF security protocols as well. The same is true for the gained experience. It would be great to see some of you also attend the workshop and contribute! The deadline for papers and tutorials is January 19, 2018. If you are working on topics that could help make standardization of OAuth (or other security protocols) better please drop us/me a note. Ciao Hannes Call for Position Papers and Tutorials ============================ Third OAuth Security Workshop (OSW 2018) Fondazione Bruno Kessler Trento, Italy March 14-16, 2018 Workshop website: https://st.fbk.eu/osw2018 == About OSW 2018 == The OAuth Security Workshop (OSW) aim is to improve the security of OAuth and related Internet protocols by a direct exchange of views between academic researchers, IETF OAuth Working Group members and industry. The workshop is hosted by the Security and Trust research unit of the Bruno Kessler Foundation (FBK). While the standardization process of OAuth ensures extensive reviews (both security and non-security related), further analysis by security experts from academia and industry is essential to ensure high quality specifications. Contributions to this workshop can help to improve the security of the Web and the Internet. == Scope and Topics == We seek position papers related to OAuth, OpenID Connect, and other technologies using OAuth under the hood. Contributions regarding technologies that are used in OAuth, such as JOSE, or impact the security of OAuth, such as Web technology, are also welcome. Areas of interest where OAuth can be used as enabler of innovative scenarios include: - IoT, SmartCities and Industry 4.0. - Mobile and Strong authentication. - Federated Identity. - Privacy-enhancing technologies. == Important Dates == - Position paper and Tutorial submission deadline: January 19, 2018 (AoE, UTC-12). - Author notification: February 5, 2018 - Workshop: Wed, March 14, 2018 (half-day), Thu, March 15, 2018 (full-day), and Fri, March 16, 2018 (half day) == Submissions == We solicit position papers that highlight challenges and lesson-learned from OAuth-based work. As all papers and presentations will be shared online without formal proceedings, we accept different kinds of submissions: from original contributions to already published or preliminary works. Submissions must be in PDF format and should feature reasonable margins and formatting. There is no page limit, but the submission should be brief (ideally not more than 3-5 pages). Submissions should not be anonymized. Authors of accepted papers will have the option to revise their papers before they are put online. One of the authors of the accepted position paper is expected to present the paper at the workshop. The workshop will host a half-day (March 14, 2018) tutorial program. Each tutorial proposal should concisely describe the content and objectives of the tutorial, and include: - title - abstract - outline of the tutorial content - intended audience, including possible assumed background of attendees - name, affiliation, email address, and brief biography of the speaker(s) - duration: 1 hour or 2 hours Tutorial proposals should be submitted as a PDF file. Submissions should be distinguished by the prefix “Tutorial:†in the title. Submission Website: https://easychair.org/conferences/?conf=osw2018 == IPR Policy == The workshop will have no expectation of IPR disclosure or licensing related to its submissions. Authors are responsible for obtaining appropriate publication clearances. == Workshop Chair == - Silvio Ranise (Security & Trust, Fondazione Bruno Kessler) == Program Committee == Chairs - Roberto Carbone (Security & Trust, Fondazione Bruno Kessler) - Hannes Tschofenig (IETF OAuth Working Group Co-Chair) Members - Michael Jones (Microsoft) - Ralf Kuesters (University of Stuttgart) - Torsten Lodderstedt (YES Europe AG) - Chris Mitchell (Royal Holloway, University of London) - Anthony Nadalin (Microsoft) - Nat Sakimura (Nomura Research Institute) - Antonio Sanso (Adobe) - Ralf Sasse (ETH Zurich) - Joerg Schwenk (Ruhr-Universität Bochum) - Giada Sciarretta (Security & Trust, Fondazione Bruno Kessler and Univ. of Trento) == Conference site and contacts == For more detailed information please refer to the workshop web site: https://st.fbk.eu/osw2018 If you have any questions on OSW18, please contact carbone [at] fbk [dot] eu, giada.sciarretta [at] fbk [dot] eu From nobody Thu Dec 14 14:58:56 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2768B127005; Thu, 14 Dec 2017 14:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=symc.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 Qcg_Qe9TaMca; Thu, 14 Dec 2017 14:58:47 -0800 (PST) Received: from asbsmtoutape01.symantec.com (asbsmtoutape01.symantec.com [155.64.138.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 7E0CA1205F0; Thu, 14 Dec 2017 14:58:47 -0800 (PST) Received: from asbsmtmtaapi01.symc.symantec.com (asb1-f5-symc-ext-prd-snat5.net.symantec.com [10.90.75.5]) by asbsmtoutape01.symantec.com (Symantec Messaging Gateway) with SMTP id 8C.25.35258.622033A5; Thu, 14 Dec 2017 22:58:46 +0000 (GMT) X-AuditID: 0a5af819-80ab69c0000089ba-b7-5a3302262d9b Received: from tus3xchcaspin01.SYMC.SYMANTEC.COM (asb1-f5-symc-ext-prd-snat10.net.symantec.com [10.90.75.10]) by asbsmtmtaapi01.symc.symantec.com (Symantec Messaging Gateway) with SMTP id 3C.3D.04260.622033A5; Thu, 14 Dec 2017 22:58:46 +0000 (GMT) Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) by tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 14 Dec 2017 14:58:45 -0800 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.128.8) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Thu, 14 Dec 2017 14:58:45 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DOvdeV3XLpZbiZyw2a+h3mESzTAnvrfzBTy3pkg/4WU=; b=gKkC+fARodLuUJHqtleqE4c8kn+72EKY18jyPRKqwS4KBaCLTGrc+vEE/eXAJS0NXsiGi+TUmdJA+F8plshP+7MXxTnws/J092v5/1UHIhOuUiQJkLAOL9EjsbwvZ+NzxIlRMtkiHdZu6LAzfftfJiIZK6QG2JtBDXL2jRwkzOk= Received: from MWHPR16MB1488.namprd16.prod.outlook.com (10.175.4.146) by MWHPR16MB1488.namprd16.prod.outlook.com (10.175.4.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Thu, 14 Dec 2017 22:58:43 +0000 Received: from MWHPR16MB1488.namprd16.prod.outlook.com ([10.175.4.146]) by MWHPR16MB1488.namprd16.prod.outlook.com ([10.175.4.146]) with mapi id 15.20.0302.017; Thu, 14 Dec 2017 22:58:42 +0000 From: Brian Witten To: "patient@ietf.org" , "saag@ietf.org" Thread-Topic: Internet Draft posted as requested - Thread-Index: AQHTdG3hrR7/CZZMykmDXlV3KMVAN6NDcJ4G Date: Thu, 14 Dec 2017 22:58:41 +0000 Message-ID: References: , , , , , , , In-Reply-To: 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=brian_witten@symantec.com; x-originating-ip: [2605:e000:9394:6500:a5ed:2f5c:12b1:afaa] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR16MB1488; 6:mfyGewS3uz2nqLR2vWp2NtUB5KrlcpA8YiiteW4M7Th/WKGz5iRb2285QC9Kiq1VzPgFVCRO8w0yrrGxH93DUNm1YXTX6V+OJdt4ih3QrL0fR2D/YAlYbQxRlH1MliV//JzqrHVFj/q+NfcSEUdofCF67Q3qH4og0FbDCHlaHgqhIMk2KNseBoYrksajWJi2EmeCroqJvmFweYczIYhjwU/FGWjEDWbvXNTUPiuaRX/NImV7bLuZQQ0eUczzQdcmERb3+7o3K0DGmh2gJ0fQL4EX2JAqObYCshIjdPKkh3DlTTvcfh0UkTWdZ2F8wI6aYsfJrlsF50jVhzq0EZLaATuL7qf8QUBFtAzlFxPWctI=; 5:rbw/2+MYcViPJsPsJC2BjUpaWqAb0BLrSBUhoqmvguJf+wCGVJp2UvP7zmyN/VDb7mP+Ui0sD2XPmwGycpWRkwtmc1mAVLH4ZoXSVJYi/ukEtLU5vQwzGyOE96r4IweFKzZdQY+95+OD4riaJuVARxSnbN0Wg2OLzb23UOr/E9o=; 24:qbQfFy1uuF2Dvo9fthh9CjznRJDj15EBjuznJ8oLWAf7J2mFBf26+SbceIaJAbrxzP1FU80Okx/zKdDm+kh8LlZSTwzA+BdJ1dchKpZrbns=; 7:nR8YQyhFOdU2tB9lJfGFA0gr2X0JQOoUX9RC6ibndwqPbZTVFeqAikhe0dy2ESsPWOLoVTQx8zz5LxHpkoh7+wq5TkacGUriUzhMHA2ZzDULn9CqIfNhzfVdkX8OVbOvKYRzj21ngqi3N0zLDnwvKeSb1fmGPHXuXezYoazXAvtH9LoJGbqDG0hZhG4UF1Ab/cBU0bcRS4SnHpreGH6dc6nC6FellZS1PBdckDsCbIMqDoL9+LdCBGYqTVea/9Jt x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e306fdfc-869c-49fb-2efd-08d5434638cf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:MWHPR16MB1488; x-ms-traffictypediagnostic: MWHPR16MB1488: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(192374486261705)(94390896966249)(94626863071701); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231023)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148)(201708071742011); SRVR:MWHPR16MB1488; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR16MB1488; x-forefront-prvs: 05214FD68E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(346002)(376002)(53754006)(51414003)(189003)(199004)(10290500003)(6512007)(9686003)(3280700002)(229853002)(68736007)(450100002)(6246003)(478600001)(6436002)(6116002)(102836003)(77096006)(6486002)(81166006)(105586002)(8936002)(33656002)(1600100001)(3660700001)(86362001)(25786009)(6306002)(8676002)(106356001)(81156014)(53936002)(2906002)(5660300001)(316002)(93886005)(2900100001)(2501003)(110136005)(15974865002)(99286004)(7736002)(97736004)(76176011)(966005)(59450400001)(74316002)(6506007)(2950100002)(53546011)(14454004)(305945005)(9010500006); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR16MB1488; H:MWHPR16MB1488.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: symantec.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e306fdfc-869c-49fb-2efd-08d5434638cf X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2017 22:58:41.4385 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR16MB1488 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleLIzCtJLcpLzFFi42LhivJm1VVjMo4yaFsibfHygLHFlP5OJgcm jyVLfjIFMEZx2aSk5mSWpRbp2yVwZTQ1/WYtuBJccerWC9YGxq/OXYycHBICJhKNC36zdzFy cQgJfGSUODTrAksXIwdY4tFfd4j4T0aJmbOnsUE4Rxkl/n7vgnJeMEpMfLaSCcRhEehklph/ 4Q0jRGYKk8TEvy+ZIJwjjBK3Oqaxg2xkE9CTOPr3DiuILSLgJbHywlZmEFtYwFBi19omJoi4 kcTn56vZQQ4BsR/eUQUJswioSnzauBaslVcgRuLspUaoZZNZJTY0HmIFqecUiJXYcVEXpIZR QEzi+6k1YCOZBcQlbj2ZzwTxtIDEkj3nmSFsUYmXj/+xQtTHSJxa+woqbi3RdvcEVL2sxKX5 3YwQ9iF2iaY+NQhbT2LrxLdQcV+JyztOgv0rIbCEUWLHgdNsEAktieVNU9gggZotsaMvDSJc A3RmC9MERqNZSM6DsA0k3p+bzwxha0ssW/gazOYVEJQ4OfMJywJGllWMConFScW5JfmlJYkF qQaGesWVuckgIhGYPJL1kvNzNzGCE8gPyR2MR074HGIU4GBU4uHt2G4UJcSaWAZUeYhRgoNZ SYT3SitQiDclsbIqtSg/vqg0J7X4EKM0B4uSOO+kb2pRQgLpiSWp2ampBalFMFkmDk6pBsYV lifZV52+Kvvh1A3BiAc13VXH9WXWlGxtKvEPEHiRIX1qz8mlh/me9Qs5+/obp/u11j2P+tw2 rVaLe0nmsc11x0z8dc9PrHytu+pHQELZP4Pb1rczts5/X7OqW+Pdy5y7pxI1j7py7+bnmb2q /p3p7Ys/b1xb/OsLo938jnzXnPV2MVk7j5orsRRnJBpqMRcVJwIAo3BLyBwDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsXCFeXNpavGZBxlcOSmuMXLA8YWU/o7mRyY PJYs+ckUwBjFZZOSmpNZllqkb5fAldHU9Ju14EpwxalbL1gbGL86dzFycEgImEg8+uvexcjF ISTwk1Fi5uxpbBDOUUaJv9+7oJwXjBITn61kAnFYBDqZJeZfeMMIkZnCJDHx70smCOcIo8St jmnsXYycHGwCehJH/95hBbFFBLwkVl7YygxiCwsYSuxa28QEETeS+Px8NTvIISD2wzuqIGEW AVWJTxvXgrXyCsRInL3UCLVsMqvEhsZDrCD1nAKxEjsu6oLUMAqISXw/tQZsJLOAuMStJ/PB bAkBAYkle84zQ9iiEi8f/2OFqI+ROLX2FVTcWqLt7gmoelmJS/O7GSHsQ+wSTX1qELaexNaJ b6HivhKXd5wE+1dCYAmjxI4Dp9kgEloSy5umsEECNVtiR18aRLgG6MwWqPoFzBLrn82GqpeR uLNwH/MERr1ZSO6GsA0k3p+bzwxha0ssW/gazOYVEJQ4OfMJywJGllWMConFScW5JbkliYkF mQaGesWVuckgIhGYPJL1kvNzNzGCE8hvsR2MB/74HGIU4GBU4uF90GwUJcSaWAZUeYhRmoNF SZz3sQZTlJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGw9MqFOeEhX4S9C2f+WOHW8Clfz13 Be3evDw3P6Xu0/0fLs4Z1eU1s6aXdtzYtfP3ds4/Uz4/WXRz7TuTz4UFT9+Jzl8243vzojzG xxzRy2QEaiv1DKe5Lfyg9j5QS0Dctmfz73fXm3aK3/2iFiTOMLsmQWPW1CX/Yk85sHJvMz11 Y/2JskevlZVYijMSDbWYi4oTASeZ0WYBAwAA X-CFilter-Loop: ASB01 Archived-At: Subject: Re: [saag] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 22:58:50 -0000 Thank you everyone for your comments! The request in Singapore for an Internet Draft seemed focused on an ask for= data, so I tried to keep the v00 focused on the data, and concise to be ea= sily read quickly, and I thought that I might be going onto a limb beginnin= g to present some of the logic, but it seems like many are hungry for more = of the logic (or "at least some logic" as they might say) so I=92ll present= more of the logic.=A0 Of course, much of the logic was presented in the ne= ar 40 slides sent earlier and roughly 5 pages of Q&A, but I agree with the = merits of centralizing all of the logic in an Internet Draft, so I=92ll aim= to do that in the v01, and, perhaps more importantly, I also hear clearly = some of the concerns on how the logic was organized (or unorganized or diso= rganized as some might say) in Singapore, so I=92ll try to be more clearly = structured both here and in more detail in the v01.=A0 I=92ll comment on th= e solutioning further below, but since so many seem so hungry for the logic= , I=92ll try present it relatively concisely here so that discussion here c= an best shape the v01 which will pull from the list, the slldes, and more. =A0 The logic, in the short form of roughly five points would be: ** (1) ** Endpoints have vulnerabilities.=A0 ( unfortunately lots of them.= =A0 For this part I believe there is overwhelming evidence, but please LMK = if you disagree. ) ** (2) ** These vulnerabilities are often difficult (sometimes nearly impos= sible) for device owners, users, etc, to mitigate =93in=94 these endpoints.= ( this is true today for countless devices, and increasingly true for incr= easingly closed devices, particularly in IOT and mobile. ) ** (3) ** For that reason, those endpoint owners/users/etc often need to pu= t some =93thing=94 in the network to mitigate those endpoint vulnerabilitie= s. ** (4) ** For that to be effective (against attacks in encrypted traffic), = that =93thing=94 needs keys to inspect the encrypted traffic.=A0 ( This can= be done any of many ways, as it=92s done today. ) ** (5) ** Where that=92s done today, it can be done much more safely, there= fore we should spec standards for how to do it more safely.=A0 ( Lots of id= eas have been published in research, and I include some details on that fur= ther below, but maturing the right ones and baking them into a standard is = of course typically a =93bigger group=94 effort. ) =A0 In that framework, I=92d love to know which of these 5 points above (if any= ) are agreeable to you, and which specifically you believe are either simpl= y dead wrong or the right-best focus of constructive discussion.=A0 For som= e it seems that point (3) above is the most controversial, but others are a= lready asking the details of (5) which is where the slides focused, but the= v01 will of course cover both in depth, and, as promised, I'll give some p= oints on (5) below. =A0 On the solutioning, as mentioned at the side-meeting, lots of solutions hav= e been proposed in research communities, but I believe it=92s important to = get aligned on the problems we=92re solving as a community before picking a= solution.=A0 As mentioned at the side-meeting, solutions proposed by the r= esearch community include Stickler by Boneh & team at Stanford, plus the un= fortunately named mcTLS and mbTLS efforts, and more, but I believe it=92s i= mportant to get aligned on the problems we=92re solving as a community befo= re picking a solution.=A0 Once we=92re aligned on (1) through (5) above the= n it makes more sense to get into the specific problems with (4) which (5) = tries to address, including (a) retaining end-to-end integrity, (b) giving = endpoints more precise control over when, where, and how such protection is= delivered from the network, in strong contrast today=92s all-or-nothing ju= st-install-a-root approach. =A0 To address some of the other important questions and concerns raised over t= he past day=85 =A0 Re, =93does not specify a new protocol,=94 many of the potential/candidate = protocols were mentioned at the side-meeting, in the notes of the side-meet= ing, in the slides presented at the side-meeting, and in the email to annou= nce the side-meeting, but I=92m happy to add them to the v01 to keep everyt= hing together in a single Internet Draft.=A0 For context, as Stephen pointe= d out, his ask was not for an Internet Draft of a protocol, but for the dat= a (and logic) of why it might help to spec a new and/or additional protocol= . Re, =93It does not specify a concrete problem (use cases),=94 again thes= e were mentioned at the side-meeting, in the notes of the side-meeting, in = the slides presented at the side-meeting, and in the email to announce the = side-meeting, but I=92m happy to add them to the v01 to keep everything tog= ether in a single Internet Draft. Re, =93It does not specify any kind of architecture,=94 as above, covered b= efore, but I=92m happy to add it to the v01 of an Internet Draft to get eve= rything together in a single Internet Draft.=A0 These seem like constructiv= e requests, even if the material was covered elsewhere already.=A0 Thank Yo= u Again! Similarly, if anything is missing from the notes, I=92m eager to be sure th= is discussion fairly and deeply captures _all_ views, particularly opposing= views, so where there are gaps in the 7 pages of notes we took, those gaps= are absolutely not intentional.=A0 I=92m eager to see any omissions rectif= ied, so please send any additions, corrections, etc, either to this list or= to me personally.=A0 Either way, I=92m eager to be sure everyone sees all = views and hears all concerns and that all of those concerns are included an= d/or addressed somehow in a v01. Re, =93pervasive monitoring should make way for network based monitoring,= =94 I wasn=92t trying to say that and in fact, from the slides you can clea= rly tell that PATIENT is aiming to more completely block pervasive monitori= ng.=A0 Crypto helps block pervasive monitoring by listeners in the network.= =A0 Pervasive monitoring is also possible by hacking all the endpoints, and= as presented in the side-meeting, we have ample evidence of nation-states = attempting to do this. PATIENT aims to make safer prevention of the latter= approach to pervasive monitoring. Re, =93draft-mm-wg-effect-encrypt,=94 you=92re absolutely right, and I=92ll= cite that work in the v01 for precisely those reasons.=A0 In fact, my aim = is to (eventually, after we get aligned on scope, etc,) design a protocol t= hat allows network security appliances to yet more safely work hand-in-hand= with pervasive encryption.=A0 I=92m not trying to push back against pervas= ive encryption at all.=A0 I suspect I might have to keep repeating myself o= n that until people believe it? Re, =93So far, I am still not convinced that a SOCKS proxy =85 connected vi= a a VPN, is not sufficient to filter out malicious data.=94=A0 I believe co= nnecting proxies via VPN is a great way to help block malicious data.=A0 I= =92m also not debating the type of proxy to be used.=A0 As you know, and as= the slides say, and as the v01 will say, I=92m saying that when proxies ch= ange stuff, it would help for the endpoint to know which proxy changed what= where.=A0 Stickler helps with that.=A0 I think it also helps for endpoints= to know more about the proxy on the other side of the VPN, but I=92d be ha= ppy for that to be in-scope or out-of-scope for a first WG on this.=A0Re, = =93from your conversations and presentations (not from this document),=94 y= ou raise a very fair point.=A0 Although the original ask was not to put =93= everything=94 into a single Internet Draft, putting =93everything=94 into a= single Internet Draft seems like a great idea, so I=92ll aim to do that wi= th v01. Regarding =93months later,=94 this seems to be at least a mild exaggeration= as the meeting was one month ago tomorrow. Regarding =93all in a non-verifiable manner,=94 I thought counting phishing= websites would be easy enough for anyone who really wanted to test a hypot= hesis instead of standing on rhetoric.=A0 PhishLabs seemed to manage that O= K.=A0 I haven=92t counted all of the https sites in PhishTank yet, but at f= irst glance the fraction seems substantial.=A0 Admittedly, not all of the d= ata is directly verifiable, nor did I ever promised that _all_ of the data = would be directly verifiable, but counting phishing sites seemed easy enoug= h.=A0 Please LMK if I=92m wrong on that point.=A0 The other sources seem to= corroborate each other. Regarding posting to the =93Threat Response Blog,=94 we=92ll consider that,= but the ask to us was to share more data here so we brought the data here = as requested. As a side comment, I=92d also note the use of pejorative phrasing.=A0 =93ar= gues for the mitm attacks on https,=94 =85 It seems that you=92re calling = =93network based blocking of malicious webpages=94 an =93attack=94 when the= blocking is actually blocking the server's _attack_ against the client.=A0= Where I choose to have a network proxy protect from evil on the net, I don= =92t consider that proxy to be attacking me.=A0 I consider that proxy to be= protecting me, and many organizations manage keys accordingly.=A0 We see m= ore and more people needing network help in protecting themselves from such= attacks, as laid out in (1) through (5) above.=A0 I look forward to your f= eedback there. =A0 Thank you again - =20 Cheers, Brian From: Brian Witten Sent: Wednesday, December 13, 2017 3:55 PM To: patient@ietf.org Subject: Internet Draft posted as requested - =A0=20 Hi Everyone, With the Wired article last week ( https://www.wired.com/story/phishing-sc= hemes-use-encrypted-sites-to-seem-legit/ ) ... I wanted to get the Internet= Draft ( https://www.ietf.org/id/draft-witten-protectingendpoints-00.txt ) = posted publicly for others to comment sooner rather than later.=A0 Of cours= e, feel free to comment here on the list or just me comments 1:1 at bwitte= n@symantec.com.=A0 Thank You Either Way! https://media.wired.com/photos/5a25b22aa587381053b48abb/191:100/pass/Phish= ingHTTPs-FeatureArt.jpg=20 Phishing Schemes Are Using Encrypted Sites to Seem Legit www.wired.com A green padlock might make it seem like a site is secure, but increasingly = phishers are using it to lure victims into giving up sensitive info. Looking Forward, Brian =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = = From nobody Thu Dec 14 15:11:04 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8891C127005; Thu, 14 Dec 2017 15:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 MvBrW9079KoI; Thu, 14 Dec 2017 15:11:01 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 7C212126CBF; Thu, 14 Dec 2017 15:11:01 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yyTnY3szQz1Kh; Fri, 15 Dec 2017 00:10:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1513293057; bh=92jAJLB1FNJrg8L64C3ef1ugUQienllrtWtecKiFe9U=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=PD7gVBTQvEIMxU4bL+rOCfCNslAl2hAXFb+8yWfHyVt6HRp3EDyy3naaQD/NALEYJ 8+PxuXKEIMGQlzBrfLLvOJlcV5sgeJIvlRURCEV1ULRKr4jgUGQ3D4gCoS1wk/ej1N OGRLJloMk4Rr3YzI6psrl/zPPyC2tgAaSv4Hona4= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id w0uB7r-ZGOBQ; Fri, 15 Dec 2017 00:10:55 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 15 Dec 2017 00:10:54 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id F058F70A3FD; Thu, 14 Dec 2017 18:10:53 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca F058F70A3FD Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D78D243A0D40; Thu, 14 Dec 2017 18:10:53 -0500 (EST) Date: Thu, 14 Dec 2017 18:10:53 -0500 (EST) From: Paul Wouters To: Brian Witten cc: "patient@ietf.org" , "saag@ietf.org" In-Reply-To: Message-ID: References: , , , , , , , User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [saag] [Patient] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 23:11:03 -0000 On Thu, 14 Dec 2017, Brian Witten wrote: > As a side comment, I’d also note the use of pejorative phrasing.  “argues for the mitm attacks on https,” … It seems that you’re calling “network based blocking of malicious webpages” an “attack” when the blocking is actually blocking the server's _attack_ against the client.  Where I choose to have a network proxy protect from evil on the net, I don’t consider that proxy to be attacking me.  I consider that proxy to be protecting me, and many organizations manage keys accordingly.  We see more and more people needing network help in protecting themselves from such attacks, as laid out in (1) through (5) above.  I look forward to your feedback there. Some call it that because you are actively trying to circumvent protection that https offers. If you let the client decrypt the data and then sent that data (encrypted) to the network agent, no one would call it mitm attack. But your proposal is to give private (session) keys from endpoint to the network agent, basically giving it the full power to impersonate the endpoint. That is a dangerous and needlessly insecure compromise. Similarly, an email message can be received over TLS, and then forwarded to the network agent for scanning without giving the network agent the key material to sit in between network agent and remote mail server. Paul From nobody Thu Dec 14 15:16:48 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D7C129431; Thu, 14 Dec 2017 15:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=symc.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 C9WyaxAKV8eP; Thu, 14 Dec 2017 15:16:32 -0800 (PST) Received: from tussmtoutape01.symantec.com (Tussmtoutape01.symantec.com [155.64.38.231]) (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 7D9E6127369; Thu, 14 Dec 2017 15:16:32 -0800 (PST) Received: from tussmtmtaapi02.symc.symantec.com (tus3-f5-symc-ext-prd-snat2.net.symantec.com [10.44.130.2]) by tussmtoutape01.symantec.com (Symantec Messaging Gateway) with SMTP id C0.64.60992.F46033A5; Thu, 14 Dec 2017 23:16:31 +0000 (GMT) X-AuditID: 0a2c7e31-3f8e99c00000ee40-8a-5a33064f2873 Received: from tus3xchcaspin01.SYMC.SYMANTEC.COM (tus3-f5-symc-ext-prd-snat3.net.symantec.com [10.44.130.3]) by tussmtmtaapi02.symc.symantec.com (Symantec Messaging Gateway) with SMTP id BF.84.04468.F46033A5; Thu, 14 Dec 2017 23:16:31 +0000 (GMT) Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) by tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 14 Dec 2017 15:16:31 -0800 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.128.8) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Thu, 14 Dec 2017 15:16:31 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8DSfLBhCdVT3Lrik8ihsNfaNFBNSNJTGJZHvODvJoBc=; b=mWuldMcYKz6dwodOkQ0lniWajg7gSh34MAYVe7zL1GGz9365qpwNtMUiLvLECGNvI0Fvrk9GbEa5V5Y6a6E825ba09KFIUbICFLQpIZx7k523YE4yoSVtWBeOrHNmF28QNcT9lpvZM/n+28gRU2qtRX+BTFRwNrmqD9R6eTNJ7U= Received: from MWHPR16MB1488.namprd16.prod.outlook.com (10.175.4.146) by MWHPR16MB1487.namprd16.prod.outlook.com (10.175.4.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Thu, 14 Dec 2017 23:16:29 +0000 Received: from MWHPR16MB1488.namprd16.prod.outlook.com ([10.175.4.146]) by MWHPR16MB1488.namprd16.prod.outlook.com ([10.175.4.146]) with mapi id 15.20.0302.017; Thu, 14 Dec 2017 23:16:29 +0000 From: Brian Witten To: Paul Wouters CC: "patient@ietf.org" , "saag@ietf.org" Thread-Topic: [EXT] Re: [Patient] Internet Draft posted as requested - Thread-Index: AQHTdG3hrR7/CZZMykmDXlV3KMVAN6NDcJ4GgAAIGoCAAAB1DA== Date: Thu, 14 Dec 2017 23:16:29 +0000 Message-ID: References: , , , , , , , , In-Reply-To: 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=brian_witten@symantec.com; x-originating-ip: [2605:e000:9394:6500:a5ed:2f5c:12b1:afaa] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR16MB1487; 6:m67/82sUplg31I83yyFErdzCdjxNhLhLoqiVY4Vk/i35Kt7fa1Y07xwnUK3iY6x9Zqay5r64Mn9gWwa4pHrc8P+6ijE+Wj+iJSX6kCvhka2skyoyrSx6hmap3PTdqX1F/21am23Xs03XcaXNCJRwJuXQcc/emfBKgBOnOt7gIompThc9VHWiOdJHDu0vrLnRKdIDKQxWT1JgP84NlzjXoxndS7JHSeSqMjw4sCwyxf+Jt+bBA0dbWMUf+BJ5C5ODfUGuy6CPzO9Bj9l/My4VLHDrFINTYITXs5oae/JtNrFsPVvgO49fYCi2iFEkiTqVSfP0MGxIlJ0OwZf+OEhttQQ6/V7B1QVeiInzrY/rEpA=; 5:F59il+/lLJ/zUY/1qf/Ntvn5m/FB50/FFyJBzYjJVvjOE2Bz0u1ScyA7h9xvaVfAmpgbFTQWull2l9Ut/pxTmk2Zk3icc1pbuJX4RlgiSSELHr4bUWDaZraxKXsww9BOoJeymukHt6rT0rV+BaSR6KTGHAUmVyhlaFZe6USma3Q=; 24:JtBZfQ8uXgjAE5rXiJbiYnlQZZb+AyACMv6n9RASwzBJZyeKvOeSA5wMimCk/RB+aY+3Xqc33LFU2hyRPvDkTwOXYld3vseDYFtu5RxhbZU=; 7:29ib88cbrHmMx5fdBm9eBwa89eKKFAju+4L6z4ZLt+3UFHa7EXTZnjyQmICPRqUfWaFPBFPVndU4JUNV2HZvQVRocbcH8aWxByN5WRBC7gyN9elmOcx5eGYpbUsZlIsqsvQ1TC1laUkPmYV+A0yqXyUSK48x700uqlfiHUGBbb63SQe+3BjP/D5/y3I5VihaHb3MoJxCsKUn5p1StD7533bWRhZFgpxEu3/BJrTvbzBwEz1JDBf1utqI5jnJ/0o8 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 72fe1888-f116-46fa-3c04-08d54348b4e0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:MWHPR16MB1487; x-ms-traffictypediagnostic: MWHPR16MB1487: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231023)(93006095)(93001095)(6041248)(20161123558100)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(6072148)(201708071742011); SRVR:MWHPR16MB1487; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR16MB1487; x-forefront-prvs: 05214FD68E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(39860400002)(376002)(346002)(51414003)(24454002)(43784003)(189003)(199004)(8936002)(6506007)(81156014)(68736007)(8676002)(7736002)(81166006)(74316002)(53546011)(76176011)(3280700002)(2906002)(86362001)(478600001)(59450400001)(25786009)(10290500003)(99286004)(93886005)(7696005)(14454004)(316002)(54906003)(3660700001)(105586002)(106356001)(6246003)(97736004)(33656002)(54896002)(9686003)(55016002)(4326008)(77096006)(6436002)(229853002)(2900100001)(102836003)(6116002)(561944003)(19627405001)(5660300001)(6606003)(6916009)(53936002)(2950100002)(9010500006); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR16MB1487; H:MWHPR16MB1488.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: symantec.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR16MB148859D8FC007D9B9D5005E6930A0MWHPR16MB1488namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 72fe1888-f116-46fa-3c04-08d54348b4e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2017 23:16:29.2062 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR16MB1487 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJKsWRmVeSWpSXmKPExsXCpdPEpOvPZhxlMGeFvsXLA8YW729dYrKY 0t/J5MDssWTJTyaP7/OYApiiuGxSUnMyy1KL9O0SuDL2/ljHXvDUuOLXrbfMDYyvtLsYOTkk BEwkNs34xdzFyMUhJPCJUeLihb+sMIktT3rYIBI/GCWWNLezQzhHGSWu3XsDViUk8IJR4snq RJAEi0Ans8SUa7ugWqYwSRw+fQvKOcIo8fzWfmaQFjYBPYmjf++AtYsIKEpMOvOIBcRmFvCS +DT3OZgtLOAqcWJjGxtEjZvE8t0XoeqdJH4sb2cEsVkEVCVmz9nCBGLzCsRI7OxbywixbAOb xMWV58ESnAKOEt1/poEtZhQQk/h+ag0TxDJxiVtP5jNBfCogsWTPeWYIW1Ti5eN/rBD1MRKn 1r6CiltLtN09AVUvK3FpfjfYMgmBQ+wSD/YuZoFI6ElsnfgWKMEBZPtKLHtRBFGzhFHiVM8q dogaLYnDPduhBmVLbDg5m30Co9EsJDdB2PkS3ccnsMwCe05Q4uTMJywQcQOJ9+fmM0PY2hLL Fr6GsvUlNn45y4gsvoCRfRWjQklpcXFuSX5pSWJBqoGhXnFlbjKISAQmp2S95PzcTYzgBFVn uIPx0QafQ4wCHIxKPLyvWIyjhFgTy4AqDzFKcDArifBeaTWKEuJNSaysSi3Kjy8qzUktPsQo zcGiJM776atalJBAemJJanZqakFqEUyWiYNTqoGR1+X1jJrQYwt9RB68cGXZIP3z/rFpJds7 7QuW5pR8fLlHp+LUFqfUKIFvnzmrpynJcR9+GPxbKs2ve57OroUVWkbzdt4r2L7H5f7D/ORb jmeE5z788HGp/one6q93Pq6e+k911syUDNUjkeK6D5Iqb0/ftqlHKOqwWkn348/vHp567Wkg +fTJdCWW4oxEQy3mouJEAING3RxMAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsXCpdPErOvPZhxlsGWXpsXLA8YW729dYrKY 0t/J5MDssWTJTyaP7/OYApiiuGxSUnMyy1KL9O0SuDL2/ljHXvDUuOLXrbfMDYyvtLsYOTkk BEwktjzpYeti5OIQEvjBKLGkuZ0dwjnKKHHt3htWkCohgReMEk9WJ4IkWAQ6mSWmXNsF1TKF SeLw6VtQzhFGiee39jODtLAJ6Ekc/XsHrF1EQFFi0plHLCA2s4CXxKe5z8FsYQFXiRMb29gg atwklu++CFXvJPFjeTsjiM0ioCoxe84WJhCbVyBGYmffWkaIZRvYJC6uPA+W4BRwlOj+Mw1s MaOAmMT3U2uYIJaJS9x6Mp8J4lMBiSV7zjND2KISLx//Y4Woj5E4tfYVVNxaou3uCah6WYlL 87vBlkkIHGKXeLB3MQtEQk9i68S3QAkOINtXYtmLIoiaJYwSp3pWsUPUaEkc7tkONShbYsPJ 2ewwC1a++sAK0bCAGRjCU5knMOrNQnIshJ0v0X18AssssK8FJU7OfMICETeQeH9uPjOErS2x bOFrKFtfYuOXs4zI4gsY2VcxKpSUFhfnluSWJCYWZBoY6RVX5iaDiERgckrWS87P3cQITlDO kjsYD/3xOcQowMGoxMNr0WYUJcSaWAZUeYhRmoNFSZz3nQZTlJBAemJJanZqakFqUXxRaU5q 8SFGJg5OqQZGAZv6nX89HqRl+KSoZZ27qm4cssrFz7t7af3Kp1xz1x7edZhbhE/u4/PM+dkL M5R3PGtjmqxasN1Q7ccRnlaHZ1cq3Pbazfl9NESj+/lnlzde7z2Vd/27+7hMu/CuSOq16Msv LP6cj974TejzceONS7herPFwbH/x8O1UDeOJriw8by0ZBHk0lFiKMxINtZiLihMBoS935TED AAA= X-CFilter-Loop: TUS03 Archived-At: Subject: Re: [saag] [EXT] Re: [Patient] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 23:16:37 -0000 --_000_MWHPR16MB148859D8FC007D9B9D5005E6930A0MWHPR16MB1488namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Paul, Thanks! I'm not against true end2end client-auth. That would help the ser= ver know for sure to whom they are talking, including both an endpoint that= couldn't be impersonated, and the middlebox which the client wants helping= with security. Sending data "back" into the network just often has a too-= ugly bandwidth cost. Doing things in-flow is far better from a bandwidth p= erspective, and I'm happy to make these middleboxes (currently impersonatin= g) more explicitly accountable for their presence in the communications... I hope that helps! Thanks Again!! Brian ________________________________ From: Paul Wouters Sent: Thursday, December 14, 2017 3:10:53 PM To: Brian Witten Cc: patient@ietf.org; saag@ietf.org Subject: [EXT] Re: [Patient] Internet Draft posted as requested - On Thu, 14 Dec 2017, Brian Witten wrote: > As a side comment, I=92d also note the use of pejorative phrasing. =93ar= gues for the mitm attacks on https,=94 =85 It seems that you=92re calling = =93network based blocking of malicious webpages=94 an =93attack=94 when the= blocking is actually blocking the server's _attack_ against the client. W= here I choose to have a network proxy protect from evil on the net, I don= =92t consider that proxy to be attacking me. I consider that proxy to be p= rotecting me, and many organizations manage keys accordingly. We see more = and more people needing network help in protecting themselves from such att= acks, as laid out in (1) through (5) above. I look forward to your feedbac= k there. Some call it that because you are actively trying to circumvent protection that https offers. If you let the client decrypt the data and then sent that data (encrypted) to the network agent, no one would call it mitm attack. But your proposal is to give private (session) keys from endpoint to the network agent, basically giving it the full power to impersonate the endpoint. That is a dangerous and needlessly insecure compromise. Similarly, an email message can be received over TLS, and then forwarded to the network agent for scanning without giving the network agent the key material to sit in between network agent and remote mail server. Paul --_000_MWHPR16MB148859D8FC007D9B9D5005E6930A0MWHPR16MB1488namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Paul,


Thanks!  I'm not against tru= e end2end client-auth.  That would help the server know for sure to wh= om they are talking, including both an endpoint that couldn't be impersonat= ed, and the middlebox which the client wants helping with security.  Sending data "back" into the networ= k just often has a too-ugly bandwidth cost.  Doing things in-flow is f= ar better from a bandwidth perspective, and I'm happy to make these middleb= oxes (currently impersonating) more explicitly accountable for their presence in the communications...


I hope that helps!  Thanks A= gain!!


Brian


From: Paul Wouters <paul= @nohats.ca>
Sent: Thursday, December 14, 2017 3:10:53 PM
To: Brian Witten
Cc: patient@ietf.org; saag@ietf.org
Subject: [EXT] Re: [Patient] Internet Draft posted as requested -
 
On Thu, 14 Dec 2017, Brian Witten wrote:

> As a side comment, I=92d also note the use of pejorative phrasing.&nbs= p; =93argues for the mitm attacks on https,=94 =85 It seems that you=92re c= alling =93network based blocking of malicious webpages=94 an =93attack=94 w= hen the blocking is actually blocking the server's _attack_ against the client.  Where I choose to have a network proxy protect f= rom evil on the net, I don=92t consider that proxy to be attacking me. = ; I consider that proxy to be protecting me, and many organizations manage = keys accordingly.  We see more and more people needing network help in protecting themselves from such attacks, as laid o= ut in (1) through (5) above.  I look forward to your feedback there.
Some call it that because you are actively trying to circumvent protection<= br> that https offers.

If you let the client decrypt the data and then sent that data (encrypted)<= br> to the network agent, no one would call it mitm attack.

But your proposal is to give private (session) keys from endpoint to
the network agent, basically giving it the full power to impersonate
the endpoint. That is a dangerous and needlessly insecure compromise.

Similarly, an email message can be received over TLS, and then forwarded to the network agent for scanning without giving the network agent the
key material to sit in between network agent and remote mail server.

Paul
--_000_MWHPR16MB148859D8FC007D9B9D5005E6930A0MWHPR16MB1488namp_-- From nobody Thu Dec 14 15:24:10 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF051287A5 for ; Thu, 14 Dec 2017 15:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 lMdtRyB8FgVM for ; Thu, 14 Dec 2017 15:24:06 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC9A127369 for ; Thu, 14 Dec 2017 15:24:06 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 460E57A3309 for ; Thu, 14 Dec 2017 23:24:05 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 14 Dec 2017 18:24:04 -0500 Content-Transfer-Encoding: 7bit Reply-To: saag@ietf.org Message-Id: <217138C4-4798-42DB-95B5-260CFC84B8EC@dukhovni.org> References: To: saag@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [saag] [Patient] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 23:24:09 -0000 > On Dec 14, 2017, at 6:10 PM, Paul Wouters wrote: > > Some call it that because you are actively trying to circumvent protection > that https offers. > > If you let the client decrypt the data and then sent that data (encrypted) > to the network agent, no one would call it mitm attack. > > But your proposal is to give private (session) keys from endpoint to > the network agent, basically giving it the full power to impersonate > the endpoint. That is a dangerous and needlessly insecure compromise. > > Similarly, an email message can be received over TLS, and then forwarded > to the network agent for scanning without giving the network agent the > key material to sit in between network agent and remote mail server. Naturally, in an ideal world, endpoints would include code that can be enabled to query interoperable agent interfaces. As it stands, such capabilities are rarely present, and the only option is to insert the agent into the application protocol that *is* unavoidably supported by the end-point. For example, I'm helping a co-worker build an MiTM proxy that users can run between web sites and third-party HTTPs clients that adds Kerberos Authentication to HTTPS requests even when the application software lacks Kerberos support. So there will continue to be a variety of use-cases for terminating and SSL on agents that sit between the application client and server. -- Viktor. From nobody Fri Dec 15 09:07:48 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1CC1293D8; Fri, 15 Dec 2017 09:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=dIPKxxUK; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=mZx7AxIs 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 CAOaFQpexar5; Fri, 15 Dec 2017 09:07:42 -0800 (PST) Received: from esa3.dell-outbound.iphmx.com (esa3.dell-outbound.iphmx.com [68.232.153.94]) (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 C61471200CF; Fri, 15 Dec 2017 09:07:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1513357057; x=1544893057; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=FwZ0claBRmA8K61twj9zYExSwx9shsECqfsMnITCLF0=; b=dIPKxxUKUcmTBJ1c2UX+DqN88MosqxMT9HX1mUKe4lqUe2S6yR/sD/d6 8qh1muQeQOy2AGB3QnQbUHCIB8tHdJgJ8F6tVeTDO1V4mOsSnDsYxfqwA dUfpvEISpSBZsuzz4WHQ9vA631etZlSg2RyEczqGmf99EX71AxD4/U0IV Y=; IronPort-PHdr: =?us-ascii?q?9a23=3AHm7juh1YPAlv2czcsmDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?sesWLP3xwZ3uMQTl6Ol3ixeRBMOHs6sC07KempujcFRI2YyGvnEGfc4EfD4+ou?= =?us-ascii?q?JSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47xaFLIv3K98yMZFAnhOgpp?= =?us-ascii?q?POT1HZPZg9iq2+yo9JDffxhEiCChbb9uMR67sRjfus4KjIV4N60/0AHJonxGe+?= =?us-ascii?q?RXwWNnO1eelAvi68mz4ZBu7T1et+ou+MBcX6r6eb84TaFDAzQ9L281/szrugLd?= =?us-ascii?q?QgaJ+3ART38ZkhtMAwjC8RH6QpL8uTb0u+ZhxCWXO9D9QKsqUjq+8ahkVB7oiD?= =?us-ascii?q?8GNzEn9mHXltdwh79frB64uhBz35LYbISTOfFjfK3SYMkaSHJBUMhPSiJBHo2y?= =?us-ascii?q?YYgBD+UDPOZXs4bzqFQVoBuiHAmhAP/jxiNUinPr26AxzuQvERvB3AwlB98Cvm?= =?us-ascii?q?nZrNHvO6gOUuC51LTDwzvZYPNI2Dfy9YbEeQ0mrP+CR71wb8vRxlQ1Gw7YilWf?= =?us-ascii?q?s5DqPzCO2+sQrWeb6+5gWfizhG4grgF8uz6izdoihInOg4Ia0FHE9SNhzYc7JN?= =?us-ascii?q?24UlB0bsO+HJRMsCGaMpN6QsM+Q2F0oCY60acKuZ+nfCQSyZQo2QLfa/Kdf4iP?= =?us-ascii?q?+BLjW+CcKip7inJ9YL+yhhW//VK+xuDySMW4yktGoypLn9XWqHwByxLe5tCaRv?= =?us-ascii?q?dh5EutxziC2gPJ5uxLLk04j7fXJpAiz7IomJocr0fOEjPzlUjzj6KbeUEp+uat?= =?us-ascii?q?5unnf7rpvIGQOopphg3jKasjn8OyDOo7PwUOWWWQ5P6y26f5/ULjRbVHlvg2kq?= =?us-ascii?q?7Ev5/EPckbvau5AxNN0oYk9ha/Ey+q0NQGknkDK1JIYAyIj5PzNFzOOvz3EOmw?= =?us-ascii?q?g1CokDtywPDGI6HhDY7KLnjelrfuYKhx51RdyAorzdBf4p1VBqsdL/L0X0/9rN?= =?us-ascii?q?3YDhknPAyo2+vqCdZw2pkAVW+BHKOVKr7evF+G6+41PeWAeIEYtC74K/c/5v7u?= =?us-ascii?q?iXE5mUUafamsxZYZZmq3HupnI0qEe3bhn9MBHn0WsQo9V+HllUONUTpXZ3qoQ6?= =?us-ascii?q?084TQ7BJq8DYjfXoCtnKCB3CCjE51NfG9JEF+MHGzpd4qaR/cMZjieIsh7kjwL?= =?us-ascii?q?TbKhUZMu1QmytA/mzLpqNvLU9TcEtZLiytd14fHTmAoz9TNqE8Sd3XuBT2Zunm?= =?us-ascii?q?MHFHcK2/VVu010zB+80LRkjvoQQdZJ5vpPZRg7KYLRycRhGtX7XB7MdZGCT1Pw?= =?us-ascii?q?Bp3sGTgtT9833/cPblpzXdK4gVqLizKjH74YkaCjBZEo/OTbxXenY4430H/P24?= =?us-ascii?q?EggkUoBMxVOifu0rV2/gf7BoPVnQOejan8JooG2yuYvk2HxGGN+Al0WRBxXe+N?= =?us-ascii?q?CVwWeEra6/7970jBZ7OjDbBhOQxEn53RYpBWY8Hk2A0VDMzoP87TNifowz+9?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2G0AAC8/zNah8uZ6ERaAxwBAQEEAQEKA?= =?us-ascii?q?QGCbCOBFXQnB4RymDKCAJcgFIE+GygKGAuFGAKFAEEWAQEBAQEBAQEBAQIQAQE?= =?us-ascii?q?BCA0JCCgvgjgkAQ5LIQYGAQEBAQEBJgEBAQEBAQEBAQEBAQEBAQEBARcCLRABE?= =?us-ascii?q?gIYAQEBAwEBAT4JFg8MBAcEAgEIEQEDAQELHQcnCxQDBggCBAESCAwHigcIAQ+?= =?us-ascii?q?rQ4MRh0QBAQEBAQEBAQEBAQEBAQEBAQEBAQEVCINlBIEOXgEQEYFXhAaBDoMuA?= =?us-ascii?q?YE7ARIBCRgfJoJ/gjKKUwkTh32QSQYCh3yDJUyLUoYThBCHOI0YiTACBAIEBQI?= =?us-ascii?q?agTsmBoENb29RgikJgkoFCwyBZ3gqh2KBJYEVAQEB?= X-IPAS-Result: =?us-ascii?q?A2G0AAC8/zNah8uZ6ERaAxwBAQEEAQEKAQGCbCOBFXQnB4R?= =?us-ascii?q?ymDKCAJcgFIE+GygKGAuFGAKFAEEWAQEBAQEBAQEBAQIQAQEBCA0JCCgvgjgkA?= =?us-ascii?q?Q5LIQYGAQEBAQEBJgEBAQEBAQEBAQEBAQEBAQEBARcCLRABEgIYAQEBAwEBAT4?= =?us-ascii?q?JFg8MBAcEAgEIEQEDAQELHQcnCxQDBggCBAESCAwHigcIAQ+rQ4MRh0QBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEVCINlBIEOXgEQEYFXhAaBDoMuAYE7ARIBCRgfJoJ?= =?us-ascii?q?/gjKKUwkTh32QSQYCh3yDJUyLUoYThBCHOI0YiTACBAIEBQIagTsmBoENb29Rg?= =?us-ascii?q?ikJgkoFCwyBZ3gqh2KBJYEVAQEB?= Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa3.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Dec 2017 10:57:36 -0600 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Dec 2017 23:01:33 +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 vBFH7dUm006268 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 15 Dec 2017 12:07:40 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com vBFH7dUm006268 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1513357660; bh=RVLDYlQCCyZaSvQKGiKunpHfAlw=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=mZx7AxIs/vk3mNd7cohRyH//0EtGsIp+15fZYGnk/e2N3EVKuAFzNscRpYjMt+DGM kB8GjbWmO9Bs5/Wq3uFDshInHVFwWVogIPzUHJSyVk2zwU2nwqQGawjT1/tG8eCuV+ /nx0V6DVLmFXRVG+QDwsoTRgIw5RCCLTHdWE2bfs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com vBFH7dUm006268 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd55.lss.emc.com (RSA Interceptor); Fri, 15 Dec 2017 12:07:33 -0500 Received: from MXHUB318.corp.emc.com (MXHUB318.corp.emc.com [10.146.3.96]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vBFH7Wf3003180 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 15 Dec 2017 12:07:32 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB318.corp.emc.com ([10.146.3.96]) with mapi id 14.03.0352.000; Fri, 15 Dec 2017 12:07:32 -0500 To: Brian Witten , "patient@ietf.org" , "saag@ietf.org" Thread-Topic: Internet Draft posted as requested - Thread-Index: AQHTdG3hrR7/CZZMykmDXlV3KMVAN6NDcJ4GgAEyMYA= Date: Fri, 15 Dec 2017 17:07:31 +0000 Message-ID: References: , , , , , , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.138] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [saag] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 17:07:46 -0000 > The logic, in the short form of roughly five points would be: > ** (1) ** Endpoints have vulnerabilities. ( unfortunately lots of them. = For > this part I believe there is overwhelming evidence, but please LMK if you > disagree. ) > ** (2) ** These vulnerabilities are often difficult (sometimes nearly > impossible) for device owners, users, etc, to mitigate "in" these endpoin= ts. ( > this is true today for countless devices, and increasingly true for incre= asingly > closed devices, particularly in IOT and mobile. ) > ** (3) ** For that reason, those endpoint owners/users/etc often need to > put some "thing" in the network to mitigate those endpoint vulnerabilitie= s. > ** (4) ** For that to be effective (against attacks in encrypted traffic)= , that > "thing" needs keys to inspect the encrypted traffic. ( This can be done = any of > many ways, as it's done today. ) > ** (5) ** Where that's done today, it can be done much more safely, > therefore we should spec standards for how to do it more safely. ( Lots = of > ideas have been published in research, and I include some details on that > further below, but maturing the right ones and baking them into a standar= d is > of course typically a "bigger group" effort. ) >=20 > In that framework, I'd love to know which of these 5 points above (if any= ) are > agreeable to you, and which specifically you believe are either simply de= ad > wrong or the right-best focus of constructive discussion. For some it se= ems > that point (3) above is the most controversial, Particularly when the "thing" is inserted without any form of knowledge or = authorization by the endpoint. The discussion should be qualitatively different when the endpoint owner/us= er/etc. is required to do something in order to authorize the "thing" to ac= cess the endpoint's encrypted traffic. A deployed example that may help in= thinking about this is insertion of firewall decryption root certs into a = browser's trust store to enable a firewall to inspect all encrypted web tra= ffic that enters or exits a corporate network. This is only an example - t= hese three sentences are *NOT* a proposal to standardize anything ... but t= hey are a report on current "running code" ... Thanks, --David ---------------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0 Mobile: +1 (978) 394-7754 David.Black@dell.com ---------------------------------------------------------------- > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Brian Witten > Sent: Thursday, December 14, 2017 5:59 PM > To: patient@ietf.org; saag@ietf.org > Subject: Re: [saag] Internet Draft posted as requested - >=20 > Thank you everyone for your comments! >=20 > The request in Singapore for an Internet Draft seemed focused on an ask f= or > data, so I tried to keep the v00 focused on the data, and concise to be e= asily > read quickly, and I thought that I might be going onto a limb beginning t= o > present some of the logic, but it seems like many are hungry for more of = the > logic (or "at least some logic" as they might say) so I'll present more o= f the > logic.=A0 Of course, much of the logic was presented in the near 40 slide= s sent > earlier and roughly 5 pages of Q&A, but I agree with the merits of centra= lizing > all of the logic in an Internet Draft, so I'll aim to do that in the v01,= and, > perhaps more importantly, I also hear clearly some of the concerns on how > the logic was organized (or unorganized or disorganized as some might say= ) in > Singapore, so I'll try to be more clearly structured both here and in mor= e > detail in the v01.=A0 I'll comment on the solutioning further below, but = since so > many seem so hungry for the logic, I'll try present it relatively concise= ly here > so that discussion here can best shape the v01 which will pull from the l= ist, > the slldes, and more. >=20 > The logic, in the short form of roughly five points would be: > ** (1) ** Endpoints have vulnerabilities.=A0 ( unfortunately lots of them= .=A0 For > this part I believe there is overwhelming evidence, but please LMK if you > disagree. ) > ** (2) ** These vulnerabilities are often difficult (sometimes nearly > impossible) for device owners, users, etc, to mitigate "in" these endpoin= ts. ( > this is true today for countless devices, and increasingly true for incre= asingly > closed devices, particularly in IOT and mobile. ) > ** (3) ** For that reason, those endpoint owners/users/etc often need to > put some "thing" in the network to mitigate those endpoint vulnerabilitie= s. > ** (4) ** For that to be effective (against attacks in encrypted traffic)= , that > "thing" needs keys to inspect the encrypted traffic.=A0 ( This can be don= e any of > many ways, as it's done today. ) > ** (5) ** Where that's done today, it can be done much more safely, > therefore we should spec standards for how to do it more safely.=A0 ( Lot= s of > ideas have been published in research, and I include some details on that > further below, but maturing the right ones and baking them into a standar= d is > of course typically a "bigger group" effort. ) >=20 > In that framework, I'd love to know which of these 5 points above (if any= ) are > agreeable to you, and which specifically you believe are either simply de= ad > wrong or the right-best focus of constructive discussion.=A0 For some it = seems > that point (3) above is the most controversial, but others are already as= king > the details of (5) which is where the slides focused, but the v01 will of= course > cover both in depth, and, as promised, I'll give some points on (5) below= . >=20 > On the solutioning, as mentioned at the side-meeting, lots of solutions h= ave > been proposed in research communities, but I believe it's important to ge= t > aligned on the problems we're solving as a community before picking a > solution.=A0 As mentioned at the side-meeting, solutions proposed by the > research community include Stickler by Boneh & team at Stanford, plus the > unfortunately named mcTLS and mbTLS efforts, and more, but I believe it's > important to get aligned on the problems we're solving as a community > before picking a solution.=A0 Once we're aligned on (1) through (5) above= then > it makes more sense to get into the specific problems with (4) which (5) = tries > to address, including (a) retaining end-to-end integrity, (b) giving endp= oints > more precise control over when, where, and how such protection is > delivered from the network, in strong contrast today's all-or-nothing jus= t- > install-a-root approach. >=20 > To address some of the other important questions and concerns raised over > the past day. >=20 > Re, "does not specify a new protocol," many of the potential/candidate > protocols were mentioned at the side-meeting, in the notes of the side- > meeting, in the slides presented at the side-meeting, and in the email to > announce the side-meeting, but I'm happy to add them to the v01 to keep > everything together in a single Internet Draft.=A0 For context, as Stephe= n > pointed out, his ask was not for an Internet Draft of a protocol, but for= the > data (and logic) of why it might help to spec a new and/or additional pro= tocol. > Re, "It does not specify a concrete problem (use cases)," again these wer= e > mentioned at the side-meeting, in the notes of the side-meeting, in the > slides presented at the side-meeting, and in the email to announce the si= de- > meeting, but I'm happy to add them to the v01 to keep everything together > in a single Internet Draft. >=20 > Re, "It does not specify any kind of architecture," as above, covered bef= ore, > but I'm happy to add it to the v01 of an Internet Draft to get everything > together in a single Internet Draft.=A0 These seem like constructive requ= ests, > even if the material was covered elsewhere already.=A0 Thank You Again! >=20 > Similarly, if anything is missing from the notes, I'm eager to be sure th= is > discussion fairly and deeply captures _all_ views, particularly opposing = views, > so where there are gaps in the 7 pages of notes we took, those gaps are > absolutely not intentional.=A0 I'm eager to see any omissions rectified, = so > please send any additions, corrections, etc, either to this list or to me > personally.=A0 Either way, I'm eager to be sure everyone sees all views a= nd > hears all concerns and that all of those concerns are included and/or > addressed somehow in a v01. >=20 > Re, "pervasive monitoring should make way for network based monitoring," = I > wasn't trying to say that and in fact, from the slides you can clearly te= ll that > PATIENT is aiming to more completely block pervasive monitoring.=A0 Crypt= o > helps block pervasive monitoring by listeners in the network.=A0 Pervasiv= e > monitoring is also possible by hacking all the endpoints, and as presente= d in > the side-meeting, we have ample evidence of nation-states attempting to d= o > this. PATIENT aims to make safer prevention of the latter approach to > pervasive monitoring. >=20 > Re, "draft-mm-wg-effect-encrypt," you're absolutely right, and I'll cite = that > work in the v01 for precisely those reasons.=A0 In fact, my aim is to (ev= entually, > after we get aligned on scope, etc,) design a protocol that allows networ= k > security appliances to yet more safely work hand-in-hand with pervasive > encryption.=A0 I'm not trying to push back against pervasive encryption a= t all.=A0 I > suspect I might have to keep repeating myself on that until people believ= e it? >=20 > Re, "So far, I am still not convinced that a SOCKS proxy . connected via = a > VPN, is not sufficient to filter out malicious data."=A0 I believe connec= ting > proxies via VPN is a great way to help block malicious data.=A0 I'm also = not > debating the type of proxy to be used.=A0 As you know, and as the slides = say, > and as the v01 will say, I'm saying that when proxies change stuff, it wo= uld > help for the endpoint to know which proxy changed what where.=A0 Stickler > helps with that.=A0 I think it also helps for endpoints to know more abou= t the > proxy on the other side of the VPN, but I'd be happy for that to be in-sc= ope > or out-of-scope for a first WG on this.=A0Re, "from your conversations an= d > presentations (not from this document)," you raise a very fair > point.=A0 Although the original ask was not to put "everything" into a si= ngle > Internet Draft, putting "everything" into a single Internet Draft seems l= ike a > great idea, so I'll aim to do that with v01. >=20 > Regarding "months later," this seems to be at least a mild exaggeration a= s the > meeting was one month ago tomorrow. >=20 > Regarding "all in a non-verifiable manner," I thought counting phishing > websites would be easy enough for anyone who really wanted to test a > hypothesis instead of standing on rhetoric.=A0 PhishLabs seemed to manage > that OK.=A0 I haven't counted all of the https sites in PhishTank yet, bu= t at first > glance the fraction seems substantial.=A0 Admittedly, not all of the data= is > directly verifiable, nor did I ever promised that _all_ of the data would= be > directly verifiable, but counting phishing sites seemed easy enough.=A0 P= lease > LMK if I'm wrong on that point.=A0 The other sources seem to corroborate = each > other. >=20 > Regarding posting to the "Threat Response Blog," we'll consider that, but= the > ask to us was to share more data here so we brought the data here as > requested. >=20 > As a side comment, I'd also note the use of pejorative phrasing.=A0 "argu= es for > the mitm attacks on https," . It seems that you're calling "network based > blocking of malicious webpages" an "attack" when the blocking is actually > blocking the server's _attack_ against the client.=A0 Where I choose to h= ave a > network proxy protect from evil on the net, I don't consider that proxy t= o be > attacking me.=A0 I consider that proxy to be protecting me, and many > organizations manage keys accordingly.=A0 We see more and more people > needing network help in protecting themselves from such attacks, as laid = out > in (1) through (5) above.=A0 I look forward to your feedback there. >=20 > Thank you again - >=20 > Cheers, > Brian >=20 >=20 > From: Brian Witten > Sent: Wednesday, December 13, 2017 3:55 PM > To: patient@ietf.org > Subject: Internet Draft posted as requested - >=20 >=20 > Hi Everyone, >=20 > With the Wired article last week ( https://www.wired.com/story/phishing- > schemes-use-encrypted-sites-to-seem-legit/ ) ... I wanted to get the > Internet Draft ( https://www.ietf.org/id/draft-witten-protectingendpoints= - > 00.txt ) posted publicly for others to comment sooner rather than later.= =A0 Of > course, feel free to comment here on the list or just me comments 1:1 at > bwitten@symantec.com.=A0 Thank You Either Way! >=20 >=20 > https://media.wired.com/photos/5a25b22aa587381053b48abb/191:100/pass > /PhishingHTTPs-FeatureArt.jpg >=20 > Phishing Schemes Are Using Encrypted Sites to Seem Legit > www.wired.com > A green padlock might make it seem like a site is secure, but increasingl= y > phishers are using it to lure victims into giving up sensitive info. >=20 > Looking Forward, > Brian >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Fri Dec 15 09:31:40 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502E7126C3D; Fri, 15 Dec 2017 09:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, 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=symc.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 zWCM_9TTmwOA; Fri, 15 Dec 2017 09:31:29 -0800 (PST) Received: from asbsmtoutape01.symantec.com (asbsmtoutape01.symantec.com [155.64.138.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 051841200CF; Fri, 15 Dec 2017 09:31:28 -0800 (PST) Received: from asbsmtmtaapi02.symc.symantec.com (asb1-f5-symc-ext-prd-snat1.net.symantec.com [10.90.75.1]) by asbsmtoutape01.symantec.com (Symantec Messaging Gateway) with SMTP id 81.20.35258.0F6043A5; Fri, 15 Dec 2017 17:31:28 +0000 (GMT) X-AuditID: 0a5af819-80ab69c0000089ba-11-5a3406f0bf0b Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (asb1-f5-symc-ext-prd-snat4.net.symantec.com [10.90.75.4]) by asbsmtmtaapi02.symc.symantec.com (Symantec Messaging Gateway) with SMTP id AB.AA.04178.FE6043A5; Fri, 15 Dec 2017 17:31:27 +0000 (GMT) Received: from tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 15 Dec 2017 09:31:26 -0800 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.128.3) by tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Fri, 15 Dec 2017 09:31:26 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8el6zBSQ9ZqYeknPIiu/9pMwLw//9yxAAeB8yRN2I8U=; b=2DdPnpJEFwoRdccUFJwQLA967fDBbM3KWHj8bSCcXjWBqu7sCRdlvi2glG8WtK1iVM9QhUiO6jp/lV499VcKuNz4/p49gQ7wMcjucQIWFrtUUvnJ9BYdMLTClU2PhAQasxJXujmW9IaPQ0/Pedq3ZIAi4lVpdY3Q7y8h5Q+FC9g= Received: from MWHPR16MB1488.namprd16.prod.outlook.com (10.175.4.146) by MWHPR16MB1487.namprd16.prod.outlook.com (10.175.4.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Fri, 15 Dec 2017 17:31:24 +0000 Received: from MWHPR16MB1488.namprd16.prod.outlook.com ([10.175.4.146]) by MWHPR16MB1488.namprd16.prod.outlook.com ([10.175.4.146]) with mapi id 15.20.0302.017; Fri, 15 Dec 2017 17:31:24 +0000 From: Brian Witten To: "Black, David" , "patient@ietf.org" , "saag@ietf.org" Thread-Topic: [EXT] RE: Internet Draft posted as requested - Thread-Index: AQHTdG3hrR7/CZZMykmDXlV3KMVAN6NDcJ4GgAEyMYCAAAfemA== Date: Fri, 15 Dec 2017 17:31:24 +0000 Message-ID: References: , , , , , , , , In-Reply-To: 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=brian_witten@symantec.com; x-originating-ip: [2605:e000:9394:6500:b45e:d290:dd3d:9478] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR16MB1487; 6:dZ+P+etdFJaZcCYISTJ0LEtRUKL4AXyq5Hg9T9u0PhJPtn1IBhI4HVypD2QOBokhsPYe4V8A7i6/GBsVqdiKv6DLpEsTO0P7Fbx/ztnBWA1YRlEr8M7PJTgEyqYNDzDgGEFwOpGG+DuRotnWYOUxNpeV2yDulwFU7nlXohpbK7WdtT+MBjzzR2ym6BHqMrRkFVqncalDYGgXZDwE7brPKZGVIxJED0kXlv5HafWfZQsN7UI/9AJrMkADyHdYVag+DJ4DwkB5CH28qnpKIXmZv5oEKRJBHNLe98XIbLYdcEtUxqE70JHoE8wvGxezbmgYAjRhWDRZUx2Xw68HvMBiSKfxPoM27ML1xJKvCcJLcC8=; 5:YNDNSZDnKUFMPp4XFG8RhRu58+Ovwm36f6rQ7dzExlQpzftOECJ6oGrQ9OCDP7mZ/xiUxJI60D41et46MUnrD0VFg+DJMbAWTVMkutU1ynXE8wPYB6gKYQgI6b4ZuZvlW/PtS7ZDxO/Z9wXcbvRzqjM9AygkR37zH33Dog4kJYc=; 24:U4ciPkTwcvbNT7GjaXlGhqetg/dBrxE5tSb2h6fKZqi9eZn6aKbJtxV9I/KiL+kdVbUSYgr/x7GaMfRx2WauYM77LkPnZwf7oc07w65a5UU=; 7:RXpk/SrMIcZ1GwWELdoSGNbZ/E50k972infQJWbkc6D+WJfLfCgbJn+jh5WQbFzV6EzW3vQrZ1h8eA8arworaiKCvqnMBGdt1eJdVFskONX0qnvqHEtM/IwkOarFP9dz/3jNEvOWfF0hsxEmWtq9F+v7cl2lQWZBn1qCGYac5pTCmYNIMQT+IGAveqloFNqjp/EJjqQABD6rCiwaFsdF0NJ3MEH7WMr/lGM8moXGpvHe282AsLJUPAt//vnV8AQR x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 14a8b0a6-7972-486e-e388-08d543e1aa38 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:MWHPR16MB1487; x-ms-traffictypediagnostic: MWHPR16MB1487: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(192374486261705)(258766100185102)(94390896966249)(94626863071701)(56004941905204); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231023)(93006095)(93001095)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(6072148)(201708071742011); SRVR:MWHPR16MB1487; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR16MB1487; x-forefront-prvs: 05220145DE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(376002)(346002)(396003)(53754006)(199004)(189003)(13464003)(51414003)(33656002)(77096006)(6436002)(229853002)(1680700002)(8666007)(106356001)(53386004)(105586002)(6246003)(236005)(54896002)(97736004)(9686003)(6306002)(19627405001)(5660300001)(6116002)(561944003)(53936002)(6606003)(55016002)(2950100002)(2900100001)(102836003)(606006)(74316002)(7736002)(10290500003)(81166006)(8676002)(68736007)(99286004)(93886005)(7696005)(25786009)(110136005)(2501003)(86362001)(53546011)(3660700001)(2906002)(14454004)(316002)(3280700002)(575784001)(478600001)(2201001)(76176011)(966005)(59450400001)(8936002)(6506007)(81156014)(9010500006); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR16MB1487; H:MWHPR16MB1488.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR16MB14886D3C1CFE600F29918BA1930B0MWHPR16MB1488namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 14a8b0a6-7972-486e-e388-08d543e1aa38 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2017 17:31:24.4257 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR16MB1487 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sf0hTURTHue+9bW+jxXNZHo0gRkkYLodigiYWEoqakkgwjHrqM80fs20O FZIplLkUf7BCp7LCpbgKKhMLE2RpOakmEib2y9Qkp1L7Z1my1bY7wX8un/M933vPOZdDk5IR XhhdXK7hVOVsqZQvokSKNBT5ix+jiLpmIuOcxl4qbnUsOs7Q0kgkkSntnR1kitn8h8giFKKE Aq60WMupjiVeFBXpzdqKuRGiaqJ/iNSh+3pCj4Q0MDFgeGv0soiWME4EjxuGBXpE+xNvvgux 7kJQZ7AJcDCBoH5xhsTBKgK39T3lCyimkQTTq3oKZwwEfP3SF3h4HMEN5weBryKfkcGE+xPP x8GMGrq//aV8vIeJh0H7pADrCdBv8VCYT8FKS6e/W4o5DHNTs6SPxUwubFkHAk2N8mFs0eW/ IGTOwJLb5mfE7IPfUw/8l0kmBOaXTYGxGTC/sJOY98LqkoeH/bkw9dAR0OPB5XQIMB+AGdNN 5CsGjFUAjllLICGDobYNhDkDBnsGKGwyI5hq2jZFwMumYQL/awk0dBHY04Ogu3mJbEVy444G jV4bySjhda/Q6B80CGydyxS2yGDuloGP+Sj03V0jMUdCh8dK7dTvIIEFHWTVeeoyjbJSw1Zw UXKZuros33ew3oXKl+Ury54g/0pthj5D45PpVsTQSLpLfN0drZDwWK3XaUVAk9Jg8fqKVxIX sNU1nEp5QVVZyqmtaD9NSUPE7a5whYS5xGq4Eo6r4FTbWYIWhulQcsrpdVnH7X9HQhsWEg7d czpqz2+11CQH96Wx+dM/sqsud2W1pUNs89l6izQqdFmYF+bJnK2zHZdWFBakarJyavvjNps+ 5uq31rQnk+Z07nc6adPT556fqYuJQVfsrY6ZE6M5ufaMkemNR5bYz4VU+HLaGJW521g7vyDP vio8J6XURaw8glSp2f/mNW6HTgMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHee692+6WwtOyPGlSLAQxtjQVDE2qDyWkEVQfHIJd9ZJD58s2 paLALEqnYZmKLm2WQ3H2hi9YaSTXqblCUUtNzMiZoCE1EK1My+1Z4JeH3/+c/3nO4XBYWm4W +bGaTAOvy+QyFGIZI1OfYJTfxeHqkIK2g5FOUz0TOd8dFlleWkQdpmPLqqvoWIvlF3WKUsui U/kMTR6v2x9zTpZmtORlT3RSF3ob2+l81GykjIhlAYfDu69SI5KxcryM4Gr5gISIXgQFMyM0 EfMI1oT3jEswuIgGc18BQzLlFHyebqCIsCEodI5vfCBlxVgFvWtTIhf7YD3UfPnNuHgbjoLW oTcSEo+GRus6Q/gozJVWUy5mcCBM2MdoF3vjRFgVmjxDvRJD98yyu0CKT4JjbcDNCO+AFfsj dzGNfWFy1uxmwBgsXUM04e0w71gXEX8i2B8veOJRsOxckBAOgBFzMXI1AyxIYGHM6kmooP3O IiIcD621TQwxWRDYS/6bgqGnpMOz13S4eY8inloENbccnm51NHwqTCa8Cx4+sYpuI6Vp0+Cm jXIaZ0F/vdTkXsBWGKieZYhFBRMV5WLC+6DhwTeasBKq1gVmc7wOSaxoD6dP1msNWgPHZWtC Dqj0F7UprofbuKcUVUqWtgW5L2rV9zka/BMnIMwihZc3ngxTy0Vc3oZTQP4so/D1dgRRajk+ zxn4dJ7P5nVJutwMXi8gipX65aOy4qTQu0Et8WPpZ9uUU6Otb336czpTL41qPlZUCjErOT43 ujqqK5xL033XflaYEy7vjDktxCYtfZh8Mbz3vt8ziPPR/OU1gYqeFf+67sGXiz9Mh56GR4yr HDblluys13lXbLtzJcds/sa5iIBcndeRoNXr/vbh45VdYcbZhIYzzQpGn8aFBtM6PfcP1u0f 2jIDAAA= X-CFilter-Loop: ASB04 Archived-At: Subject: Re: [saag] [EXT] RE: Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 17:31:34 -0000 --_000_MWHPR16MB14886D3C1CFE600F29918BA1930B0MWHPR16MB1488namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Many Thanks! Re, "inserted without any form of knowledge or authorization by the endpoin= t," in fact, PATIENT aims to establish a protocol whereby end-users get vis= ibility into ALL of the "things" (middleboxes) monitoring the communication= s. Re "root certs into a browser's trust store," you're absolutely right that = this is common practice today. This practice (without any additional proto= cols such as what PATIENT could enable) breaks end2end Integrity protection= . As a community, we can do much better. We can make this much safer, both o= n end2end cryptographic integrity protection a la Stickler, and giving endp= oints/users more visibility into the number of MB's monitoring their commun= ications! Thank You Again!! ________________________________ From: Black, David Sent: Friday, December 15, 2017 9:07 AM To: Brian Witten; patient@ietf.org; saag@ietf.org Subject: [EXT] RE: Internet Draft posted as requested - > The logic, in the short form of roughly five points would be: > ** (1) ** Endpoints have vulnerabilities. ( unfortunately lots of them. = For > this part I believe there is overwhelming evidence, but please LMK if you > disagree. ) > ** (2) ** These vulnerabilities are often difficult (sometimes nearly > impossible) for device owners, users, etc, to mitigate "in" these endpoin= ts. ( > this is true today for countless devices, and increasingly true for incre= asingly > closed devices, particularly in IOT and mobile. ) > ** (3) ** For that reason, those endpoint owners/users/etc often need to > put some "thing" in the network to mitigate those endpoint vulnerabilitie= s. > ** (4) ** For that to be effective (against attacks in encrypted traffic)= , that > "thing" needs keys to inspect the encrypted traffic. ( This can be done = any of > many ways, as it's done today. ) > ** (5) ** Where that's done today, it can be done much more safely, > therefore we should spec standards for how to do it more safely. ( Lots = of > ideas have been published in research, and I include some details on that > further below, but maturing the right ones and baking them into a standar= d is > of course typically a "bigger group" effort. ) > > In that framework, I'd love to know which of these 5 points above (if any= ) are > agreeable to you, and which specifically you believe are either simply de= ad > wrong or the right-best focus of constructive discussion. For some it se= ems > that point (3) above is the most controversial, Particularly when the "thing" is inserted without any form of knowledge or = authorization by the endpoint. The discussion should be qualitatively different when the endpoint owner/us= er/etc. is required to do something in order to authorize the "thing" to ac= cess the endpoint's encrypted traffic. A deployed example that may help in= thinking about this is insertion of firewall decryption root certs into a = browser's trust store to enable a firewall to inspect all encrypted web tra= ffic that enters or exits a corporate network. This is only an example - t= hese three sentences are *NOT* a proposal to standardize anything ... but t= hey are a report on current "running code" ... Thanks, --David ---------------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 Mobile: +1 (978) 394-7754 David.Black@dell.com ---------------------------------------------------------------- > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Brian Witten > Sent: Thursday, December 14, 2017 5:59 PM > To: patient@ietf.org; saag@ietf.org > Subject: Re: [saag] Internet Draft posted as requested - > > Thank you everyone for your comments! > > The request in Singapore for an Internet Draft seemed focused on an ask f= or > data, so I tried to keep the v00 focused on the data, and concise to be e= asily > read quickly, and I thought that I might be going onto a limb beginning t= o > present some of the logic, but it seems like many are hungry for more of = the > logic (or "at least some logic" as they might say) so I'll present more o= f the > logic. Of course, much of the logic was presented in the near 40 slides = sent > earlier and roughly 5 pages of Q&A, but I agree with the merits of centra= lizing > all of the logic in an Internet Draft, so I'll aim to do that in the v01,= and, > perhaps more importantly, I also hear clearly some of the concerns on how > the logic was organized (or unorganized or disorganized as some might say= ) in > Singapore, so I'll try to be more clearly structured both here and in mor= e > detail in the v01. I'll comment on the solutioning further below, but si= nce so > many seem so hungry for the logic, I'll try present it relatively concise= ly here > so that discussion here can best shape the v01 which will pull from the l= ist, > the slldes, and more. > > The logic, in the short form of roughly five points would be: > ** (1) ** Endpoints have vulnerabilities. ( unfortunately lots of them. = For > this part I believe there is overwhelming evidence, but please LMK if you > disagree. ) > ** (2) ** These vulnerabilities are often difficult (sometimes nearly > impossible) for device owners, users, etc, to mitigate "in" these endpoin= ts. ( > this is true today for countless devices, and increasingly true for incre= asingly > closed devices, particularly in IOT and mobile. ) > ** (3) ** For that reason, those endpoint owners/users/etc often need to > put some "thing" in the network to mitigate those endpoint vulnerabilitie= s. > ** (4) ** For that to be effective (against attacks in encrypted traffic)= , that > "thing" needs keys to inspect the encrypted traffic. ( This can be done = any of > many ways, as it's done today. ) > ** (5) ** Where that's done today, it can be done much more safely, > therefore we should spec standards for how to do it more safely. ( Lots = of > ideas have been published in research, and I include some details on that > further below, but maturing the right ones and baking them into a standar= d is > of course typically a "bigger group" effort. ) > > In that framework, I'd love to know which of these 5 points above (if any= ) are > agreeable to you, and which specifically you believe are either simply de= ad > wrong or the right-best focus of constructive discussion. For some it se= ems > that point (3) above is the most controversial, but others are already as= king > the details of (5) which is where the slides focused, but the v01 will of= course > cover both in depth, and, as promised, I'll give some points on (5) below= . > > On the solutioning, as mentioned at the side-meeting, lots of solutions h= ave > been proposed in research communities, but I believe it's important to ge= t > aligned on the problems we're solving as a community before picking a > solution. As mentioned at the side-meeting, solutions proposed by the > research community include Stickler by Boneh & team at Stanford, plus the > unfortunately named mcTLS and mbTLS efforts, and more, but I believe it's > important to get aligned on the problems we're solving as a community > before picking a solution. Once we're aligned on (1) through (5) above t= hen > it makes more sense to get into the specific problems with (4) which (5) = tries > to address, including (a) retaining end-to-end integrity, (b) giving endp= oints > more precise control over when, where, and how such protection is > delivered from the network, in strong contrast today's all-or-nothing jus= t- > install-a-root approach. > > To address some of the other important questions and concerns raised over > the past day. > > Re, "does not specify a new protocol," many of the potential/candidate > protocols were mentioned at the side-meeting, in the notes of the side- > meeting, in the slides presented at the side-meeting, and in the email to > announce the side-meeting, but I'm happy to add them to the v01 to keep > everything together in a single Internet Draft. For context, as Stephen > pointed out, his ask was not for an Internet Draft of a protocol, but for= the > data (and logic) of why it might help to spec a new and/or additional pro= tocol. > Re, "It does not specify a concrete problem (use cases)," again these wer= e > mentioned at the side-meeting, in the notes of the side-meeting, in the > slides presented at the side-meeting, and in the email to announce the si= de- > meeting, but I'm happy to add them to the v01 to keep everything together > in a single Internet Draft. > > Re, "It does not specify any kind of architecture," as above, covered bef= ore, > but I'm happy to add it to the v01 of an Internet Draft to get everything > together in a single Internet Draft. These seem like constructive reques= ts, > even if the material was covered elsewhere already. Thank You Again! > > Similarly, if anything is missing from the notes, I'm eager to be sure th= is > discussion fairly and deeply captures _all_ views, particularly opposing = views, > so where there are gaps in the 7 pages of notes we took, those gaps are > absolutely not intentional. I'm eager to see any omissions rectified, so > please send any additions, corrections, etc, either to this list or to me > personally. Either way, I'm eager to be sure everyone sees all views and > hears all concerns and that all of those concerns are included and/or > addressed somehow in a v01. > > Re, "pervasive monitoring should make way for network based monitoring," = I > wasn't trying to say that and in fact, from the slides you can clearly te= ll that > PATIENT is aiming to more completely block pervasive monitoring. Crypto > helps block pervasive monitoring by listeners in the network. Pervasive > monitoring is also possible by hacking all the endpoints, and as presente= d in > the side-meeting, we have ample evidence of nation-states attempting to d= o > this. PATIENT aims to make safer prevention of the latter approach to > pervasive monitoring. > > Re, "draft-mm-wg-effect-encrypt," you're absolutely right, and I'll cite = that > work in the v01 for precisely those reasons. In fact, my aim is to (even= tually, > after we get aligned on scope, etc,) design a protocol that allows networ= k > security appliances to yet more safely work hand-in-hand with pervasive > encryption. I'm not trying to push back against pervasive encryption at = all. I > suspect I might have to keep repeating myself on that until people believ= e it? > > Re, "So far, I am still not convinced that a SOCKS proxy . connected via = a > VPN, is not sufficient to filter out malicious data." I believe connecti= ng > proxies via VPN is a great way to help block malicious data. I'm also no= t > debating the type of proxy to be used. As you know, and as the slides sa= y, > and as the v01 will say, I'm saying that when proxies change stuff, it wo= uld > help for the endpoint to know which proxy changed what where. Stickler > helps with that. I think it also helps for endpoints to know more about = the > proxy on the other side of the VPN, but I'd be happy for that to be in-sc= ope > or out-of-scope for a first WG on this. Re, "from your conversations and > presentations (not from this document)," you raise a very fair > point. Although the original ask was not to put "everything" into a sing= le > Internet Draft, putting "everything" into a single Internet Draft seems l= ike a > great idea, so I'll aim to do that with v01. > > Regarding "months later," this seems to be at least a mild exaggeration a= s the > meeting was one month ago tomorrow. > > Regarding "all in a non-verifiable manner," I thought counting phishing > websites would be easy enough for anyone who really wanted to test a > hypothesis instead of standing on rhetoric. PhishLabs seemed to manage > that OK. I haven't counted all of the https sites in PhishTank yet, but = at first > glance the fraction seems substantial. Admittedly, not all of the data i= s > directly verifiable, nor did I ever promised that _all_ of the data would= be > directly verifiable, but counting phishing sites seemed easy enough. Ple= ase > LMK if I'm wrong on that point. The other sources seem to corroborate ea= ch > other. > > Regarding posting to the "Threat Response Blog," we'll consider that, but= the > ask to us was to share more data here so we brought the data here as > requested. > > As a side comment, I'd also note the use of pejorative phrasing. "argues= for > the mitm attacks on https," . It seems that you're calling "network based > blocking of malicious webpages" an "attack" when the blocking is actually > blocking the server's _attack_ against the client. Where I choose to hav= e a > network proxy protect from evil on the net, I don't consider that proxy t= o be > attacking me. I consider that proxy to be protecting me, and many > organizations manage keys accordingly. We see more and more people > needing network help in protecting themselves from such attacks, as laid = out > in (1) through (5) above. I look forward to your feedback there. > > Thank you again - > > Cheers, > Brian > > > From: Brian Witten > Sent: Wednesday, December 13, 2017 3:55 PM > To: patient@ietf.org > Subject: Internet Draft posted as requested - > > > Hi Everyone, > > With the Wired article last week ( https://clicktime.symantec.com/a/1/rI= iJXLn_RcL6DO1kshrfRFngO-jzXx2qnw5My1Gmx-4=3D?d=3DacDp1ppr8wHdxscIO4PLDe8sLD= UJcnfHSz2clVZzWLBTyzbkEl4RaUhyHkZYo10tyNBxxnXDlN2oWb07cBnksNldu3BSjflTGgm5H= QghRGGbipD3c7Nl4rUJ2U65HmVxzWgiiV0Ynq0kqVwskgbtycb-DcPW4Q3IIx1qQwmT66LrRpGV= ItWeSOY1eY-KLO-F4N7fwc8Z3FJyaKcxhdPsTn4TFe6OkX9MgQJsjXttvbHcoHr_hM1GRoT_Hmf= V-KyYQemM7RzNkRbb2ES1NQp2v_mmPoMGPwDdPxkuJKGsPg-FY6EFpCQ3EcmayeK9TZhaFUUhH0= 1VFcgm_8Qqb8bYf2vbBDgj-8y_rzqcJ1TA_bvPfjlxvEzOps0yNQl9DH26gAGK9GM5MXxDEZc5x= AocAyQ%3D&u=3Dhttps%3A%2F%2Fwww.wired.com%2Fstory%2Fphishing- > schemes-use-encrypted-sites-to-seem-legit/ ) ... I wanted to get the > Internet Draft ( https://clicktime.symantec.com/a/1/1E0rtJCkJI3RRVQJh91qE= ecCADHsunsL3_elUVceQ0k=3D?d=3DacDp1ppr8wHdxscIO4PLDe8sLDUJcnfHSz2clVZzWLBTy= zbkEl4RaUhyHkZYo10tyNBxxnXDlN2oWb07cBnksNldu3BSjflTGgm5HQghRGGbipD3c7Nl4rUJ= 2U65HmVxzWgiiV0Ynq0kqVwskgbtycb-DcPW4Q3IIx1qQwmT66LrRpGVItWeSOY1eY-KLO-F4N7= fwc8Z3FJyaKcxhdPsTn4TFe6OkX9MgQJsjXttvbHcoHr_hM1GRoT_HmfV-KyYQemM7RzNkRbb2E= S1NQp2v_mmPoMGPwDdPxkuJKGsPg-FY6EFpCQ3EcmayeK9TZhaFUUhH01VFcgm_8Qqb8bYf2vbB= Dgj-8y_rzqcJ1TA_bvPfjlxvEzOps0yNQl9DH26gAGK9GM5MXxDEZc5xAocAyQ%3D&u=3Dhttps= %3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-witten-protectingendpoints- > 00.txt ) posted publicly for others to comment sooner rather than later. = Of > course, feel free to comment here on the list or just me comments 1:1 at > bwitten@symantec.com. Thank You Either Way! > > > https://clicktime.symantec.com/a/1/EZreXTnVcH4VO_SfwFt5e40fv5Kya02XGSioz4= HgSnQ=3D?d=3DacDp1ppr8wHdxscIO4PLDe8sLDUJcnfHSz2clVZzWLBTyzbkEl4RaUhyHkZYo1= 0tyNBxxnXDlN2oWb07cBnksNldu3BSjflTGgm5HQghRGGbipD3c7Nl4rUJ2U65HmVxzWgiiV0Yn= q0kqVwskgbtycb-DcPW4Q3IIx1qQwmT66LrRpGVItWeSOY1eY-KLO-F4N7fwc8Z3FJyaKcxhdPs= Tn4TFe6OkX9MgQJsjXttvbHcoHr_hM1GRoT_HmfV-KyYQemM7RzNkRbb2ES1NQp2v_mmPoMGPwD= dPxkuJKGsPg-FY6EFpCQ3EcmayeK9TZhaFUUhH01VFcgm_8Qqb8bYf2vbBDgj-8y_rzqcJ1TA_b= vPfjlxvEzOps0yNQl9DH26gAGK9GM5MXxDEZc5xAocAyQ%3D&u=3Dhttps%3A%2F%2Fmedia.wi= red.com%2Fphotos%2F5a25b22aa587381053b48abb%2F191%3A100%2Fpass > /PhishingHTTPs-FeatureArt.jpg > > Phishing Schemes Are Using Encrypted Sites to Seem Legit > www.wired.com > A green padlock might make it seem like a site is secure, but increasingl= y > phishers are using it to lure victims into giving up sensitive info. > > Looking Forward, > Brian > > _______________________________________________ > saag mailing list > saag@ietf.org > https://clicktime.symantec.com/a/1/8r1dfpQVPaT0ym4x10d1AoBGkiwLzbkySDbKaq= -1M2Q=3D?d=3DacDp1ppr8wHdxscIO4PLDe8sLDUJcnfHSz2clVZzWLBTyzbkEl4RaUhyHkZYo1= 0tyNBxxnXDlN2oWb07cBnksNldu3BSjflTGgm5HQghRGGbipD3c7Nl4rUJ2U65HmVxzWgiiV0Yn= q0kqVwskgbtycb-DcPW4Q3IIx1qQwmT66LrRpGVItWeSOY1eY-KLO-F4N7fwc8Z3FJyaKcxhdPs= Tn4TFe6OkX9MgQJsjXttvbHcoHr_hM1GRoT_HmfV-KyYQemM7RzNkRbb2ES1NQp2v_mmPoMGPwD= dPxkuJKGsPg-FY6EFpCQ3EcmayeK9TZhaFUUhH01VFcgm_8Qqb8bYf2vbBDgj-8y_rzqcJ1TA_b= vPfjlxvEzOps0yNQl9DH26gAGK9GM5MXxDEZc5xAocAyQ%3D&u=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fsaag --_000_MWHPR16MB14886D3C1CFE600F29918BA1930B0MWHPR16MB1488namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Many Thanks!

Re, "inserted without any form of know= ledge or authorization by the endpoint," in fact, PATIENT aims to esta= blish a protocol whereby end-users get visibility into ALL of the "thi= ngs" (middleboxes) monitoring the communications.

Re "root certs into a browser's trust store," you're absolutely r= ight that this is common practice today.  This practice (without any a= dditional protocols such as what PATIENT could enable) breaks end2end Integ= rity protection.

As a community, we can do much better.  We can make this much safer, b= oth on end2end cryptographic integrity protection a la Stickler, and giving= endpoints/users more visibility into the number of MB's monitoring their c= ommunications!

Thank You Again!!


From: Black, David <Da= vid.Black@dell.com>
Sent: Friday, December 15, 2017 9:07 AM
To: Brian Witten; patient@ietf.org; saag@ietf.org
Subject: [EXT] RE: Internet Draft posted as requested -
 
> The logic, in the short form of roughly five = points would be:
> ** (1) ** Endpoints have vulnerabilities.  ( unfortunately lots o= f them.  For
> this part I believe there is overwhelming evidence, but please LMK if = you
> disagree. )
> ** (2) ** These vulnerabilities are often difficult (sometimes nearly<= br> > impossible) for device owners, users, etc, to mitigate "in" = these endpoints. (
> this is true today for countless devices, and increasingly true for in= creasingly
> closed devices, particularly in IOT and mobile. )
> ** (3) ** For that reason, those endpoint owners/users/etc often need = to
> put some "thing" in the network to mitigate those endpoint v= ulnerabilities.
> ** (4) ** For that to be effective (against attacks in encrypted traff= ic), that
> "thing" needs keys to inspect the encrypted traffic.  (= This can be done any of
> many ways, as it's done today. )
> ** (5) ** Where that's done today, it can be done much more safely, > therefore we should spec standards for how to do it more safely. = ( Lots of
> ideas have been published in research, and I include some details on t= hat
> further below, but maturing the right ones and baking them into a stan= dard is
> of course typically a "bigger group" effort. )
>
> In that framework, I'd love to know which of these 5 points above (if = any) are
> agreeable to you, and which specifically you believe are either simply= dead
> wrong or the right-best focus of constructive discussion.  For so= me it seems
> that point (3) above is the most controversial,

Particularly when the "thing" is inserted without any form of kno= wledge or authorization by the endpoint.

The discussion should be qualitatively different when the endpoint owner/us= er/etc. is required to do something in order to authorize the "thing&q= uot; to access the endpoint's encrypted traffic.  A deployed example t= hat may help in thinking about this is insertion of firewall decryption root certs into a browser's trust store to enable a= firewall to inspect all encrypted web traffic that enters or exits a corpo= rate network.  This is only an example - these three sentences are *NO= T* a proposal to standardize anything ... but they are a report on current "running code" ...

Thanks, --David
----------------------------------------------------------------
David L. Black, Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953    Mobile: +1 (978) 394-7754
David.Black@dell.com
----------------------------------------------------------------

> -----Original Message-----
> From: saag [mailto:saag-bounc= es@ietf.org] On Behalf Of Brian Witten
> Sent: Thursday, December 14, 2017 5:59 PM
> To: patient@ietf.org; saag@ietf.org
> Subject: Re: [saag] Internet Draft posted as requested -
>
> Thank you everyone for your comments!
>
> The request in Singapore for an Internet Draft seemed focused on an as= k for
> data, so I tried to keep the v00 focused on the data, and concise to b= e easily
> read quickly, and I thought that I might be going onto a limb beginnin= g to
> present some of the logic, but it seems like many are hungry for more = of the
> logic (or "at least some logic" as they might say) so I'll p= resent more of the
> logic.  Of course, much of the logic was presented in the near 40= slides sent
> earlier and roughly 5 pages of Q&A, but I agree with the merits of= centralizing
> all of the logic in an Internet Draft, so I'll aim to do that in the v= 01, and,
> perhaps more importantly, I also hear clearly some of the concerns on = how
> the logic was organized (or unorganized or disorganized as some might = say) in
> Singapore, so I'll try to be more clearly structured both here and in = more
> detail in the v01.  I'll comment on the solutioning further below= , but since so
> many seem so hungry for the logic, I'll try present it relatively conc= isely here
> so that discussion here can best shape the v01 which will pull from th= e list,
> the slldes, and more.
>
> The logic, in the short form of roughly five points would be:
> ** (1) ** Endpoints have vulnerabilities.  ( unfortunately lots o= f them.  For
> this part I believe there is overwhelming evidence, but please LMK if = you
> disagree. )
> ** (2) ** These vulnerabilities are often difficult (sometimes nearly<= br> > impossible) for device owners, users, etc, to mitigate "in" = these endpoints. (
> this is true today for countless devices, and increasingly true for in= creasingly
> closed devices, particularly in IOT and mobile. )
> ** (3) ** For that reason, those endpoint owners/users/etc often need = to
> put some "thing" in the network to mitigate those endpoint v= ulnerabilities.
> ** (4) ** For that to be effective (against attacks in encrypted traff= ic), that
> "thing" needs keys to inspect the encrypted traffic.  (= This can be done any of
> many ways, as it's done today. )
> ** (5) ** Where that's done today, it can be done much more safely, > therefore we should spec standards for how to do it more safely. = ( Lots of
> ideas have been published in research, and I include some details on t= hat
> further below, but maturing the right ones and baking them into a stan= dard is
> of course typically a "bigger group" effort. )
>
> In that framework, I'd love to know which of these 5 points above (if = any) are
> agreeable to you, and which specifically you believe are either simply= dead
> wrong or the right-best focus of constructive discussion.  For so= me it seems
> that point (3) above is the most controversial, but others are already= asking
> the details of (5) which is where the slides focused, but the v01 will= of course
> cover both in depth, and, as promised, I'll give some points on (5) be= low.
>
> On the solutioning, as mentioned at the side-meeting, lots of solution= s have
> been proposed in research communities, but I believe it's important to= get
> aligned on the problems we're solving as a community before picking a<= br> > solution.  As mentioned at the side-meeting, solutions proposed b= y the
> research community include Stickler by Boneh & team at Stanford, p= lus the
> unfortunately named mcTLS and mbTLS efforts, and more, but I believe i= t's
> important to get aligned on the problems we're solving as a community<= br> > before picking a solution.  Once we're aligned on (1) through (5)= above then
> it makes more sense to get into the specific problems with (4) which (= 5) tries
> to address, including (a) retaining end-to-end integrity, (b) giving e= ndpoints
> more precise control over when, where, and how such protection is
> delivered from the network, in strong contrast today's all-or-nothing = just-
> install-a-root approach.
>
> To address some of the other important questions and concerns raised o= ver
> the past day.
>
> Re, "does not specify a new protocol," many of the potential= /candidate
> protocols were mentioned at the side-meeting, in the notes of the side= -
> meeting, in the slides presented at the side-meeting, and in the email= to
> announce the side-meeting, but I'm happy to add them to the v01 to kee= p
> everything together in a single Internet Draft.  For context, as = Stephen
> pointed out, his ask was not for an Internet Draft of a protocol, but = for the
> data (and logic) of why it might help to spec a new and/or additional = protocol.
> Re, "It does not specify a concrete problem (use cases)," ag= ain these were
> mentioned at the side-meeting, in the notes of the side-meeting, in th= e
> slides presented at the side-meeting, and in the email to announce the= side-
> meeting, but I'm happy to add them to the v01 to keep everything toget= her
> in a single Internet Draft.
>
> Re, "It does not specify any kind of architecture," as above= , covered before,
> but I'm happy to add it to the v01 of an Internet Draft to get everyth= ing
> together in a single Internet Draft.  These seem like constructiv= e requests,
> even if the material was covered elsewhere already.  Thank You Ag= ain!
>
> Similarly, if anything is missing from the notes, I'm eager to be sure= this
> discussion fairly and deeply captures _all_ views, particularly opposi= ng views,
> so where there are gaps in the 7 pages of notes we took, those gaps ar= e
> absolutely not intentional.  I'm eager to see any omissions recti= fied, so
> please send any additions, corrections, etc, either to this list or to= me
> personally.  Either way, I'm eager to be sure everyone sees all v= iews and
> hears all concerns and that all of those concerns are included and/or<= br> > addressed somehow in a v01.
>
> Re, "pervasive monitoring should make way for network based monit= oring," I
> wasn't trying to say that and in fact, from the slides you can clearly= tell that
> PATIENT is aiming to more completely block pervasive monitoring. = Crypto
> helps block pervasive monitoring by listeners in the network.  Pe= rvasive
> monitoring is also possible by hacking all the endpoints, and as prese= nted in
> the side-meeting, we have ample evidence of nation-states attempting t= o do
> this.  PATIENT aims to make safer prevention of the latter approa= ch to
> pervasive monitoring.
>
> Re, "draft-mm-wg-effect-encrypt," you're absolutely right, a= nd I'll cite that
> work in the v01 for precisely those reasons.  In fact, my aim is = to (eventually,
> after we get aligned on scope, etc,) design a protocol that allows net= work
> security appliances to yet more safely work hand-in-hand with pervasiv= e
> encryption.  I'm not trying to push back against pervasive encryp= tion at all.  I
> suspect I might have to keep repeating myself on that until people bel= ieve it?
>
> Re, "So far, I am still not convinced that a SOCKS proxy . connec= ted via a
> VPN, is not sufficient to filter out malicious data."  I bel= ieve connecting
> proxies via VPN is a great way to help block malicious data.  I'm= also not
> debating the type of proxy to be used.  As you know, and as the s= lides say,
> and as the v01 will say, I'm saying that when proxies change stuff, it= would
> help for the endpoint to know which proxy changed what where.  St= ickler
> helps with that.  I think it also helps for endpoints to know mor= e about the
> proxy on the other side of the VPN, but I'd be happy for that to be in= -scope
> or out-of-scope for a first WG on this. Re, "from your conve= rsations and
> presentations (not from this document)," you raise a very fair > point.  Although the original ask was not to put "everything= " into a single
> Internet Draft, putting "everything" into a single Internet = Draft seems like a
> great idea, so I'll aim to do that with v01.
>
> Regarding "months later," this seems to be at least a mild e= xaggeration as the
> meeting was one month ago tomorrow.
>
> Regarding "all in a non-verifiable manner," I thought counti= ng phishing
> websites would be easy enough for anyone who really wanted to test a > hypothesis instead of standing on rhetoric.  PhishLabs seemed to = manage
> that OK.  I haven't counted all of the https sites in PhishTank y= et, but at first
> glance the fraction seems substantial.  Admittedly, not all of th= e data is
> directly verifiable, nor did I ever promised that _all_ of the data wo= uld be
> directly verifiable, but counting phishing sites seemed easy enough.&n= bsp; Please
> LMK if I'm wrong on that point.  The other sources seem to corrob= orate each
> other.
>
> Regarding posting to the "Threat Response Blog," we'll consi= der that, but the
> ask to us was to share more data here so we brought the data here as > requested.
>
> As a side comment, I'd also note the use of pejorative phrasing. = "argues for
> the mitm attacks on https," . It seems that you're calling "= network based
> blocking of malicious webpages" an "attack" when the bl= ocking is actually
> blocking the server's _attack_ against the client.  Where I choos= e to have a
> network proxy protect from evil on the net, I don't consider that prox= y to be
> attacking me.  I consider that proxy to be protecting me, and man= y
> organizations manage keys accordingly.  We see more and more peop= le
> needing network help in protecting themselves from such attacks, as la= id out
> in (1) through (5) above.  I look forward to your feedback there.=
>
> Thank you again -
>
> Cheers,
> Brian
>
>
> From: Brian Witten
> Sent: Wednesday, December 13, 2017 3:55 PM
> To: patient@ietf.org
> Subject: Internet Draft posted as requested -
>
>
> Hi Everyone,
>
> With the Wired article last week (  https://clicktime.symantec.com/a/1/rIiJXLn_RcL6DO1kshrfRFngO-jzXx2qnw5My1Gm= x-4=3D?d=3DacDp1ppr8wHdxscIO4PLDe8sLDUJcnfHSz2clVZzWLBTyzbkEl4RaUhyHkZYo10t= yNBxxnXDlN2oWb07cBnksNldu3BSjflTGgm5HQghRGGbipD3c7Nl4rUJ2U65HmVxzWgiiV0Ynq0= kqVwskgbtycb-DcPW4Q3IIx1qQwmT66LrRpGVItWeSOY1eY-KLO-F4N7fwc8Z3FJyaKcxhdPsTn= 4TFe6OkX9MgQJsjXttvbHcoHr_hM1GRoT_HmfV-KyYQemM7RzNkRbb2ES1NQp2v_mmPoMGPwDdP= xkuJKGsPg-FY6EFpCQ3EcmayeK9TZhaFUUhH01VFcgm_8Qqb8bYf2vbBDgj-8y_rzqcJ1TA_bvP= fjlxvEzOps0yNQl9DH26gAGK9GM5MXxDEZc5xAocAyQ%3D&u=3Dhttps%3A%2F%2Fwww.wi= red.com%2Fstory%2Fphishing-
> schemes-use-encrypted-sites-to-seem-legit/ ) ... I wanted to get the > Internet Draft ( https://clicktime.symantec.com/a/1/1E0rtJCkJI3RRVQJh91qEecCADHsunsL3_elUVce= Q0k=3D?d=3DacDp1ppr8wHdxscIO4PLDe8sLDUJcnfHSz2clVZzWLBTyzbkEl4RaUhyHkZYo10t= yNBxxnXDlN2oWb07cBnksNldu3BSjflTGgm5HQghRGGbipD3c7Nl4rUJ2U65HmVxzWgiiV0Ynq0= kqVwskgbtycb-DcPW4Q3IIx1qQwmT66LrRpGVItWeSOY1eY-KLO-F4N7fwc8Z3FJyaKcxhdPsTn= 4TFe6OkX9MgQJsjXttvbHcoHr_hM1GRoT_HmfV-KyYQemM7RzNkRbb2ES1NQp2v_mmPoMGPwDdP= xkuJKGsPg-FY6EFpCQ3EcmayeK9TZhaFUUhH01VFcgm_8Qqb8bYf2vbBDgj-8y_rzqcJ1TA_bvP= fjlxvEzOps0yNQl9DH26gAGK9GM5MXxDEZc5xAocAyQ%3D&u=3Dhttps%3A%2F%2Fwww.ie= tf.org%2Fid%2Fdraft-witten-protectingendpoints-
> 00.txt ) posted publicly for others to comment sooner rather than late= r.  Of
> course, feel free to comment here on the list  or just me comment= s 1:1 at
> bwitten@symantec.com.  Thank You Either Way!
>
>
> https://clicktime.symantec.com/a/1/EZreXTnVcH4VO_SfwFt5e40fv5Kya02XGSioz4Hg= SnQ=3D?d=3DacDp1ppr8wHdxscIO4PLDe8sLDUJcnfHSz2clVZzWLBTyzbkEl4RaUhyHkZYo10t= yNBxxnXDlN2oWb07cBnksNldu3BSjflTGgm5HQghRGGbipD3c7Nl4rUJ2U65HmVxzWgiiV0Ynq0= kqVwskgbtycb-DcPW4Q3IIx1qQwmT66LrRpGVItWeSOY1eY-KLO-F4N7fwc8Z3FJyaKcxhdPsTn= 4TFe6OkX9MgQJsjXttvbHcoHr_hM1GRoT_HmfV-KyYQemM7RzNkRbb2ES1NQp2v_mmPoMGPwDdP= xkuJKGsPg-FY6EFpCQ3EcmayeK9TZhaFUUhH01VFcgm_8Qqb8bYf2vbBDgj-8y_rzqcJ1TA_bvP= fjlxvEzOps0yNQl9DH26gAGK9GM5MXxDEZc5xAocAyQ%3D&u=3Dhttps%3A%2F%2Fmedia.= wired.com%2Fphotos%2F5a25b22aa587381053b48abb%2F191%3A100%2Fpass
> /PhishingHTTPs-FeatureArt.jpg
>
> Phishing Schemes Are Using Encrypted Sites to Seem Legit
> www.wired.com
> A green padlock might make it seem like a site is secure, but increasi= ngly
> phishers are using it to lure victims into giving up sensitive info. >
> Looking Forward,
> Brian
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://clicktime.symantec.com/a/1/8r1dfpQVPaT0ym4x10d1AoBGkiwLzbkySDbKaq-1= M2Q=3D?d=3DacDp1ppr8wHdxscIO4PLDe8sLDUJcnfHSz2clVZzWLBTyzbkEl4RaUhyHkZYo10t= yNBxxnXDlN2oWb07cBnksNldu3BSjflTGgm5HQghRGGbipD3c7Nl4rUJ2U65HmVxzWgiiV0Ynq0= kqVwskgbtycb-DcPW4Q3IIx1qQwmT66LrRpGVItWeSOY1eY-KLO-F4N7fwc8Z3FJyaKcxhdPsTn= 4TFe6OkX9MgQJsjXttvbHcoHr_hM1GRoT_HmfV-KyYQemM7RzNkRbb2ES1NQp2v_mmPoMGPwDdP= xkuJKGsPg-FY6EFpCQ3EcmayeK9TZhaFUUhH01VFcgm_8Qqb8bYf2vbBDgj-8y_rzqcJ1TA_bvP= fjlxvEzOps0yNQl9DH26gAGK9GM5MXxDEZc5xAocAyQ%3D&u=3Dhttps%3A%2F%2Fwww.ie= tf.org%2Fmailman%2Flistinfo%2Fsaag
--_000_MWHPR16MB14886D3C1CFE600F29918BA1930B0MWHPR16MB1488namp_-- From nobody Fri Dec 15 15:47:31 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651091242F5; Fri, 15 Dec 2017 15:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 QeV4pOWWkorg; Fri, 15 Dec 2017 15:47:23 -0800 (PST) Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (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 9F3141241FC; Fri, 15 Dec 2017 15:47:23 -0800 (PST) Received: by mail-qt0-x241.google.com with SMTP id e2so14133537qti.0; Fri, 15 Dec 2017 15:47:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xbfYDP0azV/MzBGTFmKQxgxG2jD5+mrGuocrDPD2PUM=; b=A/9T/jtumB5RO378xiNPNoNy4WEe0OTmc2juSBTw4jrAtxt75BGnGuKDpb1OG1+KQ0 UW1hnBLcgGhkEBhzr/gh2b2whmlKWNiySnUt6WIEhzlOBHwUc7OE2EYH9Sa905erbhW5 ZC/uhMJk715rgk9ZzhKvmaYkEiXkEQt4cQc1mzMmafPJUCpodCMOxwi0wKT+dGNIi1GW zA73Doh1DPLmVpVol5/iKkgA3bUwdSB/5GiatdLS2jcaNCd9WN8BrcYfdEWQRtQ6k1gK MUS9o+2ie+0ZFeGzVRUWrPygmUBlJAcqS+v7L7IfsSHEV8nxaIxcG7Isq02X1ZaYrcmV 5g0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xbfYDP0azV/MzBGTFmKQxgxG2jD5+mrGuocrDPD2PUM=; b=c9Oh716BS721rYi8sivaJhM1IZ4+OzyfFQ9gFaWnr2GG4ya4dTmQG5jMlPuvWUcD5A eHRmukVzuBLmFge++b52tp2IXiwmvno/UzM6+/6YbhB3GOl582p4FdzwSYKTL4rtfs8t WGwBP/kihS7ursy8rLdMFGsC7y8usn+CcdT8gtvRPT4FFOa2w/qzWP7rU7HiFA9Q2Zko mSm/hVUDvDl+7I1rMoE3u9UJFwDZZGc+Un/gG7XJkUmw8IRyfQyKOUGbJnl3x3Qonp5m pDK66c/xGbZC0+sawBp9jdgc9GTOLOLoqqZWJcIYnfyHkjo64f4GS4QD2U/29spSptvm W7uQ== X-Gm-Message-State: AKGB3mJGxdrzm1vfsee8d4s9TFzP1Z82D49AeV31WVlqfkF0F/7B4Inj CtnIodOkPrKpLURpAfdnQkPZ8+TZ3t0/nw== X-Google-Smtp-Source: ACJfBovAdfqJNad67xGp1KI/OKcBpB/GzlyJQLdb1/fkyB/emXOa3d/Y71aW9s5w/TUZJdbokvwsiw== X-Received: by 10.237.36.119 with SMTP id s52mr24450464qtc.199.1513381642651; Fri, 15 Dec 2017 15:47:22 -0800 (PST) Received: from ?IPv6:2605:a601:3116:8400:5557:213a:958c:1162? ([2605:a601:3116:8400:5557:213a:958c:1162]) by smtp.gmail.com with ESMTPSA id w41sm4708320qtc.19.2017.12.15.15.47.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 15:47:21 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Bret Jordan In-Reply-To: Date: Fri, 15 Dec 2017 16:47:17 -0700 Cc: "patient@ietf.org" , "saag@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Witten X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [saag] [Patient] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 23:47:26 -0000 Brian, This is great. Thanks for taking the time to spell it out a bit more. = The points you bring up are important and things we as a community need = to remember. =20 Bret > On Dec 14, 2017, at 15:58, Brian Witten = wrote: >=20 > Thank you everyone for your comments! >=20 > The request in Singapore for an Internet Draft seemed focused on an = ask for data, so I tried to keep the v00 focused on the data, and = concise to be easily read quickly, and I thought that I might be going = onto a limb beginning to present some of the logic, but it seems like = many are hungry for more of the logic (or "at least some logic" as they = might say) so I=E2=80=99ll present more of the logic. Of course, much = of the logic was presented in the near 40 slides sent earlier and = roughly 5 pages of Q&A, but I agree with the merits of centralizing all = of the logic in an Internet Draft, so I=E2=80=99ll aim to do that in the = v01, and, perhaps more importantly, I also hear clearly some of the = concerns on how the logic was organized (or unorganized or disorganized = as some might say) in Singapore, so I=E2=80=99ll try to be more clearly = structured both here and in more detail in the v01. I=E2=80=99ll = comment on the solutioning further below, but since so many seem so = hungry for the logic, I=E2=80=99ll try present it relatively concisely = here so that discussion here can best shape the v01 which will pull from = the list, the slldes, and more. > =20 > The logic, in the short form of roughly five points would be: > ** (1) ** Endpoints have vulnerabilities. ( unfortunately lots of = them. For this part I believe there is overwhelming evidence, but = please LMK if you disagree. ) > ** (2) ** These vulnerabilities are often difficult (sometimes nearly = impossible) for device owners, users, etc, to mitigate =E2=80=9Cin=E2=80=9D= these endpoints. ( this is true today for countless devices, and = increasingly true for increasingly closed devices, particularly in IOT = and mobile. ) > ** (3) ** For that reason, those endpoint owners/users/etc often need = to put some =E2=80=9Cthing=E2=80=9D in the network to mitigate those = endpoint vulnerabilities. > ** (4) ** For that to be effective (against attacks in encrypted = traffic), that =E2=80=9Cthing=E2=80=9D needs keys to inspect the = encrypted traffic. ( This can be done any of many ways, as it=E2=80=99s = done today. ) > ** (5) ** Where that=E2=80=99s done today, it can be done much more = safely, therefore we should spec standards for how to do it more safely. = ( Lots of ideas have been published in research, and I include some = details on that further below, but maturing the right ones and baking = them into a standard is of course typically a =E2=80=9Cbigger group=E2=80=9D= effort. ) > =20 > In that framework, I=E2=80=99d love to know which of these 5 points = above (if any) are agreeable to you, and which specifically you believe = are either simply dead wrong or the right-best focus of constructive = discussion. For some it seems that point (3) above is the most = controversial, but others are already asking the details of (5) which is = where the slides focused, but the v01 will of course cover both in = depth, and, as promised, I'll give some points on (5) below. > =20 > On the solutioning, as mentioned at the side-meeting, lots of = solutions have been proposed in research communities, but I believe = it=E2=80=99s important to get aligned on the problems we=E2=80=99re = solving as a community before picking a solution. As mentioned at the = side-meeting, solutions proposed by the research community include = Stickler by Boneh & team at Stanford, plus the unfortunately named mcTLS = and mbTLS efforts, and more, but I believe it=E2=80=99s important to get = aligned on the problems we=E2=80=99re solving as a community before = picking a solution. Once we=E2=80=99re aligned on (1) through (5) above = then it makes more sense to get into the specific problems with (4) = which (5) tries to address, including (a) retaining end-to-end = integrity, (b) giving endpoints more precise control over when, where, = and how such protection is delivered from the network, in strong = contrast today=E2=80=99s all-or-nothing just-install-a-root approach. > =20 > To address some of the other important questions and concerns raised = over the past day=E2=80=A6 > =20 > Re, =E2=80=9Cdoes not specify a new protocol,=E2=80=9D many of the = potential/candidate protocols were mentioned at the side-meeting, in the = notes of the side-meeting, in the slides presented at the side-meeting, = and in the email to announce the side-meeting, but I=E2=80=99m happy to = add them to the v01 to keep everything together in a single Internet = Draft. For context, as Stephen pointed out, his ask was not for an = Internet Draft of a protocol, but for the data (and logic) of why it = might help to spec a new and/or additional protocol. Re, =E2=80=9CIt = does not specify a concrete problem (use cases),=E2=80=9D again these = were mentioned at the side-meeting, in the notes of the side-meeting, in = the slides presented at the side-meeting, and in the email to announce = the side-meeting, but I=E2=80=99m happy to add them to the v01 to keep = everything together in a single Internet Draft. >=20 > Re, =E2=80=9CIt does not specify any kind of architecture,=E2=80=9D as = above, covered before, but I=E2=80=99m happy to add it to the v01 of an = Internet Draft to get everything together in a single Internet Draft. = These seem like constructive requests, even if the material was covered = elsewhere already. Thank You Again! >=20 > Similarly, if anything is missing from the notes, I=E2=80=99m eager to = be sure this discussion fairly and deeply captures _all_ views, = particularly opposing views, so where there are gaps in the 7 pages of = notes we took, those gaps are absolutely not intentional. I=E2=80=99m = eager to see any omissions rectified, so please send any additions, = corrections, etc, either to this list or to me personally. Either way, = I=E2=80=99m eager to be sure everyone sees all views and hears all = concerns and that all of those concerns are included and/or addressed = somehow in a v01. >=20 > Re, =E2=80=9Cpervasive monitoring should make way for network based = monitoring,=E2=80=9D I wasn=E2=80=99t trying to say that and in fact, = from the slides you can clearly tell that PATIENT is aiming to more = completely block pervasive monitoring. Crypto helps block pervasive = monitoring by listeners in the network. Pervasive monitoring is also = possible by hacking all the endpoints, and as presented in the = side-meeting, we have ample evidence of nation-states attempting to do = this. PATIENT aims to make safer prevention of the latter approach to = pervasive monitoring. >=20 > Re, =E2=80=9Cdraft-mm-wg-effect-encrypt,=E2=80=9D you=E2=80=99re = absolutely right, and I=E2=80=99ll cite that work in the v01 for = precisely those reasons. In fact, my aim is to (eventually, after we = get aligned on scope, etc,) design a protocol that allows network = security appliances to yet more safely work hand-in-hand with pervasive = encryption. I=E2=80=99m not trying to push back against pervasive = encryption at all. I suspect I might have to keep repeating myself on = that until people believe it? >=20 > Re, =E2=80=9CSo far, I am still not convinced that a SOCKS proxy =E2=80=A6= connected via a VPN, is not sufficient to filter out malicious data.=E2=80= =9D I believe connecting proxies via VPN is a great way to help block = malicious data. I=E2=80=99m also not debating the type of proxy to be = used. As you know, and as the slides say, and as the v01 will say, = I=E2=80=99m saying that when proxies change stuff, it would help for the = endpoint to know which proxy changed what where. Stickler helps with = that. I think it also helps for endpoints to know more about the proxy = on the other side of the VPN, but I=E2=80=99d be happy for that to be = in-scope or out-of-scope for a first WG on this. Re, =E2=80=9Cfrom your = conversations and presentations (not from this document),=E2=80=9D you = raise a very fair point. Although the original ask was not to put = =E2=80=9Ceverything=E2=80=9D into a single Internet Draft, putting = =E2=80=9Ceverything=E2=80=9D into a single Internet Draft seems like a = great idea, so I=E2=80=99ll aim to do that with v01. >=20 > Regarding =E2=80=9Cmonths later,=E2=80=9D this seems to be at least a = mild exaggeration as the meeting was one month ago tomorrow. >=20 > Regarding =E2=80=9Call in a non-verifiable manner,=E2=80=9D I thought = counting phishing websites would be easy enough for anyone who really = wanted to test a hypothesis instead of standing on rhetoric. PhishLabs = seemed to manage that OK. I haven=E2=80=99t counted all of the https = sites in PhishTank yet, but at first glance the fraction seems = substantial. Admittedly, not all of the data is directly verifiable, = nor did I ever promised that _all_ of the data would be directly = verifiable, but counting phishing sites seemed easy enough. Please LMK = if I=E2=80=99m wrong on that point. The other sources seem to = corroborate each other. >=20 > Regarding posting to the =E2=80=9CThreat Response Blog,=E2=80=9D = we=E2=80=99ll consider that, but the ask to us was to share more data = here so we brought the data here as requested. >=20 > As a side comment, I=E2=80=99d also note the use of pejorative = phrasing. =E2=80=9Cargues for the mitm attacks on https,=E2=80=9D =E2=80=A6= It seems that you=E2=80=99re calling =E2=80=9Cnetwork based blocking of = malicious webpages=E2=80=9D an =E2=80=9Cattack=E2=80=9D when the = blocking is actually blocking the server's _attack_ against the client. = Where I choose to have a network proxy protect from evil on the net, I = don=E2=80=99t consider that proxy to be attacking me. I consider that = proxy to be protecting me, and many organizations manage keys = accordingly. We see more and more people needing network help in = protecting themselves from such attacks, as laid out in (1) through (5) = above. I look forward to your feedback there. > =20 > Thank you again - >=20 > Cheers, > Brian >=20 >=20 > From: Brian Witten > Sent: Wednesday, December 13, 2017 3:55 PM > To: patient@ietf.org > Subject: Internet Draft posted as requested - > =20 >=20 > Hi Everyone, >=20 > With the Wired article last week ( = https://www.wired.com/story/phishing-schemes-use-encrypted-sites-to-seem-l= egit/ ) ... I wanted to get the Internet Draft ( = https://www.ietf.org/id/draft-witten-protectingendpoints-00.txt ) posted = publicly for others to comment sooner rather than later. Of course, = feel free to comment here on the list or just me comments 1:1 at = bwitten@symantec.com. Thank You Either Way! >=20 > = https://media.wired.com/photos/5a25b22aa587381053b48abb/191:100/pass/Phish= ingHTTPs-FeatureArt.jpg=20 >=20 > Phishing Schemes Are Using Encrypted Sites to Seem Legit > www.wired.com > A green padlock might make it seem like a site is secure, but = increasingly phishers are using it to lure victims into giving up = sensitive info. >=20 > Looking Forward, > Brian > =20 > _______________________________________________ > PATIENT mailing list > PATIENT@ietf.org > https://www.ietf.org/mailman/listinfo/patient From nobody Sat Dec 16 07:27:45 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4540C1250B8; Sat, 16 Dec 2017 07:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 Iwd5XGNeko0t; Sat, 16 Dec 2017 07:27:36 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386E0120721; Sat, 16 Dec 2017 07:27:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 03AECBE2E; Sat, 16 Dec 2017 15:27:34 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTIB9cBRUonF; Sat, 16 Dec 2017 15:27:32 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C59BBBE24; Sat, 16 Dec 2017 15:27:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1513438052; bh=RZvbobyTiOWIl2idTvxIGHW9lRH1ggyTSdFI218jArM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=oT3Dwz+2DCTolj8XJ2b3ZzQ8iRuQwMu7OsO56zaSWAjBgirdxGtRPvtY9w4iFOJLC z1Ws99UajaKjLKf+YiyoNZ5mB+tMu0AkGSXr6bf2yyDxrBYWHULTA130jK/5Pf/utU Yrroi+0NuZDPR1fOkjtodechcoCG+ImwWyAEm7qI= To: Brian Witten , "patient@ietf.org" , "saag@ietf.org" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sat, 16 Dec 2017 15:27:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dIcS9xb3qu5wDUlc6brBADEMUFNvdkWvC" Archived-At: Subject: Re: [saag] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 15:27:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dIcS9xb3qu5wDUlc6brBADEMUFNvdkWvC Content-Type: multipart/mixed; boundary="qJUrGMFgMMdk1Cu3b07q0oWgGg6O7BbDS"; protected-headers="v1" From: Stephen Farrell To: Brian Witten , "patient@ietf.org" , "saag@ietf.org" Message-ID: Subject: Re: [saag] Internet Draft posted as requested - References: In-Reply-To: --qJUrGMFgMMdk1Cu3b07q0oWgGg6O7BbDS Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 14/12/17 22:58, Brian Witten wrote: > The logic, in the short form of roughly five points would be: Let's see if there is or is not logic to be found... > ** (1) > ** Endpoints have vulnerabilities. ( unfortunately lots of them. > For this part I believe there is overwhelming evidence, but please > LMK if you disagree. )=20 That's incomplete to the point of being misleading. Middleboxes are as likely to have bugs. And if those are mitm'ing many https connections the impact of a problem is higher than for the client side. Probably also higher impact for most instances of servers too. And the mitms are certainly in a position to mitm connections to high-value servers (if they can do one they can do all) so all mitm code bugs could argued to be worse than endpoint bugs. > ** (2) ** These vulnerabilities are often > difficult (sometimes nearly impossible) for device owners, users, > etc, to mitigate =E2=80=9Cin=E2=80=9D these endpoints. ( this is true t= oday for > countless devices, and increasingly true for increasingly closed > devices, particularly in IOT and mobile. )=20 Where's the evidence for that? What percentage is "often"? (Speaking about "countless" devices, is pure rhetorical noise and not useful if you are honestly trying to provide verifiable evidence.) Why would middleboxes be easier to patch? It seems from many anecdotes (I'd love to see real numbers), that at least browsers and web servers these days are managed much better in terms of updates. > ** (3) ** For that reason, > those endpoint owners/users/etc often need to put some =E2=80=9Cthing=E2= =80=9D in the > network to mitigate those endpoint vulnerabilities. **=20 That's simply false. Even if I accepted your stated and flawed premises, the above still doesn't follow at all. Just to call out your flawed logic in one way: buggy difficult to fix clients *could* be fixed or replaced over time, so your claim that a mitm middlebox is *needed* is obviously false. > (4) ** For > that to be effective (against attacks in encrypted traffic), that > =E2=80=9Cthing=E2=80=9D needs keys to inspect the encrypted traffic. (= This can be > done any of many ways, as it=E2=80=99s done today. )=20 Also clearly incorrect. See [1] (recently quoted by Martin T on some other list) for a proof that your claim that this is *needed* is also just false. [1] https://arxiv.org/abs/1607.01639 > ** (5) ** Where that=E2=80=99s > done today, it can be done much more safely, therefore we should spec > standards for how to do it more safely. ( Lots of ideas have been > published in research, and I include some details on that further > below, but maturing the right ones and baking them into a standard is > of course typically a =E2=80=9Cbigger group=E2=80=9D effort. ) Afaics all of those approaches are inherently flawed and consider it someone reasonable that a human can decide when to trust a random name/address that claims to be "good." None (i.e. zero) of the approaches proposed would improve the overall environment and therefore none (i.e. zero) of those ought be standardised. So overall it seems flawed premises, incorrect logic, and your -00's lack of relevant data leave us right back where we started having to deal with risible claims such as this: > Re, "inserted without any form of knowledge or authorization by > the endpoint," in fact, PATIENT aims to establish a protocol whereby > end-users get visibility into ALL of the "things" (middleboxes) > monitoring the communications. Just for a laugh, I loaded [2] in a default setup browser (chromium). Among the 269 http requests that caused was [3]. Are you (Brian) seriously trying to claim that you actually believe that a random person can sensibly decide 269 times if 2001:db8::bad:1dea ought be allowed to mitm that connection? That is not something I find a credible assertion, so I'm left with the belief that the quoted text above aims to be a snow-job of some kind. And while a snow-job may be seasonal for the next few weeks, it is not a basis on which the IETF ought do anything except brush the snow-job aside. S [2] https://www.symantec.com/ [3] https://fei.pro-market.net/engine?du=3D24;csync=3D8A149905A638355A509A770= D02460917;mimetype=3Dimg;sr --qJUrGMFgMMdk1Cu3b07q0oWgGg6O7BbDS-- --dIcS9xb3qu5wDUlc6brBADEMUFNvdkWvC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaNTtjAAoJEC88hzaAX42iQ5MH+gL4VmvgqnImT7gTAEwKXonC fr+kptdjROfjBNq28STIU/mEAuC0XF7ZEKXUw5Zom0tbBj0Le6lxX7jTih6lFvyS 1gN6M6TuWUqxe+ckDsvjWwIaPBihE4bJEcasnARwAQP2uw1v1xp6vAEvwMEfzZ9N 20PN6fc5vCELR/RL9Oa/686F2Q7phdxAUSCmu++n/2n/C0pawajOv1DHCLEVBwWz TKAbKw1c8Z7zhwp69/IHW0ptahJHJxCNeSktG1frzygpCfBcP7RO4+jxWL2JGIZA WnkU4XE/VevhG9EpH2/BQnEWr3Vo23zx6txiP3ef4IwB2CQnFSSaUh4CUzOoP6Y= =7Gm3 -----END PGP SIGNATURE----- --dIcS9xb3qu5wDUlc6brBADEMUFNvdkWvC-- From nobody Sun Dec 17 15:19:28 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242C3126BF0; Sun, 17 Dec 2017 15:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 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 lW0vQ-ImiFgl; Sun, 17 Dec 2017 15:19:17 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr60126.outbound.protection.outlook.com [40.107.6.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 6DB3F124234; Sun, 17 Dec 2017 15:19:16 -0800 (PST) Received: from AM5PR0602MB3251.eurprd06.prod.outlook.com (10.167.170.156) by AM5PR0602MB3249.eurprd06.prod.outlook.com (10.167.170.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Sun, 17 Dec 2017 23:19:12 +0000 Received: from AM5PR0602MB3251.eurprd06.prod.outlook.com ([fe80::5e9:e441:e61f:7696]) by AM5PR0602MB3251.eurprd06.prod.outlook.com ([fe80::5e9:e441:e61f:7696%13]) with mapi id 15.20.0323.018; Sun, 17 Dec 2017 23:19:12 +0000 From: "Diego R. Lopez" To: Stephen Farrell , Brian Witten , "patient@ietf.org" , "saag@ietf.org" Thread-Topic: [Patient] [saag] Internet Draft posted as requested - Thread-Index: AQHTdG3n75b66muaQUWJ0xAs2sVGYqNDdU+AgAKmnICAAibggA== Date: Sun, 17 Dec 2017 23:19:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.8.0.171210 authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-originating-ip: [83.42.130.160] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0602MB3249; 6:vtziawqOVz4R/XwMHm3w+AwX871spl5OW5oPzI0KJlBvhF84P2+Z94AdNN+OCMissrffXA+F6xKGs2XO6yfNzS5ep7OyzYQTaBrJXuIOdLIwEiUxwM+P7rYkx/fPwNU6I6EnMWwkdUxt6IxI8pzKLLj3XzeDLI5Akukape5WfOCLaVTbAohizj7tExgD3L84vgzCvKI/++Uiq299dSLt0H4jO21j+CAEOGVdb5m4+g7nhADSD+k9YTdM5/BWWLSXT9GXjU16fpJBrHkABZiUVu2ps6P7QGFN5r8YVd0matg/ftXb2WJdUXQE2jEARufVJan7NvNjRGgVgy+9jPXLwInms/Qb2ejaSphT3oRPWZY=; 5:OEGAF+q16cYax2NG+5rrObQtuFHRsZuVCqk+WydZ/JwcAdlwNS3l348yjjKkO5grJ1doaZsE/li0QR9uxYZBOJ0TQkvfNY2O7IR9/BKMXCglhL4f77AmOjmpfYU3LeE3ZY2sUtLJydbUkTu3A9ubN/6PagIJXmk9o9SwHkPqrKg=; 24:IVzaMWzIRlm7aiOXnuB7BuA09QHGJ8JNWI09tojkdb4x5YtUnDUYvv5AD2aE4fS5wrAeZ5K2zhVMRFbK2ioBtbW9UXjNvOu3IkYcnN5ecmk=; 7:7u8WbdB7pvJrsPD0A8rN87uFSrmtctVLxPZpX3NMsUG614nxL90ojgdeBGsiyJD4Tk20ygD4tfI8y2jHQvj069vJI9im3uSTMyxQpYUpfyXxKUJ/Oanbj3fq7oHJk9aiAPdf+9OOlTZ9JKxPdcGKUJaHJcI8flUSZl5dcRhaTcYHQGSqC3SwESP00DcQUFZxLdzqe60txODVrupdQvveTw1T4y328VAEchLJcwOJXqlx8Lry6gtN7IY9d6wIBA79 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 37e5416c-d067-4278-7657-08d545a4955a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603307); SRVR:AM5PR0602MB3249; x-ms-traffictypediagnostic: AM5PR0602MB3249: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(40392960112811)(127643986962959)(128460861657000)(21748063052155)(81160342030619); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231023)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(20161123564025)(6072148)(201708071742011); SRVR:AM5PR0602MB3249; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM5PR0602MB3249; x-forefront-prvs: 05245CA661 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(366004)(396003)(376002)(252514010)(189003)(40134004)(24454002)(199004)(25724002)(33656002)(3280700002)(68736007)(8936002)(97736004)(105586002)(106356001)(2950100002)(99286004)(66066001)(5660300001)(76176011)(3660700001)(93886005)(606006)(25786009)(54896002)(6306002)(6486002)(2906002)(6436002)(53936002)(7736002)(59450400001)(8676002)(478600001)(86362001)(14454004)(6506007)(5250100002)(53546011)(81156014)(81166006)(966005)(2501003)(110136005)(6512007)(236005)(83506002)(82746002)(316002)(102836003)(3846002)(2201001)(6116002)(83716003)(58126008)(229853002)(786003)(45080400002)(6246003)(2900100001)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0602MB3249; H:AM5PR0602MB3251.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AF4C62E061AB45DBB3E656AB67A1070Atelefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-Network-Message-Id: 37e5416c-d067-4278-7657-08d545a4955a X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2017 23:19:12.4698 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0602MB3249 Archived-At: Subject: Re: [saag] [Patient] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Dec 2017 23:19:22 -0000 --_000_AF4C62E061AB45DBB3E656AB67A1070Atelefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 77u/SGksDQoNCg0KDQpGaXJzdCBvZiBhbGwsIGxldCBtZSBzYXkgSSBhbSBnbGFkIHRvIHNlZSB0 aGlzIGRpc2N1c3Npb24gcmVvcGVuZWQsIGFuZCBnbGFkIHRvIHNlZSBhcyB3ZWxsIHNvbWUgcHJv cG9zYWxzIHRoYXQgc291bmQgbW9yZSBjb25zdHJ1Y3RpdmUgdGhhbiB0aGUgdXN1YWwgcmVsaWdp b3VzIGVudHJlbmNobWVudHMgdGhhdCBhcmUgc28gY29tbW9uIGluIHRoaXMgZnJvbnQsIGVzcGVj aWFsbHkgd2hlbiBJIHNlZSBjZXJ0YWluIGFja25vd2xlZGdlbWVudCB3ZSBhcmUgbm90IG5lY2Vz c2FyaWx5IHRhbGtpbmcgb2YgbWl0bS1pbmcsIGFuZCB3ZSBhcmUgbm90IG9ubHkgdGFsa2luZyBh Ym91dCBIVFRQUyBhbmQvb3Igd2ViIGFjY2Vzcy4gSXQgaXMgYWJvdXQgZXhwbG9yaW5nIHRoZSBz b2x1dGlvbiBzcGFjZSBmb3IgbmV0d29yay1ob3N0ZWQgZGV2aWNlIHByb3RlY3Rpb24gaW4gYSBu ZXR3b3JrIHdpdGggd2lkZXNwcmVhZCAoT0ssIGxldCdzIG5vdCB1c2UgInBlcnZhc2l2ZSIpIHVz ZSBvZiBlbmQtdG8tZW5kIGVuY3J5cHRpb24uDQoNCg0KDQpUaGlzIHNhaWQsIHRoZXJlIGEgZmV3 IHBvaW50cyBJJ2QgbGlrZSB0byBtYWtlIGluIHJlc3BvbnNlIHRvIFN0ZXBoZW4ncyBjb21tZW50 cy4uLg0KDQoNCg0KT24gMTYvMTIvMjAxNywgMTY6MjcsICJQQVRJRU5UIG9uIGJlaGFsZiBvZiBT dGVwaGVuIEZhcnJlbGwiIDxwYXRpZW50LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHN0 ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+IHdyb3RlOg0KDQoNCg0KICAgIE9uIDE0LzEyLzE3IDIy OjU4LCBCcmlhbiBXaXR0ZW4gd3JvdGU6DQoNCiAgICA+IFRoZSBsb2dpYywgaW4gdGhlIHNob3J0 IGZvcm0gb2Ygcm91Z2hseSBmaXZlIHBvaW50cyB3b3VsZCBiZToNCg0KDQoNCiAgICBMZXQncyBz ZWUgaWYgdGhlcmUgaXMgb3IgaXMgbm90IGxvZ2ljIHRvIGJlIGZvdW5kLi4uDQoNCg0KDQogICAg PiAqKiAoMSkNCg0KICAgID4gKiogRW5kcG9pbnRzIGhhdmUgdnVsbmVyYWJpbGl0aWVzLiAgKCB1 bmZvcnR1bmF0ZWx5IGxvdHMgb2YgdGhlbS4NCg0KICAgID4gRm9yIHRoaXMgcGFydCBJIGJlbGll dmUgdGhlcmUgaXMgb3ZlcndoZWxtaW5nIGV2aWRlbmNlLCBidXQgcGxlYXNlDQoNCiAgICA+IExN SyBpZiB5b3UgZGlzYWdyZWUuICkNCg0KDQoNCiAgICBUaGF0J3MgaW5jb21wbGV0ZSB0byB0aGUg cG9pbnQgb2YgYmVpbmcgbWlzbGVhZGluZy4gTWlkZGxlYm94ZXMNCg0KICAgIGFyZSBhcyBsaWtl bHkgdG8gaGF2ZSBidWdzLiBBbmQgaWYgdGhvc2UgYXJlIG1pdG0naW5nIG1hbnkgaHR0cHMNCg0K ICAgIGNvbm5lY3Rpb25zIHRoZSBpbXBhY3Qgb2YgYSBwcm9ibGVtIGlzIGhpZ2hlciB0aGFuIGZv ciB0aGUgY2xpZW50DQoNCiAgICBzaWRlLiBQcm9iYWJseSBhbHNvIGhpZ2hlciBpbXBhY3QgZm9y IG1vc3QgaW5zdGFuY2VzIG9mIHNlcnZlcnMNCg0KICAgIHRvby4gQW5kIHRoZSBtaXRtcyBhcmUg Y2VydGFpbmx5IGluIGEgcG9zaXRpb24gdG8gbWl0bSBjb25uZWN0aW9ucw0KDQogICAgdG8gaGln aC12YWx1ZSBzZXJ2ZXJzIChpZiB0aGV5IGNhbiBkbyBvbmUgdGhleSBjYW4gZG8gYWxsKSBzbyBh bGwNCg0KICAgIG1pdG0gY29kZSBidWdzIGNvdWxkIGFyZ3VlZCB0byBiZSB3b3JzZSB0aGFuIGVu ZHBvaW50IGJ1Z3MuDQoNCg0KDQpJcyBub3QgaGVyZSBhIGZsYXcgaW4geW91ciBsb2dpYz8gTm9i b2R5IGhhcyBtZW50aW9uZWQgbWlkZGxlYm94ZXMgKG9yIOKAnHRoaW5nc+KAnSwgYXMgdGhleSBo YXZlIGNhbGxlZCBiZWxvdykgeWV04oCmDQoNCg0KDQogICAgPiAqKiAoMikgKiogVGhlc2UgdnVs bmVyYWJpbGl0aWVzIGFyZSBvZnRlbg0KDQogICAgPiBkaWZmaWN1bHQgKHNvbWV0aW1lcyBuZWFy bHkgaW1wb3NzaWJsZSkgZm9yIGRldmljZSBvd25lcnMsIHVzZXJzLA0KDQogICAgPiBldGMsIHRv IG1pdGlnYXRlIOKAnGlu4oCdIHRoZXNlIGVuZHBvaW50cy4gKCB0aGlzIGlzIHRydWUgdG9kYXkg Zm9yDQoNCiAgICA+IGNvdW50bGVzcyBkZXZpY2VzLCBhbmQgaW5jcmVhc2luZ2x5IHRydWUgZm9y IGluY3JlYXNpbmdseSBjbG9zZWQNCg0KICAgID4gZGV2aWNlcywgcGFydGljdWxhcmx5IGluIElP VCBhbmQgbW9iaWxlLiApDQoNCg0KDQogICAgV2hlcmUncyB0aGUgZXZpZGVuY2UgZm9yIHRoYXQ/ IFdoYXQgcGVyY2VudGFnZSBpcyAib2Z0ZW4iPw0KDQogICAgKFNwZWFraW5nIGFib3V0ICJjb3Vu dGxlc3MiIGRldmljZXMsIGlzIHB1cmUgcmhldG9yaWNhbA0KDQogICAgbm9pc2UgYW5kIG5vdCB1 c2VmdWwgaWYgeW91IGFyZSBob25lc3RseSB0cnlpbmcgdG8gcHJvdmlkZQ0KDQogICAgdmVyaWZp YWJsZSBldmlkZW5jZS4pDQoNCg0KDQpUaGUgbW9zdCByZWNlbnQgSSBoYXZlIGZvdW5kIGlzIGhl cmU6IGh0dHBzOi8vZGFubHV1LmNvbS9hbmRyb2lkLXVwZGF0ZXMvIC4gSXQgb25seSByZWZlcnMg dG8gQW5kcm9pZCBkZXZpY2VzLCB0aG91Z2ggaXQgbWVudGlvbnMgb3RoZXIgc3lzdGVtcyBhcyBX aW5kb3dzIFhQLiBBbmQgaXQgZG9lcyBub3QgdGFrZSBpbnRvIGFjY291bnQgSW9UIGRldmljZXMs IHRvIG5hbWUgYW5vdGhlciBjYXRlZ29yeS4gTWF5IGJlIGFsbCBvZiB0aG9zZSBhcmUgbm90IOKA nGNvdW50bGVzc+KAnSwgYnV0IGl0IG1ha2VzIHRoZSB1c2Ugb2YgdGhlIHdvcmQgYSByZWFzb25h Ymx5IGFjY3VyYXRlIGZpZ3VyZSBvZiBzcGVlY2ggYW55d2F5Lg0KDQoNCg0KICAgIFdoeSB3b3Vs ZCBtaWRkbGVib3hlcyBiZSBlYXNpZXIgdG8gcGF0Y2g/IEl0IHNlZW1zIGZyb20gbWFueQ0KDQog ICAgYW5lY2RvdGVzIChJJ2QgbG92ZSB0byBzZWUgcmVhbCBudW1iZXJzKSwgdGhhdCBhdCBsZWFz dCBicm93c2Vycw0KDQogICAgYW5kIHdlYiBzZXJ2ZXJzIHRoZXNlIGRheXMgYXJlIG1hbmFnZWQg bXVjaCBiZXR0ZXIgaW4gdGVybXMgb2YNCg0KICAgIHVwZGF0ZXMuDQoNCg0KDQpJIGNhbm5vdCBz cGVhayBmb3Igb3RoZXIgcGVvcGxlIHN1cHBvcnRpbmcgdGhpcywgYnV0IHdlIGhhdmUgbm90IGlu IG1pbmQgb25seSB3ZWIgYnJvd3NlcnMgb3Igd2ViIGFjY2VzcyB1c2UgY2FzZXMuIEkgcmVtZW1i ZXIgY29uc3RyYWluZWQgZGV2aWNlcyB3ZXJlIG1lbnRpb25lZCBhIGNvdXBsZSBvZiB0aW1lcyBp biBTaW5nYXBvcmUuDQoNCg0KDQogICAgPiAqKiAoMykgKiogRm9yIHRoYXQgcmVhc29uLA0KDQog ICAgPiB0aG9zZSBlbmRwb2ludCBvd25lcnMvdXNlcnMvZXRjIG9mdGVuIG5lZWQgdG8gcHV0IHNv bWUg4oCcdGhpbmfigJ0gaW4gdGhlDQoNCiAgICA+IG5ldHdvcmsgdG8gbWl0aWdhdGUgdGhvc2Ug ZW5kcG9pbnQgdnVsbmVyYWJpbGl0aWVzLiAqKg0KDQoNCg0KICAgIFRoYXQncyBzaW1wbHkgZmFs c2UuIEV2ZW4gaWYgSSBhY2NlcHRlZCB5b3VyIHN0YXRlZCBhbmQgZmxhd2VkDQoNCiAgICBwcmVt aXNlcywgdGhlIGFib3ZlIHN0aWxsIGRvZXNuJ3QgZm9sbG93IGF0IGFsbC4gSnVzdCB0byBjYWxs DQoNCiAgICBvdXQgeW91ciBmbGF3ZWQgbG9naWMgaW4gb25lIHdheTogYnVnZ3kgZGlmZmljdWx0 IHRvIGZpeCBjbGllbnRzDQoNCiAgICAqY291bGQqIGJlIGZpeGVkIG9yIHJlcGxhY2VkIG92ZXIg dGltZSwgc28geW91ciBjbGFpbSB0aGF0DQoNCiAgICBhIG1pdG0gbWlkZGxlYm94IGlzICpuZWVk ZWQqIGlzIG9idmlvdXNseSBmYWxzZS4NCg0KDQoNCk9LLiBNYXkgYmUg4oCcbmVlZOKAnSBpcyBh IHRvbyBzdHJvbmcgd29yZCBoZXJlLCBhdCBsZWFzdCBpbiB0aGUgZ2VuZXJhbCBjYXNlIChub3Qg c3VyZSBhYm91dCBzb21lIGtpbmRzIG9mIGRldmljZXPigKYpLiBCdXQgbXkgb3duIGV4cGVyaWVu Y2UgYXMgdXNlciBpcyB0aGF0IOKAnGNhbiByZXF1aXJl4oCdIGlzLCBhZ2FpbiwgcmVhc29uYWJs eSBhY2N1cmF0ZQ0KDQoNCg0KICAgID4gKDQpICoqIEZvcg0KDQogICAgPiB0aGF0IHRvIGJlIGVm ZmVjdGl2ZSAoYWdhaW5zdCBhdHRhY2tzIGluIGVuY3J5cHRlZCB0cmFmZmljKSwgdGhhdA0KDQog ICAgPiDigJx0aGluZ+KAnSBuZWVkcyBrZXlzIHRvIGluc3BlY3QgdGhlIGVuY3J5cHRlZCB0cmFm ZmljLiAgKCBUaGlzIGNhbiBiZQ0KDQogICAgPiBkb25lIGFueSBvZiBtYW55IHdheXMsIGFzIGl0 4oCZcyBkb25lIHRvZGF5LiApDQoNCg0KDQogICAgQWxzbyBjbGVhcmx5IGluY29ycmVjdC4gU2Vl IFsxXSAocmVjZW50bHkgcXVvdGVkIGJ5IE1hcnRpbiBUIG9uIHNvbWUNCg0KICAgIG90aGVyIGxp c3QpIGZvciBhIHByb29mIHRoYXQgeW91ciBjbGFpbSB0aGF0IHRoaXMgaXMgKm5lZWRlZCogaXMg YWxzbw0KDQogICAganVzdCBmYWxzZS4NCg0KDQoNCiAgICBbMV0gaHR0cHM6Ly9hcnhpdi5vcmcv YWJzLzE2MDcuMDE2MzkNCg0KDQoNClRoaXMgaXMgYW4gaW50ZXJlc3RpbmcgcmVmZXJlbmNlLiBU aGFua3MgZm9yIHNlbmRpbmcgaXQuIEkgZ3Vlc3MgdGhpcyBraW5kIG9mIHNvbHV0aW9ucyBpcyBp biB0aGUgbWluZHMgb2YgbWFueSwgYW5kIHJlY29tbWVuZGF0aW9ucyBvbiB0aGVtIChpbmNsdWRp bmcgYSBzb3VuZCBiYXNlIG9mIGRhdGFzZXRzIGZvciB0cmFpbmluZyBhbmQgdmFsaWRhdGlvbiwg YXMgSSBoYXZlIG1lbnRpb25lZCBlbHNld2hlcmUpIGNvdWxkIGJlIGFuIGludGVyZXN0aW5nIHJl c3VsdCBvZiBhbiBlZmZvcnQgbGlrZSBQQVRJRU5ULiBCdXQgdGhlIHBhcGVyIGFja25vd2xlZGdl cyBsaW1pdGF0aW9ucyBhbmQgd2F5cyBmb3IgZnVydGhlciBpbXByb3ZlbWVudCwgYW5kIGl0IGhh cyBiZWVuIGFwcGxpZWQgdG8gYSBwYXJ0aWN1bGFyIGNhc2U6IGRpc3Rpbmd1aXNoaW5nIGxlZ2l0 aW1hdGUgZnJvbSBtYWx3YXJlLW9yaWdpbmF0ZWQgZW5jcnlwdGVkIHRyYWZmaWMuIE5vdGhpbmcg aXMgc2FpZCBhYm91dCBtYWx3YXJlIHBheWxvYWQgZGV0ZWN0aW9uIHRvIHByZXZlbnQgaW5mZWN0 aW9uLCBhcyBhbiBleGFtcGxlIG9mIGEga2V5IGZlYXR1cmUuDQoNCg0KDQogICAgPiAqKiAoNSkg KiogV2hlcmUgdGhhdOKAmXMNCg0KICAgID4gZG9uZSB0b2RheSwgaXQgY2FuIGJlIGRvbmUgbXVj aCBtb3JlIHNhZmVseSwgdGhlcmVmb3JlIHdlIHNob3VsZCBzcGVjDQoNCiAgICA+IHN0YW5kYXJk cyBmb3IgaG93IHRvIGRvIGl0IG1vcmUgc2FmZWx5LiAgKCBMb3RzIG9mIGlkZWFzIGhhdmUgYmVl bg0KDQogICAgPiBwdWJsaXNoZWQgaW4gcmVzZWFyY2gsIGFuZCBJIGluY2x1ZGUgc29tZSBkZXRh aWxzIG9uIHRoYXQgZnVydGhlcg0KDQogICAgPiBiZWxvdywgYnV0IG1hdHVyaW5nIHRoZSByaWdo dCBvbmVzIGFuZCBiYWtpbmcgdGhlbSBpbnRvIGEgc3RhbmRhcmQgaXMNCg0KICAgID4gb2YgY291 cnNlIHR5cGljYWxseSBhIOKAnGJpZ2dlciBncm91cOKAnSBlZmZvcnQuICkNCg0KDQoNCiAgICBB ZmFpY3MgYWxsIG9mIHRob3NlIGFwcHJvYWNoZXMgYXJlIGluaGVyZW50bHkgZmxhd2VkIGFuZCBj b25zaWRlcg0KDQogICAgaXQgc29tZW9uZSByZWFzb25hYmxlIHRoYXQgYSBodW1hbiBjYW4gZGVj aWRlIHdoZW4gdG8gdHJ1c3QgYQ0KDQogICAgcmFuZG9tIG5hbWUvYWRkcmVzcyB0aGF0IGNsYWlt cyB0byBiZSAiZ29vZC4iIE5vbmUgKGkuZS4gemVybykgb2YNCg0KICAgIHRoZSBhcHByb2FjaGVz IHByb3Bvc2VkIHdvdWxkIGltcHJvdmUgdGhlIG92ZXJhbGwgZW52aXJvbm1lbnQgYW5kDQoNCiAg ICB0aGVyZWZvcmUgbm9uZSAoaS5lLiB6ZXJvKSBvZiB0aG9zZSBvdWdodCBiZSBzdGFuZGFyZGlz ZWQuDQoNCg0KDQpJIGFtIGFmcmFpZCBJIGRvbuKAmXQgZm9sbG93IHlvdSBoZXJl4oCmIFdoYXQg ZG8geW91IG1lYW4gYnkg4oCccmFuZG9tIG5hbWUvYWRkcmVzcyB0aGF0IGNsYWltcyB0byBiZSDi gJxnb29k4oCd4oCdPyBHaXZlbiB0aGVyZSBhcmUgYXBwcm9wcmlhdGUgcm9vdHMgb2YgdHJ1c3Qs IGhvdyBpcyB0aGlzIOKAnHJhbmRvbeKAnSB0cnVzdCBkaWZmZXJlbnQgZnJvbSB0aGUgY2VydGlm aWNhdGUgdmVyaWZpY2F0aW9uIHByb2Nlc3MgaW4gVExTPw0KDQoNCg0KQmUgZ29vZGUsDQoNCg0K DQotLQ0KDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpEciBE aWVnbyBSLiBMb3Bleg0KDQpUZWxlZm9uaWNhIEkrRA0KDQpodHRwczovL3d3dy5saW5rZWRpbi5j b20vaW4vZHIybG9wZXovDQoNCmUtbWFpbDogZGllZ28uci5sb3BlekB0ZWxlZm9uaWNhLmNvbQ0K DQpUZWw6ICAgICAgICAgKzM0IDkxMyAxMjkgMDQxDQoNCk1vYmlsZTogICszNCA2ODIgMDUxIDA5 MQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVudG9z IHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRl bmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJhIHVz byBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8gZXMg dXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBxdWUg bGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRv cml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNp w7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJv Z2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUgaW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEg dsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVjY2nDs24uDQoNClRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFs IGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwg b3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2FnZSBpcyBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBh bnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5p Y2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg dHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBub3QgcmVhZCBpdC4gUGxlYXNlIGltbWVkaWF0ZWx5 IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmlj YXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0Lg0KDQpFc3RhIG1lbnNhZ2VtIGUgc2V1 cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywg cG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBvdSBjb25maWRlbmNpYWwgZSDD qSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNl IG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlvIGluZGljYWRvLCBmaWNhIG5v dGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwgdXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9v dSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRl IGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVy cm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0 YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8Ojbw0K --_000_AF4C62E061AB45DBB3E656AB67A1070Atelefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <3BDCCDEDCFA02040A2E827200A434ADA@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5U ZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uUGxhaW5UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzAuODVwdCAzLjBjbSA3MC44NXB0IDMuMGNtO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+77u/PHNwYW4gbGFuZz0iRU4t VVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Rmlyc3Qgb2YgYWxsLCBsZXQgbWUgc2F5 IEkgYW0gZ2xhZCB0byBzZWUgdGhpcyBkaXNjdXNzaW9uIHJlb3BlbmVkLCBhbmQgZ2xhZCB0byBz ZWUgYXMgd2VsbCBzb21lIHByb3Bvc2FscyB0aGF0IHNvdW5kIG1vcmUgY29uc3RydWN0aXZlIHRo YW4gdGhlIHVzdWFsIHJlbGlnaW91cyBlbnRyZW5jaG1lbnRzIHRoYXQgYXJlIHNvIGNvbW1vbiBp biB0aGlzIGZyb250LCBlc3BlY2lhbGx5DQogd2hlbiBJIHNlZSBjZXJ0YWluIGFja25vd2xlZGdl bWVudCB3ZSBhcmUgbm90IG5lY2Vzc2FyaWx5IHRhbGtpbmcgb2YgbWl0bS1pbmcsIGFuZCB3ZSBh cmUgbm90IG9ubHkgdGFsa2luZyBhYm91dCBIVFRQUyBhbmQvb3Igd2ViIGFjY2Vzcy4gSXQgaXMg YWJvdXQgZXhwbG9yaW5nIHRoZSBzb2x1dGlvbiBzcGFjZSBmb3IgbmV0d29yay1ob3N0ZWQgZGV2 aWNlIHByb3RlY3Rpb24gaW4gYSBuZXR3b3JrIHdpdGggd2lkZXNwcmVhZCAoT0ssIGxldCdzDQog bm90IHVzZSAmcXVvdDtwZXJ2YXNpdmUmcXVvdDspIHVzZSBvZiBlbmQtdG8tZW5kIGVuY3J5cHRp b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIHNhaWQsIHRoZXJlIGEgZmV3IHBvaW50 cyBJJ2QgbGlrZSB0byBtYWtlIGluIHJlc3BvbnNlIHRvIFN0ZXBoZW4ncyBjb21tZW50cy4uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+T24gMTYvMTIvMjAxNywgMTY6MjcsICZxdW90O1BBVElF TlQgb24gYmVoYWxmIG9mIFN0ZXBoZW4gRmFycmVsbCZxdW90OyAmbHQ7cGF0aWVudC1ib3VuY2Vz QGlldGYub3JnIG9uIGJlaGFsZiBvZiBzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllJmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO09uIDE0LzEyLzE3IDIyOjU4 LCBCcmlhbiBXaXR0ZW4gd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyBUaGUgbG9naWMsIGluIHRoZSBzaG9ydCBmb3JtIG9mIHJvdWdo bHkgZml2ZSBwb2ludHMgd291bGQgYmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4m bmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtMZXQncyBzZWUgaWYgdGhlcmUgaXMgb3IgaXMgbm90IGxvZ2ljIHRv IGJlIGZvdW5kLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsm bmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmZ3Q7ICoqICgxKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgKiogRW5kcG9pbnRzIGhhdmUgdnVsbmVyYWJpbGl0aWVzLiZuYnNwOyAo IHVuZm9ydHVuYXRlbHkgbG90cyBvZiB0aGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwNzBD MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgRm9yIHRoaXMgcGFydCBJIGJlbGlldmUgdGhlcmUg aXMgb3ZlcndoZWxtaW5nIGV2aWRlbmNlLCBidXQgcGxlYXNlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBMTUsgaWYgeW91IGRpc2FncmVlLiAp DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 VGhhdCdzIGluY29tcGxldGUgdG8gdGhlIHBvaW50IG9mIGJlaW5nIG1pc2xlYWRpbmcuIE1pZGRs ZWJveGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsg YXJlIGFzIGxpa2VseSB0byBoYXZlIGJ1Z3MuIEFuZCBpZiB0aG9zZSBhcmUgbWl0bSdpbmcgbWFu eSBodHRwczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGNvbm5lY3Rpb25zIHRoZSBpbXBhY3Qgb2YgYSBwcm9ibGVtIGlzIGhpZ2hlciB0aGFuIGZvciB0 aGUgY2xpZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJz cDsgc2lkZS4gUHJvYmFibHkgYWxzbyBoaWdoZXIgaW1wYWN0IGZvciBtb3N0IGluc3RhbmNlcyBv ZiBzZXJ2ZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJz cDsgdG9vLiBBbmQgdGhlIG1pdG1zIGFyZSBjZXJ0YWlubHkgaW4gYSBwb3NpdGlvbiB0byBtaXRt IGNvbm5lY3Rpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsm bmJzcDsgdG8gaGlnaC12YWx1ZSBzZXJ2ZXJzIChpZiB0aGV5IGNhbiBkbyBvbmUgdGhleSBjYW4g ZG8gYWxsKSBzbyBhbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNw OyZuYnNwOyBtaXRtIGNvZGUgYnVncyBjb3VsZCBhcmd1ZWQgdG8gYmUgd29yc2UgdGhhbiBlbmRw b2ludCBidWdzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+SXMgbm90IGhlcmUgYSBmbGF3IGluIHlvdXIgbG9naWM/IE5v Ym9keSBoYXMgbWVudGlvbmVkIG1pZGRsZWJveGVzIChvciDigJx0aGluZ3PigJ0sIGFzIHRoZXkg aGF2ZSBjYWxsZWQgYmVsb3cpIHlldOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyAqKiAoMikgKiogVGhlc2UgdnVsbmVyYWJpbGl0aWVzIGFy ZSBvZnRlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgZGlmZmljdWx0IChzb21ldGltZXMgbmVhcmx5IGltcG9zc2libGUpIGZvciBkZXZpY2Ug b3duZXJzLCB1c2Vycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7IGV0YywgdG8gbWl0aWdhdGUg4oCcaW7igJ0gdGhlc2UgZW5kcG9pbnRzLiAo IHRoaXMgaXMgdHJ1ZSB0b2RheSBmb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGNvdW50bGVzcyBkZXZpY2VzLCBhbmQgaW5jcmVhc2luZ2x5 IHRydWUgZm9yIGluY3JlYXNpbmdseSBjbG9zZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcw QzAiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGRldmljZXMsIHBhcnRpY3VsYXJseSBpbiBJT1Qg YW5kIG1vYmlsZS4gKQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO1doZXJlJ3MgdGhlIGV2aWRlbmNlIGZvciB0aGF0PyBXaGF0IHBlcmNlbnRh Z2UgaXMgJnF1b3Q7b2Z0ZW4mcXVvdDs/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4m bmJzcDsmbmJzcDsmbmJzcDsgKFNwZWFraW5nIGFib3V0ICZxdW90O2NvdW50bGVzcyZxdW90OyBk ZXZpY2VzLCBpcyBwdXJlIHJoZXRvcmljYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAi PiZuYnNwOyZuYnNwOyZuYnNwOyBub2lzZSBhbmQgbm90IHVzZWZ1bCBpZiB5b3UgYXJlIGhvbmVz dGx5IHRyeWluZyB0byBwcm92aWRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJz cDsmbmJzcDsmbmJzcDsgdmVyaWZpYWJsZSBldmlkZW5jZS4pPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIG1vc3QgcmVj ZW50IEkgaGF2ZSBmb3VuZCBpcyBoZXJlOg0KPGEgaHJlZj0iaHR0cHM6Ly9kYW5sdXUuY29tL2Fu ZHJvaWQtdXBkYXRlcy8iPmh0dHBzOi8vZGFubHV1LmNvbS9hbmRyb2lkLXVwZGF0ZXMvPC9hPiAu IEl0IG9ubHkgcmVmZXJzIHRvIEFuZHJvaWQgZGV2aWNlcywgdGhvdWdoIGl0IG1lbnRpb25zIG90 aGVyIHN5c3RlbXMgYXMgV2luZG93cyBYUC4gQW5kIGl0IGRvZXMgbm90IHRha2UgaW50byBhY2Nv dW50IElvVCBkZXZpY2VzLCB0byBuYW1lIGFub3RoZXIgY2F0ZWdvcnkuIE1heSBiZSBhbGwgb2YN CiB0aG9zZSBhcmUgbm90IOKAnGNvdW50bGVzc+KAnSwgYnV0IGl0IG1ha2VzIHRoZSB1c2Ugb2Yg dGhlIHdvcmQgYSByZWFzb25hYmx5IGFjY3VyYXRlIGZpZ3VyZSBvZiBzcGVlY2ggYW55d2F5Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1doeSB3b3VsZCBt aWRkbGVib3hlcyBiZSBlYXNpZXIgdG8gcGF0Y2g/IEl0IHNlZW1zIGZyb20gbWFueTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuZWNkb3RlcyAoSSdk IGxvdmUgdG8gc2VlIHJlYWwgbnVtYmVycyksIHRoYXQgYXQgbGVhc3QgYnJvd3NlcnM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNwOyBhbmQgd2ViIHNlcnZl cnMgdGhlc2UgZGF5cyBhcmUgbWFuYWdlZCBtdWNoIGJldHRlciBpbiB0ZXJtcyBvZjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVwZGF0ZXMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj5JIGNhbm5vdCBzcGVhayBmb3Igb3RoZXIgcGVvcGxlIHN1cHBvcnRpbmcgdGhpcywgYnV0 IHdlIGhhdmUgbm90IGluIG1pbmQgb25seSB3ZWIgYnJvd3NlcnMgb3Igd2ViIGFjY2VzcyB1c2Ug Y2FzZXMuIEkgcmVtZW1iZXIgY29uc3RyYWluZWQgZGV2aWNlcyB3ZXJlIG1lbnRpb25lZCBhIGNv dXBsZSBvZiB0aW1lcyBpbiBTaW5nYXBvcmUuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNw OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jmd0OyAqKiAoMykgKiogRm9yIHRoYXQgcmVhc29uLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgdGhvc2UgZW5kcG9pbnQgb3duZXJz L3VzZXJzL2V0YyBvZnRlbiBuZWVkIHRvIHB1dCBzb21lIOKAnHRoaW5n4oCdIGluIHRoZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgbmV0d29y ayB0byBtaXRpZ2F0ZSB0aG9zZSBlbmRwb2ludCB2dWxuZXJhYmlsaXRpZXMuICoqDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhhdCdzIHNp bXBseSBmYWxzZS4gRXZlbiBpZiBJIGFjY2VwdGVkIHlvdXIgc3RhdGVkIGFuZCBmbGF3ZWQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNwOyBwcmVtaXNlcywg dGhlIGFib3ZlIHN0aWxsIGRvZXNuJ3QgZm9sbG93IGF0IGFsbC4gSnVzdCB0byBjYWxsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsgb3V0IHlvdXIgZmxh d2VkIGxvZ2ljIGluIG9uZSB3YXk6IGJ1Z2d5IGRpZmZpY3VsdCB0byBmaXggY2xpZW50czxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICpjb3VsZCogYmUg Zml4ZWQgb3IgcmVwbGFjZWQgb3ZlciB0aW1lLCBzbyB5b3VyIGNsYWltIHRoYXQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNwOyBhIG1pdG0gbWlkZGxlYm94 IGlzICpuZWVkZWQqIGlzIG9idmlvdXNseSBmYWxzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMw MDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPk9LLiBNYXkgYmUg4oCc bmVlZOKAnSBpcyBhIHRvbyBzdHJvbmcgd29yZCBoZXJlLCBhdCBsZWFzdCBpbiB0aGUgZ2VuZXJh bCBjYXNlIChub3Qgc3VyZSBhYm91dCBzb21lIGtpbmRzIG9mIGRldmljZXPigKYpLiBCdXQgbXkg b3duIGV4cGVyaWVuY2UgYXMgdXNlciBpcyB0aGF0IOKAnGNhbiByZXF1aXJl4oCdIGlzLCBhZ2Fp biwgcmVhc29uYWJseSBhY2N1cmF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jmd0OyAoNCkgKiogRm9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3 MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyB0aGF0IHRvIGJlIGVmZmVjdGl2ZSAoYWdhaW5z dCBhdHRhY2tzIGluIGVuY3J5cHRlZCB0cmFmZmljKSwgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg4oCcdGhpbmfigJ0gbmVlZHMga2V5 cyB0byBpbnNwZWN0IHRoZSBlbmNyeXB0ZWQgdHJhZmZpYy4mbmJzcDsgKCBUaGlzIGNhbiBiZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgZG9u ZSBhbnkgb2YgbWFueSB3YXlzLCBhcyBpdOKAmXMgZG9uZSB0b2RheS4gKQ0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0Fsc28gY2xlYXJseSBp bmNvcnJlY3QuIFNlZSBbMV0gKHJlY2VudGx5IHF1b3RlZCBieSBNYXJ0aW4gVCBvbiBzb21lPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsgb3RoZXIgbGlz dCkgZm9yIGEgcHJvb2YgdGhhdCB5b3VyIGNsYWltIHRoYXQgdGhpcyBpcyAqbmVlZGVkKiBpcyBh bHNvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsganVz dCBmYWxzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNw OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O1sxXSA8YSBocmVmPSJodHRwczovL2FyeGl2Lm9yZy9hYnMvMTYwNy4wMTYzOSI+DQpodHRwczov L2FyeGl2Lm9yZy9hYnMvMTYwNy4wMTYzOTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcw QzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlRoaXMgaXMgYW4gaW50ZXJl c3RpbmcgcmVmZXJlbmNlLiBUaGFua3MgZm9yIHNlbmRpbmcgaXQuIEkgZ3Vlc3MgdGhpcyBraW5k IG9mIHNvbHV0aW9ucyBpcyBpbiB0aGUgbWluZHMgb2YgbWFueSwgYW5kIHJlY29tbWVuZGF0aW9u cyBvbiB0aGVtIChpbmNsdWRpbmcgYSBzb3VuZCBiYXNlIG9mIGRhdGFzZXRzIGZvciB0cmFpbmlu ZyBhbmQNCiB2YWxpZGF0aW9uLCBhcyBJIGhhdmUgbWVudGlvbmVkIGVsc2V3aGVyZSkgY291bGQg YmUgYW4gaW50ZXJlc3RpbmcgcmVzdWx0IG9mIGFuIGVmZm9ydCBsaWtlIFBBVElFTlQuIEJ1dCB0 aGUgcGFwZXIgYWNrbm93bGVkZ2VzIGxpbWl0YXRpb25zIGFuZCB3YXlzIGZvciBmdXJ0aGVyIGlt cHJvdmVtZW50LCBhbmQgaXQgaGFzIGJlZW4gYXBwbGllZCB0byBhIHBhcnRpY3VsYXIgY2FzZTog ZGlzdGluZ3Vpc2hpbmcgbGVnaXRpbWF0ZSBmcm9tIG1hbHdhcmUtb3JpZ2luYXRlZA0KIGVuY3J5 cHRlZCB0cmFmZmljLiBOb3RoaW5nIGlzIHNhaWQgYWJvdXQgbWFsd2FyZSBwYXlsb2FkIGRldGVj dGlvbiB0byBwcmV2ZW50IGluZmVjdGlvbiwgYXMgYW4gZXhhbXBsZSBvZiBhIGtleSBmZWF0dXJl Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICoqICg1KSAqKiBXaGVyZSB0 aGF04oCZczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgZG9uZSB0b2RheSwgaXQgY2FuIGJlIGRvbmUgbXVjaCBtb3JlIHNhZmVseSwgdGhlcmVm b3JlIHdlIHNob3VsZCBzcGVjPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyBzdGFuZGFyZHMgZm9yIGhvdyB0byBkbyBpdCBtb3JlIHNhZmVseS4m bmJzcDsgKCBMb3RzIG9mIGlkZWFzIGhhdmUgYmVlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAw NzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgcHVibGlzaGVkIGluIHJlc2VhcmNoLCBhbmQg SSBpbmNsdWRlIHNvbWUgZGV0YWlscyBvbiB0aGF0IGZ1cnRoZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGJlbG93LCBidXQgbWF0dXJpbmcg dGhlIHJpZ2h0IG9uZXMgYW5kIGJha2luZyB0aGVtIGludG8gYSBzdGFuZGFyZCBpczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgb2YgY291cnNl IHR5cGljYWxseSBhIOKAnGJpZ2dlciBncm91cOKAnSBlZmZvcnQuICk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0FmYWljcyBhbGwgb2YgdGhvc2UgYXBw cm9hY2hlcyBhcmUgaW5oZXJlbnRseSBmbGF3ZWQgYW5kIGNvbnNpZGVyPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsgaXQgc29tZW9uZSByZWFzb25hYmxl IHRoYXQgYSBodW1hbiBjYW4gZGVjaWRlIHdoZW4gdG8gdHJ1c3QgYTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJhbmRvbSBuYW1lL2FkZHJlc3MgdGhh dCBjbGFpbXMgdG8gYmUgJnF1b3Q7Z29vZC4mcXVvdDsgTm9uZSAoaS5lLiB6ZXJvKSBvZjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBhcHByb2Fj aGVzIHByb3Bvc2VkIHdvdWxkIGltcHJvdmUgdGhlIG92ZXJhbGwgZW52aXJvbm1lbnQgYW5kPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsgdGhlcmVmb3Jl IG5vbmUgKGkuZS4gemVybykgb2YgdGhvc2Ugb3VnaHQgYmUgc3RhbmRhcmRpc2VkLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPkkgYW0gYWZyYWlkIEkgZG9u4oCZdCBmb2xsb3cgeW91IGhlcmXigKYg V2hhdCBkbyB5b3UgbWVhbiBieSDigJxyYW5kb20gbmFtZS9hZGRyZXNzIHRoYXQgY2xhaW1zIHRv IGJlIOKAnGdvb2TigJ3igJ0/IEdpdmVuIHRoZXJlIGFyZSBhcHByb3ByaWF0ZSByb290cyBvZiB0 cnVzdCwgaG93IGlzIHRoaXMg4oCccmFuZG9t4oCdIHRydXN0IGRpZmZlcmVudCBmcm9tIHRoZQ0K IGNlcnRpZmljYXRlIHZlcmlmaWNhdGlvbiBwcm9jZXNzIGluIFRMUz88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5CZSBnb29k ZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLSA8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mcXVvdDtFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8mcXVvdDsm bmJzcDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RHIgRGllZ28gUi4gTG9wZXogPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGVsZWZvbmljYSBJJiM0MztEIDwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPmh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9kcjJsb3Blei8m bmJzcDsmbmJzcDsmbmJzcDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ZS1tYWlsOiBk aWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ VGVsOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz OzM0IDkxMyAxMjkgMDQxIDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk1vYmlsZTombmJz cDsgJiM0MzszNCA2ODIgMDUxIDA5MTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YnI+DQo8aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29s b3I9IkdyYXkiIHNpemU9IjEiPjxicj4NCkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBzZSBk aXJpZ2VuIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBp bmZvcm1hY2nDs24gcHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28gZXhj bHVzaXZvIGRlIGxhIHBlcnNvbmEgbyBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVzdGVk LiBlbCBkZXN0aW5hdGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxhDQog bGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRvcml6 YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNpw7Nu IHZpZ2VudGUuIFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJvZ2Ft b3MgcXVlIG5vcyBsbyBjb211bmlxdWUgaW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEgdsOt YSB5IHByb2NlZGEgYSBzdSBkZXN0cnVjY2nDs24uPGJyPg0KPGJyPg0KVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRl bnRpYWwgaW5mb3JtYXRpb24gaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZp ZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdl IGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0 aGF0IGFueSBkaXNzZW1pbmF0aW9uLA0KIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMg Y29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1l ZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBj b21tdW5pY2F0aW9uIGluIGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC48YnI+DQo8YnI+DQpFc3Rh IG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBzZXUg ZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBvdSBj b25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlkYWRl IGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlvIGlu ZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGENCiBsZWl0dXJhLCB1dGlsaXphw6fDo28s IGRpdnVsZ2HDp8OjbyBlL291IGPDs3BpYSBzZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFyIHBy b2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUgZXN0 YSBtZW5zYWdlbSBwb3IgZXJybywgcm9nYW1vcy1saGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBpbWVk aWF0YW1lbnRlIHBvciBlc3RhIG1lc21hIHZpYSBlIHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6Nv PGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AF4C62E061AB45DBB3E656AB67A1070Atelefonicacom_-- From nobody Sun Dec 17 16:24:04 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59B312711D; Sun, 17 Dec 2017 16:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 JMNhRLoyhEnY; Sun, 17 Dec 2017 16:23:56 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 710921200C5; Sun, 17 Dec 2017 16:23:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A6605BE2E; Mon, 18 Dec 2017 00:23:54 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGGAGQSPcvNE; Mon, 18 Dec 2017 00:23:53 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 50C71BE24; Mon, 18 Dec 2017 00:23:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1513556633; bh=m5QGpiFSvg+U31NLNkBVEOm6VwOi+54A4Oy0CT2mXOY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=QDx1J/goMwTQ7i2bDyGnNpJ9/+eoz6fR06B9giRHDlmvPpgRHmc1BOvS9nLLCq4tj aLFnxnPWhOCUmETZbp82J1NRnHCPezYXhRXG/LwRhUts9ltUZ3nZ7p52rfFcDElhof mu2T41dSLsBS6wJLGSKl+VGtt0xg1fripld32oFE= To: "Diego R. Lopez" , Brian Witten , "patient@ietf.org" , "saag@ietf.org" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Mon, 18 Dec 2017 00:23:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MT3HJ19vsNt2fkLfMpGfDifS9petDHdxL" Archived-At: Subject: Re: [saag] [Patient] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 00:23:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MT3HJ19vsNt2fkLfMpGfDifS9petDHdxL Content-Type: multipart/mixed; boundary="NEMTjJW4DArmcRIBH9WiaFMMO182J2AFQ"; protected-headers="v1" From: Stephen Farrell To: "Diego R. Lopez" , Brian Witten , "patient@ietf.org" , "saag@ietf.org" Message-ID: Subject: Re: [Patient] [saag] Internet Draft posted as requested - References: In-Reply-To: --NEMTjJW4DArmcRIBH9WiaFMMO182J2AFQ Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Diego, I generally disagree with some of your earlier points where you disagree with me:-) I do agree that there are hard problems with updates and bugs in general for endpoints and devices in the middle. I don't agree that breaking TLS or HTTPs is a viable way to improve that, It'd make it worse. But rather than repeat things I've said to you in person before, for this threat, maybe it is work saying that the proponent here claimed to be interested in a new multiparty security protocol (in the mailing list description) which could have been a worthy, if unlikely to succeed endeavour. In Singapore, I concluded that they are primarily or maybe only interested in the web as used by people and in mitm'ing that. So personally I think the separate mailing list would be better closed down as it seems to have been started on the basis of some confusion wrt folks' goals. On 17/12/17 23:19, Diego R. Lopez wrote: >=20 > I am afraid I don=E2=80=99t follow you here=E2=80=A6 What do you mean b= y =E2=80=9Crandom > name/address that claims to be =E2=80=9Cgood=E2=80=9D=E2=80=9D? Given t= here are appropriate > roots of trust, how is this =E2=80=9Crandom=E2=80=9D trust different fr= om the > certificate verification process in TLS? The difference in the above context is the the proponents here want TTPs that tell lies all the time, and that are so wide-spread and not well-known that they appear to the endpoints indistinguishable from a random router. The public Web PKI TTPs we have are far from perfect but at least they don't do that so far. There also appears to be some magical thinking that allows some proponents to say that they think these new lies can benefit the user and give the user more control. I have no clue how that can reflect a genuine technical opinion. S. --NEMTjJW4DArmcRIBH9WiaFMMO182J2AFQ-- --MT3HJ19vsNt2fkLfMpGfDifS9petDHdxL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaNwqYAAoJEC88hzaAX42iCGYIALaXpB9X47ivpmoNjYdRnWmh hUTJAuEB4JngRtvbmqM3c1ARlvLdL0ttPdHbOMAC3+y2qnEdm8iXJWscEmUv0JUW 882vLKghsf5obiX84clTWyRsMd8EcOCytyB5UxFsk49bUsOzDp7qMBzMyJ3VcuOB /c5jMjL0/cBnFI9yLhj8IJek8/wTuuWB3N59e3Z/intTYatFuwEXwYZctpgNqvHl 61XhXkrboSyqyXiZPcBjH/hRO//sy1PmW3GpmNLOa45M+c9mi1NX8OE44SjvI3tx bNhjENqGYniBKrZ9kt3Wck/a6QHSqOkjVbi+kJPzc/jYK3PbLBWcAx2/laW8HV0= =PZT5 -----END PGP SIGNATURE----- --MT3HJ19vsNt2fkLfMpGfDifS9petDHdxL-- From nobody Mon Dec 18 08:19:13 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED6C126B6D; Mon, 18 Dec 2017 08:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=wxWxnVaj; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=rsa.com header.b=Q6ClChUg 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 O99fuZPtbvfR; Mon, 18 Dec 2017 08:19:09 -0800 (PST) Received: from esa5.dell-outbound.iphmx.com (esa5.dell-outbound.iphmx.com [68.232.153.95]) (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 79E83124C27; Mon, 18 Dec 2017 08:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1513613350; x=1545149350; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=fiP6gVGP9kxKi9+KRabHz1czkazixeRId4uaIr4X3HU=; b=wxWxnVajSUoZjYJWBQ1ULFCACznMhgFNomG8mkrTm5vpZQ2khKK/SOvY FtXF9/nr7CFvidkgJNeFC+BaZHCr+6jVdN9BiphaitxN7GjEEdDceiv65 KTPB+/BHuCsZOpNjZAntJDTXYj1LBtlRdbItNIT0neB65pcL2lX6+TXqH o=; IronPort-PHdr: =?us-ascii?q?9a23=3AJ0fjsByCAUBZ3YzXCy+O+j09IxM/srCxBDY+r6Qd?= =?us-ascii?q?0uoRKPad9pjvdHbS+e9qxAeQG9mDsrQc06L/iOPJYSQ4+5GPsXQPItRndiQuro?= =?us-ascii?q?EopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZv?= =?us-ascii?q?JuTyB4Xek9m72/q99pHPfglEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+?= =?us-ascii?q?VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfM?= =?us-ascii?q?QA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7Vq4/Vyi84Kh3SR/okC?= =?us-ascii?q?YHOCA/8GHLkcx7kaZXrAu8qxBj34LYZYeYP+d8cKzAZ9MXXWpPUNhMWSxdDI2y?= =?us-ascii?q?bIUPAOgAPelEoIfyqEADrQelCgSoGO/j1iNEi33w0KYn0+ohCwbG3Ak4Et4ArX?= =?us-ascii?q?nUqM/6O7sRUeyt0aLGwy/Mb+1X2Tjg5oTDbxcsr/+WUrJucMre1FMjGh7BjlqK?= =?us-ascii?q?tYPlPCiY2fkTvGif6+psT/6gi2kiqwxopDWk28kiio7Mho0Py1DE8z10z5woKt?= =?us-ascii?q?KjTE57ZsKrEJhItyGeKot2WdkuQ2ZyuCY10rEGt5+7fCwWyJs53R7fb/2Hc5OU?= =?us-ascii?q?4hL4TuqePTB4hHdjdbmihBiy6VCtx+z/W8WuzlpHoDRJnsPRun0N2RHf8NaLRu?= =?us-ascii?q?dj8ku5xDqDyxrf5v9KLE03j6bWJJEszqQtmpcdsknPBiH2l1v1gaOKc0gp/+ul?= =?us-ascii?q?5uvjb7Xoo5KRN5J7hRvgPqkrh8CzHP83Pw0BUmWV+umx1Lvu9lDjTrpQlP05iK?= =?us-ascii?q?zZvYjfJcQcu6G2HRdY0p0m6xajFzem18kYnWUfIFJFZh2Hi4/pNknQL/DjF/iz?= =?us-ascii?q?nU6gnyp1yPDCOr3tG5LNLmXfkLj6erZ99khcxxctwdxF5pJUErEBIPf8W0PrqN?= =?us-ascii?q?PYCRo5PxS1w+bhFtp9ypsTVGOMD6ODLq/fv0GE6vgyL+SMaoIZoijxJ+Q76/L2?= =?us-ascii?q?iH82g14dfa2n3ZsNb3C4G+xrLUuDbnryg9cODH0Gsxc6TOPwlFKCUiVeaGusUK?= =?us-ascii?q?I44jE3Ep6pDYDGRoy1mryOwD+7HoFKZmBBEl2MCm3neJ+LW/oXaSKdPNNhkjIe?= =?us-ascii?q?WbimUY8h2gmktBXmxLp/MurU5ioYuIr71Ndv++3TlA899TpoD8mG0mGCUX10nm?= =?us-ascii?q?0SSz8xxqB/rh819lDW6rR1m/xVE5R97ulTXwM+fcrH0+FiC930HAzIZM2ETFKO?= =?us-ascii?q?Sc7gHTo9CNM8lZtGKV50B9SviAzr3ie2DfkSjbPBTMgs+77d0n7tD8dw13iA07?= =?us-ascii?q?Mu2R1uCNBGPGKOh6Nj+U7UHYGD2xGCnq+lXaURwCCL832MmzmgpkZdBURaVazO?= =?us-ascii?q?XjRXSkLIrNizrhfuRqGvBfINNgJKyuaOJ69OLNbuiAMVF7/YJN3CbjfpyC+LDh?= =?us-ascii?q?GSy+bJNdKydg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ERAACf6DdamMqZ6ERcGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJsgTh0JweECYohjwiCAJchghUKGAeBD4QNAhqEbT8YAQEBAQE?= =?us-ascii?q?BAQEBAQIQAQEBAQEICwsGKC+COCQBDmwMAQEBAQEBAQEBIgEpAg0CICECGAEBA?= =?us-ascii?q?QMBIxEMHw8MBAcEAgEGAhEEAQEBAgIGHQMCAgIwFAEICAIEAQ4ECAyKDggBD4w?= =?us-ascii?q?bnWyCJ4MRh1YBAQEBAQEBAQEBAQEBAQEBAQEBAQEVAwWBD4Jfgg6BV4Fogh6BD?= =?us-ascii?q?oMvgXAVgn4xgjKSIJEbBgKHfaEgjRuFaAGDRwIEAgQFAhqBOx+CCW9RgimCUxA?= =?us-ascii?q?MgWd4AQaIeoEVAQEB?= X-IPAS-Result: =?us-ascii?q?A2ERAACf6DdamMqZ6ERcGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?sgTh0JweECYohjwiCAJchghUKGAeBD4QNAhqEbT8YAQEBAQEBAQEBAQIQAQEBA?= =?us-ascii?q?QEICwsGKC+COCQBDmwMAQEBAQEBAQEBIgEpAg0CICECGAEBAQMBIxEMHw8MBAc?= =?us-ascii?q?EAgEGAhEEAQEBAgIGHQMCAgIwFAEICAIEAQ4ECAyKDggBD4wbnWyCJ4MRh1YBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEVAwWBD4Jfgg6BV4Fogh6BDoMvgXAVgn4xgjK?= =?us-ascii?q?SIJEbBgKHfaEgjRuFaAGDRwIEAgQFAhqBOx+CCW9RgimCUxAMgWd4AQaIeoEVA?= =?us-ascii?q?QEB?= Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa5.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Dec 2017 10:09:09 -0600 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Dec 2017 22:08:31 +0600 Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd05.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vBIGJ2Ks020823 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Dec 2017 11:19:07 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com vBIGJ2Ks020823 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1513613947; bh=zwWPXtT/N+J3jlL7MnQz+5T3xqE=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Q6ClChUgQMXK2baWCd1lVo3H58q4cQq3xRmToJGXQegIaAWQuR+fm3Znj7wuSiOhH mRq5Az7S6jsPMkcfz2zPD0XMOmvjA6xjPI9HyBFhDkrrUUbh0yEiQjA6vXq0tkEfx5 a2frqCgo7l3ed28KRQvf6y6l4MEY4G/OY+f6uGfI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com vBIGJ2Ks020823 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd02.lss.emc.com (RSA Interceptor); Mon, 18 Dec 2017 11:18:44 -0500 Received: from MXHUB303.corp.emc.com (MXHUB303.corp.emc.com [10.146.3.29]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vBIGImXX024542 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 18 Dec 2017 11:18:49 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB303.corp.emc.com ([10.146.3.29]) with mapi id 14.03.0352.000; Mon, 18 Dec 2017 11:18:47 -0500 To: Stephen Farrell , "patient@ietf.org" , "saag@ietf.org" Thread-Topic: [saag] [Patient] Internet Draft posted as requested - Thread-Index: AQHTd42B8AeAsyHgxE2f7m0T/khZiqNIka0AgACxWjA= Date: Mon, 18 Dec 2017 16:18:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.138] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [saag] [Patient] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 16:19:11 -0000 PiBJIGdlbmVyYWxseSBkaXNhZ3JlZSB3aXRoIHNvbWUgb2YgeW91ciBlYXJsaWVyIHBvaW50cyB3 aGVyZQ0KPiB5b3UgZGlzYWdyZWUgd2l0aCBtZTotKSBJIGRvIGFncmVlIHRoYXQgdGhlcmUgYXJl IGhhcmQNCj4gcHJvYmxlbXMgd2l0aCB1cGRhdGVzIGFuZCBidWdzIGluIGdlbmVyYWwgZm9yIGVu ZHBvaW50cyBhbmQNCj4gZGV2aWNlcyBpbiB0aGUgbWlkZGxlLiBJIGRvbid0IGFncmVlIHRoYXQg YnJlYWtpbmcgVExTIG9yDQo+IEhUVFBzIGlzIGEgdmlhYmxlIHdheSB0byBpbXByb3ZlIHRoYXQs IEl0J2QgbWFrZSBpdCB3b3JzZS4NCg0KSWYgImJyZWFraW5nIiBpcyBkZWZpbmVkIGFzICJNSVRN LWluZyBjb25uZWN0aW9ucyB3aXRob3V0IGFueSBmb3JtIG9mIGtub3dsZWRnZSBvciBhdXRob3Jp emF0aW9uIGJ5IHRoZSBlbmRwb2ludCwiIHRoZW4gSSB3b3VsZCBhZ3JlZSB0aGF0ICJicmVha2lu ZyBUTFMgb3IgSFRUUFMiIGlzIGEgYmFkIGlkZWEuDQoNCj4gQnV0IHJhdGhlciB0aGFuIHJlcGVh dCB0aGluZ3MgSSd2ZSBzYWlkIHRvIHlvdSBpbiBwZXJzb24NCj4gYmVmb3JlLCBmb3IgdGhpcyB0 aHJlYXQsIG1heWJlIGl0IGlzIHdvcmsgc2F5aW5nIHRoYXQgdGhlDQo+IHByb3BvbmVudCBoZXJl IGNsYWltZWQgdG8gYmUgaW50ZXJlc3RlZCBpbiBhIG5ldyBtdWx0aXBhcnR5DQo+IHNlY3VyaXR5 IHByb3RvY29sIChpbiB0aGUgbWFpbGluZyBsaXN0IGRlc2NyaXB0aW9uKSB3aGljaA0KPiBjb3Vs ZCBoYXZlIGJlZW4gYSB3b3J0aHksIGlmIHVubGlrZWx5IHRvIHN1Y2NlZWQgZW5kZWF2b3VyLg0K DQorMSBvbiB3b3J0aHksIG5vIGNvbW1lbnQgb24gbGlrZWxpaG9vZCBvZiBzdWNjZXNzLg0KDQo+ IEluIFNpbmdhcG9yZSwgSSBjb25jbHVkZWQgdGhhdCB0aGV5IGFyZSBwcmltYXJpbHkgb3IgbWF5 YmUNCj4gb25seSBpbnRlcmVzdGVkIGluIHRoZSB3ZWIgYXMgdXNlZCBieSBwZW9wbGUgYW5kIGlu IG1pdG0naW5nDQo+IHRoYXQuIFNvIHBlcnNvbmFsbHkgSSB0aGluayB0aGUgc2VwYXJhdGUgbWFp bGluZyBsaXN0IHdvdWxkDQo+IGJlIGJldHRlciBjbG9zZWQgZG93biBhcyBpdCBzZWVtcyB0byBo YXZlIGJlZW4gc3RhcnRlZCBvbg0KPiB0aGUgYmFzaXMgb2Ygc29tZSBjb25mdXNpb24gd3J0IGZv bGtzJyBnb2Fscy4NCg0KQWxzbywgbm8gY29tbWVudCBvbiBwZW9wbGUncyBpbnRlbnRzLCBidXQg SSBkbyB3YW50IHRvIHJlc3BvbmQgdG8gb25lIG9mIFN0ZXBoZW4ncyBlYXJsaWVyIHJlbWFya3Mg Li4uDQoNCj4gSnVzdCBmb3IgYSBsYXVnaCwgSSBsb2FkZWQgWzJdIGluIGEgZGVmYXVsdCBzZXR1 cCBicm93c2VyIChjaHJvbWl1bSkuDQo+IEFtb25nIHRoZSAyNjkgaHR0cCByZXF1ZXN0cyB0aGF0 IGNhdXNlZCB3YXMgWzNdLiBBcmUgeW91IChCcmlhbikNCj4gc2VyaW91c2x5IHRyeWluZyB0byBj bGFpbSB0aGF0IHlvdSBhY3R1YWxseSBiZWxpZXZlIHRoYXQgYSByYW5kb20NCj4gcGVyc29uIGNh biBzZW5zaWJseSBkZWNpZGUgMjY5IHRpbWVzIGlmIDIwMDE6ZGI4OjpiYWQ6MWRlYSBvdWdodA0K PiBiZSBhbGxvd2VkIHRvIG1pdG0gdGhhdCBjb25uZWN0aW9uPw0KDQpBIHBlcnNvbiAocmFuZG9t IG9yIG90aGVyd2lzZSkgLSBvZiBjb3Vyc2Ugbm90IC4uLiBob3dldmVyIC4uLiBhIGNvbW11bml0 eSBvciBvdGhlcndpc2UgbWFpbnRhaW5lZCBibGFja2xpc3Qgb3Igd2hpdGVsaXN0IGlzIHBsYXVz aWJsZSwgYWx0aG91Z2ggdGhhdCBkb2VzIHJlcXVpcmUgYm90aCB0aGF0IHRoZSBpbnZvbHZlZCBt aWRkbGVib3hlcyB0byBoYXZlIHN0YWJsZSB2aXNpYmxlIGlkZW50aXRpZXMsIGFuZCB0aGF0IHRo ZXJlIGJlIGEgdmlhYmxlIGNvbW11bml0eSBvciBvdGhlciBtYWludGVuYW5jZSBvcmdhbml6YXRp b24gZm9yIHRoZSBsaXN0IG9yIGxpc3RzLg0KDQpBIGJsYWNrbGlzdCBhcHByb2FjaCBzZWVtcyBy ZWFzb25hYmx5IGVmZmVjdGl2ZSBpbiBvdGhlciBkb21haW5zIC0gZm9yIGV4YW1wbGVzLCB0cnkg dGhlc2UgbGlua3M6DQoJaHR0cHM6Ly9hZGJsb2NrcGx1cy5vcmcvc3Vic2NyaXB0aW9ucw0KCWh0 dHBzOi8vZmlsdGVybGlzdHMuY29tLw0KDQpUaGFua3MsIC0tRGF2aWQNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzYWFnIFttYWlsdG86c2FhZy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgU3RlcGhlbiBGYXJyZWxsDQo+IFNlbnQ6IFN1bmRheSwgRGVjZW1i ZXIgMTcsIDIwMTcgNzoyNCBQTQ0KPiBUbzogRGllZ28gUi4gTG9wZXogPGRpZWdvLnIubG9wZXpA dGVsZWZvbmljYS5jb20+OyBCcmlhbiBXaXR0ZW4NCj4gPGJyaWFuX3dpdHRlbkBzeW1hbnRlYy5j b20+OyBwYXRpZW50QGlldGYub3JnOyBzYWFnQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc2Fh Z10gW1BhdGllbnRdIEludGVybmV0IERyYWZ0IHBvc3RlZCBhcyByZXF1ZXN0ZWQgLQ0KPiANCj4g DQo+IERpZWdvLA0KPiANCj4gSSBnZW5lcmFsbHkgZGlzYWdyZWUgd2l0aCBzb21lIG9mIHlvdXIg ZWFybGllciBwb2ludHMgd2hlcmUNCj4geW91IGRpc2FncmVlIHdpdGggbWU6LSkgSSBkbyBhZ3Jl ZSB0aGF0IHRoZXJlIGFyZSBoYXJkDQo+IHByb2JsZW1zIHdpdGggdXBkYXRlcyBhbmQgYnVncyBp biBnZW5lcmFsIGZvciBlbmRwb2ludHMgYW5kDQo+IGRldmljZXMgaW4gdGhlIG1pZGRsZS4gSSBk b24ndCBhZ3JlZSB0aGF0IGJyZWFraW5nIFRMUyBvcg0KPiBIVFRQcyBpcyBhIHZpYWJsZSB3YXkg dG8gaW1wcm92ZSB0aGF0LCBJdCdkIG1ha2UgaXQgd29yc2UuDQo+IEJ1dCByYXRoZXIgdGhhbiBy ZXBlYXQgdGhpbmdzIEkndmUgc2FpZCB0byB5b3UgaW4gcGVyc29uDQo+IGJlZm9yZSwgZm9yIHRo aXMgdGhyZWF0LCBtYXliZSBpdCBpcyB3b3JrIHNheWluZyB0aGF0IHRoZQ0KPiBwcm9wb25lbnQg aGVyZSBjbGFpbWVkIHRvIGJlIGludGVyZXN0ZWQgaW4gYSBuZXcgbXVsdGlwYXJ0eQ0KPiBzZWN1 cml0eSBwcm90b2NvbCAoaW4gdGhlIG1haWxpbmcgbGlzdCBkZXNjcmlwdGlvbikgd2hpY2gNCj4g Y291bGQgaGF2ZSBiZWVuIGEgd29ydGh5LCBpZiB1bmxpa2VseSB0byBzdWNjZWVkIGVuZGVhdm91 ci4NCj4gSW4gU2luZ2Fwb3JlLCBJIGNvbmNsdWRlZCB0aGF0IHRoZXkgYXJlIHByaW1hcmlseSBv ciBtYXliZQ0KPiBvbmx5IGludGVyZXN0ZWQgaW4gdGhlIHdlYiBhcyB1c2VkIGJ5IHBlb3BsZSBh bmQgaW4gbWl0bSdpbmcNCj4gdGhhdC4gU28gcGVyc29uYWxseSBJIHRoaW5rIHRoZSBzZXBhcmF0 ZSBtYWlsaW5nIGxpc3Qgd291bGQNCj4gYmUgYmV0dGVyIGNsb3NlZCBkb3duIGFzIGl0IHNlZW1z IHRvIGhhdmUgYmVlbiBzdGFydGVkIG9uDQo+IHRoZSBiYXNpcyBvZiBzb21lIGNvbmZ1c2lvbiB3 cnQgZm9sa3MnIGdvYWxzLg0KPiANCj4gT24gMTcvMTIvMTcgMjM6MTksIERpZWdvIFIuIExvcGV6 IHdyb3RlOg0KPiA+DQo+ID4gSSBhbSBhZnJhaWQgSSBkb27igJl0IGZvbGxvdyB5b3UgaGVyZeKA piBXaGF0IGRvIHlvdSBtZWFuIGJ5IOKAnHJhbmRvbQ0KPiA+IG5hbWUvYWRkcmVzcyB0aGF0IGNs YWltcyB0byBiZSDigJxnb29k4oCd4oCdPyBHaXZlbiB0aGVyZSBhcmUgYXBwcm9wcmlhdGUNCj4g PiByb290cyBvZiB0cnVzdCwgaG93IGlzIHRoaXMg4oCccmFuZG9t4oCdIHRydXN0IGRpZmZlcmVu dCBmcm9tIHRoZQ0KPiA+IGNlcnRpZmljYXRlIHZlcmlmaWNhdGlvbiBwcm9jZXNzIGluIFRMUz8N Cj4gVGhlIGRpZmZlcmVuY2UgaW4gdGhlIGFib3ZlIGNvbnRleHQgaXMgdGhlIHRoZSBwcm9wb25l bnRzDQo+IGhlcmUgd2FudCBUVFBzIHRoYXQgdGVsbCBsaWVzIGFsbCB0aGUgdGltZSwgYW5kIHRo YXQgYXJlDQo+IHNvIHdpZGUtc3ByZWFkIGFuZCBub3Qgd2VsbC1rbm93biB0aGF0IHRoZXkgYXBw ZWFyIHRvIHRoZQ0KPiBlbmRwb2ludHMgaW5kaXN0aW5ndWlzaGFibGUgZnJvbSBhIHJhbmRvbSBy b3V0ZXIuIFRoZSBwdWJsaWMNCj4gV2ViIFBLSSBUVFBzIHdlIGhhdmUgYXJlIGZhciBmcm9tIHBl cmZlY3QgYnV0IGF0IGxlYXN0IHRoZXkNCj4gZG9uJ3QgZG8gdGhhdCBzbyBmYXIuDQo+IA0KPiBU aGVyZSBhbHNvIGFwcGVhcnMgdG8gYmUgc29tZSBtYWdpY2FsIHRoaW5raW5nIHRoYXQgYWxsb3dz DQo+IHNvbWUgcHJvcG9uZW50cyB0byBzYXkgdGhhdCB0aGV5IHRoaW5rIHRoZXNlIG5ldyBsaWVz IGNhbg0KPiBiZW5lZml0IHRoZSB1c2VyIGFuZCBnaXZlIHRoZSB1c2VyIG1vcmUgY29udHJvbC4g SSBoYXZlIG5vDQo+IGNsdWUgaG93IHRoYXQgY2FuIHJlZmxlY3QgYSBnZW51aW5lIHRlY2huaWNh bCBvcGluaW9uLg0KPiANCj4gUy4NCj4gDQoNCg== From nobody Mon Dec 18 09:08:16 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCABE126CBF; Mon, 18 Dec 2017 09:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[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=cs.tcd.ie 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 sh-aKbVO4JFf; Mon, 18 Dec 2017 09:08:07 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7421243F3; Mon, 18 Dec 2017 09:08:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D0E50BE47; Mon, 18 Dec 2017 17:08:04 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZBfc7RMPkHI; Mon, 18 Dec 2017 17:08:04 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8B238BE3E; Mon, 18 Dec 2017 17:08:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1513616884; bh=Ukmn9wOAkvtprFwgHxIi+uBz0v3Gp39BfrgPcKPpQ2g=; h=Subject:To:References:From:Date:In-Reply-To:From; b=jCeH+Qa1vn20rUB3QiHh+T2xA/jWVb5Tz1+BdbhSiTVDNJFga7Fynw3K15Fynt2FR 5XOSK7MJ0d/AWNfrzCtu/7P2n5axFk461sRhPmJOz6MMKDG0ps8VAFlrcVWya9iAoS xUfCKwqdIaIj7LQt6d42cq1f15mFdTH5LGCGwGUU= To: "Black, David" , "patient@ietf.org" , "saag@ietf.org" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <19005081-c8fc-8090-d6f6-ab61855db793@cs.tcd.ie> Date: Mon, 18 Dec 2017 17:08:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SGkxLwexk48haP6KgH2pUKadSVEkU1kgv" Archived-At: Subject: Re: [saag] [Patient] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 17:08:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SGkxLwexk48haP6KgH2pUKadSVEkU1kgv Content-Type: multipart/mixed; boundary="mImQcmVikxs2cwD3lcswPwk8O4i7qm032"; protected-headers="v1" From: Stephen Farrell To: "Black, David" , "patient@ietf.org" , "saag@ietf.org" Message-ID: <19005081-c8fc-8090-d6f6-ab61855db793@cs.tcd.ie> Subject: Re: [saag] [Patient] Internet Draft posted as requested - References: In-Reply-To: --mImQcmVikxs2cwD3lcswPwk8O4i7qm032 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hi David, On 18/12/17 16:18, Black, David wrote: >> I generally disagree with some of your earlier points where you >> disagree with me:-) I do agree that there are hard problems with >> updates and bugs in general for endpoints and devices in the >> middle. I don't agree that breaking TLS or HTTPs is a viable way to >> improve that, It'd make it worse. >=20 > If "breaking" is defined as "MITM-ing connections without any form of > knowledge or authorization by the endpoint," then I would agree that > "breaking TLS or HTTPS" is a bad idea. Even with supposed "knowledge" (see the number 269 below), cookies and other bearer tokens mean that so-called visibility is the same as allowing impersonation unless one doesn't actually ever apply the mitm technology to the web. The chances of that seem to be zero to me. And of course, many of the so-called "visibility" schemes, immediately do allow for endpoint impersonation for everything and not just bearer-token situations, whenever the middlebox so chooses, regardless of the language used to describe those schemes. Which brings us back to them being no better than the current ickky corporate mitm root-ca stuff. >=20 >> But rather than repeat things I've said to you in person before, >> for this threat, maybe it is work saying that the proponent here >> claimed to be interested in a new multiparty security protocol (in >> the mailing list description) which could have been a worthy, if >> unlikely to succeed endeavour. >=20 > +1 on worthy, no comment on likelihood of success. My guess is that success would require there being some application that wanted to use the putative multiparty protocol. I'm sure there might be some such application but I've no idea if there's one that would justify the effort. And of course, it'd be a first-order requirement that that putative new protocol not be confusable with https or tls, or else it'd inherit all the downsides and reasons to not use that protocol for any application that can use https or tls, and that ever needs to be secure against mitm attack. (Which is why I think success there isn't really likely.) >=20 >> In Singapore, I concluded that they are primarily or maybe only >> interested in the web as used by people and in mitm'ing that. So >> personally I think the separate mailing list would be better closed >> down as it seems to have been started on the basis of some >> confusion wrt folks' goals. >=20 > Also, no comment on people's intents,=20 My comment was about my own conclusion. > but I do want to respond to one > of Stephen's earlier remarks ..> >> Just for a laugh, I loaded [2] in a default setup browser >> (chromium). Among the 269 http requests that caused was [3]. Are >> you (Brian) seriously trying to claim that you actually believe >> that a random person can sensibly decide 269 times if >> 2001:db8::bad:1dea ought be allowed to mitm that connection? >=20 > A person (random or otherwise) - of course not=20 That is the exact claim to which I was responding and is, as you note, nonsense. None of this mitm stuff is really about giving users control of anything. > ... however ... a > community or otherwise maintained blacklist or whitelist is > plausible, although that does require both that the involved > middleboxes to have stable visible identities, and that there be a > viable community or other maintenance organization for the list or > lists. >=20 > A blacklist approach seems reasonably effective in other domains - > for examples, try these links: https://adblockplus.org/subscriptions=20 > https://filterlists.com/ IIUC, those kinds of service are aimed at allowing endpoints to decide to just not send http requests. I don't see that they are particularly relevant to this discussion, but I don't know details of any middlebox-oriented services like that. (That's one reason I asked for evidence of efficacy.) It's also worth noting that for mail, where MTAs are a good example of known and fairly well-identified servers, we have decades of history of MTA inspection of cleartext missing lots of "bad" content, and of variously good and less good blocklists. If the proponents of these mitm schemes honestly and openly faced up to such issues and argued for another decades-long arms-race and acknowledged the downsides (e.g. assisting censorship, breaking all sorts of application assumptions, and enabling pervasive monitoring) of mitm'ing https and/or tls then that at least would be credible. It'd still be a bad plan, but at least one for which we could discuss the technical (de)merits and not have to deal with the nonsense claims such at the one we both noted above. Cheers, S. >=20 > Thanks, --David >=20 >> -----Original Message----- From: saag >> [mailto:saag-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: >> Sunday, December 17, 2017 7:24 PM To: Diego R. Lopez >> ; Brian Witten=20 >> ; patient@ietf.org; saag@ietf.org=20 >> Subject: Re: [saag] [Patient] Internet Draft posted as requested - >>=20 >>=20 >> Diego, >>=20 >> I generally disagree with some of your earlier points where you >> disagree with me:-) I do agree that there are hard problems with >> updates and bugs in general for endpoints and devices in the >> middle. I don't agree that breaking TLS or HTTPs is a viable way to >> improve that, It'd make it worse. But rather than repeat things >> I've said to you in person before, for this threat, maybe it is >> work saying that the proponent here claimed to be interested in a >> new multiparty security protocol (in the mailing list description) >> which could have been a worthy, if unlikely to succeed endeavour.=20 >> In Singapore, I concluded that they are primarily or maybe only >> interested in the web as used by people and in mitm'ing that. So >> personally I think the separate mailing list would be better closed >> down as it seems to have been started on the basis of some >> confusion wrt folks' goals. >>=20 >> On 17/12/17 23:19, Diego R. Lopez wrote: >>>=20 >>> I am afraid I don=E2=80=99t follow you here=E2=80=A6 What do you mean= by =E2=80=9Crandom=20 >>> name/address that claims to be =E2=80=9Cgood=E2=80=9D=E2=80=9D? Given= there are >>> appropriate roots of trust, how is this =E2=80=9Crandom=E2=80=9D trus= t different >>> from the certificate verification process in TLS? >> The difference in the above context is the the proponents here want >> TTPs that tell lies all the time, and that are so wide-spread and >> not well-known that they appear to the endpoints indistinguishable >> from a random router. The public Web PKI TTPs we have are far from >> perfect but at least they don't do that so far. >>=20 >> There also appears to be some magical thinking that allows some >> proponents to say that they think these new lies can benefit the >> user and give the user more control. I have no clue how that can >> reflect a genuine technical opinion. >>=20 >> S. >>=20 >=20 --mImQcmVikxs2cwD3lcswPwk8O4i7qm032-- --SGkxLwexk48haP6KgH2pUKadSVEkU1kgv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaN/XzAAoJEC88hzaAX42i41gIALXelgf/t+4IjfQ0BjhR18wS jDFb1kNPttkqs2mmtfA4CR9znd8JG9TAu799Y5rVY6trBBDhOyEwpXbIsNMVRJJ5 UQCUqWnBVpeZsDBpzaHDOA7h9iOG/Yzd8x/gxW+le+pPm7TRyUv2fNmUI1k9gW2G hEgOJUo7ups4YLdag5tb7UMUtmY2KqTdc8GyRMZ7dng0O9wpBQuEWMRHfoE/slti 2SubdmmEXtkbJX5mPNnXXXSuhPTBhWFgeeFRKJstmGCCCE6/yHsp5T/fE2GZiunN IR8pVQKCHMuQvq6fxhm/IFn8G7H7nM2lqG7C3pkK2mQE43i0jHzwN/Au4fglaMk= =fXdy -----END PGP SIGNATURE----- --SGkxLwexk48haP6KgH2pUKadSVEkU1kgv-- From nobody Mon Dec 18 09:39:58 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155D8126CBF; Mon, 18 Dec 2017 09:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=symc.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 OniYp3ep98t8; Mon, 18 Dec 2017 09:39:51 -0800 (PST) Received: from asbsmtoutape01.symantec.com (asbsmtoutape01.symantec.com [155.64.138.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 19AC6126579; Mon, 18 Dec 2017 09:39:51 -0800 (PST) Received: from asbsmtmtaapi01.symc.symantec.com (asb1-f5-symc-ext-prd-snat1.net.symantec.com [10.90.75.1]) by asbsmtoutape01.symantec.com (Symantec Messaging Gateway) with SMTP id CF.0C.35258.56DF73A5; Mon, 18 Dec 2017 17:39:49 +0000 (GMT) X-AuditID: 0a5af819-80ab69c0000089ba-b0-5a37fd65bd3a Received: from TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (asb1-f5-symc-ext-prd-snat5.net.symantec.com [10.90.75.5]) by asbsmtmtaapi01.symc.symantec.com (Symantec Messaging Gateway) with SMTP id 28.F6.04260.56DF73A5; Mon, 18 Dec 2017 17:39:49 +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.1236.3; Mon, 18 Dec 2017 09:39:48 -0800 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.128.1) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Mon, 18 Dec 2017 09:39:48 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PjZm6YqSlCIEmTa+o7MfyFGmIJgnLLLKVv8nqcAcAZE=; b=4gic8th4C+hjTt/A2T504DAt71e5/TVJI85pEqvo5zgVHh2i5K5xwe29Zpi78eKBvj9MUhkR8X9qdqBU42+pa2Z8BG7AWWcIM+bU+FIG/sF0rqfsdSPQ85p+LNdy3tlwLOiigAonxXJqdlLiYLTnyVxpomruTJBw/Y74Rg+gJgA= Received: from MWHPR16MB1488.namprd16.prod.outlook.com (10.175.4.146) by MWHPR16MB1486.namprd16.prod.outlook.com (10.175.4.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Mon, 18 Dec 2017 17:39:46 +0000 Received: from MWHPR16MB1488.namprd16.prod.outlook.com ([10.175.4.146]) by MWHPR16MB1488.namprd16.prod.outlook.com ([10.175.4.146]) with mapi id 15.20.0302.017; Mon, 18 Dec 2017 17:39:46 +0000 From: Brian Witten To: Stephen Farrell , "Diego R. Lopez" , "patient@ietf.org" , "saag@ietf.org" Thread-Topic: [EXT] Re: [Patient] [saag] Internet Draft posted as requested - Thread-Index: AQHTd415HLZtNjcH2kGG5FkwS/mPNKNIPdsAgAEe6Lc= Date: Mon, 18 Dec 2017 17:39:45 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.64.38.107] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR16MB1486; 6:5ZpQxWXND6lT8spJycMzvSbQyX/U5THbnl6vU5k0+vM+iYuvwChy6D4+4sigwPM349/4GSjk+84MS2BRFoftw+sr/xYa5TNYtR0ZjO/ave5c+Ve2er5DQsfznssJo21bdLGBVITRhJRilx4XsYUuh+qcV2Fg3Gai7urxKxTyjzGVj5KUg2IOppEgR3O5tlEoBJgJpXGX0ESmRmIfQLBLj4AmvDFR6YaCgY7cJHyh5U5anTuRFgGKzX1AVhDMBLKc3JT70bbjNAnsF7HrQhSEteRQFfF1Jrf13BNVhzSaOg0Z/y8UQ9bSI2TYMcNiwM0EV2XNfkBcwX8+4iGXWgV7lKWw37S0TMNj5hJXyrYb89k=; 5:bNwY/bIS3K/YdmHGYZSnHr39o0R0g1SGAg7putNcIcq5PB8qae6gootYF5iCkctoU0qPMWxlHyfwr7mYHQmdQaAOcpu1dbklSPSIoBRc5E0Uhxmz1N1MHaO6sZxVhf6VJnCEHy8+AtGoVss+p6sNEsFu6yiDraVRJEIwGmV1an0=; 24:2qD04hFo5mENU3HUdUn6DFWV7Uar2FzJ1tXF6qNWMJn9nN3kB/32rg3jtE+OMEoc9yv1ETvqz8jRGHcfNhlsU8i5K0HSudNMQOjmh5OHWr8=; 7:G0EUs/dsFviQ2VSHv+/hL0VSRnfQUfP1WtE5qgb4maMLIO3y51kV8yHiM78rvm/wM0EB7NC4rSa2YESxSdPJu0GVOB7ahZ2/K+yhZI1jAP4Al/9eRWWM+SweaG4dArNlzuOy1fpJxLg/SPWvN4js8St6yUntYcCArx4qdwtGWfHdQwKaIWrfyOEFGouPpe9gOaEfmpkEh/F4xxPBFnH1t3WizVmCDTxLQqfrJocnlZygr/t7yHUJDGVn6ejDjl6d x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ae235759-0762-4d3e-594f-08d5463e5475 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:MWHPR16MB1486; x-ms-traffictypediagnostic: MWHPR16MB1486: authentication-results: spf=none (sender IP is ) smtp.mailfrom=brian_witten@symantec.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231023)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123555025)(20161123558100)(20161123562025)(6072148)(201708071742011); SRVR:MWHPR16MB1486; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR16MB1486; x-forefront-prvs: 0525BB0ADF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(346002)(396003)(39860400002)(24454002)(189003)(199004)(2501003)(9686003)(53936002)(2906002)(55016002)(99286004)(93886005)(7736002)(305945005)(3280700002)(345774005)(3660700001)(74316002)(33656002)(5660300001)(14454004)(68736007)(105586002)(106356001)(86362001)(3846002)(6116002)(102836003)(97736004)(8676002)(81156014)(7696005)(76176011)(81166006)(478600001)(59450400001)(6506007)(53546011)(8936002)(316002)(2201001)(2950100002)(6436002)(66066001)(110136005)(10290500003)(229853002)(6246003)(77096006)(25786009)(2900100001)(9010500006); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR16MB1486; H:MWHPR16MB1488.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: symantec.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ae235759-0762-4d3e-594f-08d5463e5475 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2017 17:39:45.9186 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR16MB1486 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHeXfOtuNy8LZMHw2pBvlBac2SlK6GBVJaEmGxLDvpScXLZJu3 Pk0jcxvilMrScimzILTSEic2qzVz3smwUKyEnLhkdF9KqG07M/ry8nve//+5wUMRokZuCJWV p2IUeXSOmCcgBbIjaCuzFC2Tto3tjPk64OTFOJ7viLlapeHE1Jrf8mPJ+FbdOC/eaFzkxGv+ EEmETLAnncnJKmQU2/adE2R+aLpB5L+MLW6c7eKrUW+UFvlRgKOgRV9JapGAEuFvCBZnLxGr grmrB7GCC8GUuY7HBlYEDQulXDaYQ/Dw3XWvjcQaAvoNVp9yjQPmKxb0L2fFpud5KvOwBHqX pryuANyCYKz7BfII63ACqE1LpIcDcCK0V49yWN4FDtsb71gk3gKDukd8LaIoIU4B+9RGtoGe D66yOW+uH94LHRVDfA8jHAi/B1q8dQgcBJMzBg67Hgbj01HfquvB8WmZy/JmaP1u9XEojBl0 3g0AW/hw++NlPitIoKPaiVhOhMEVu89kdG/jbPJ1CAf7xDTBTpECA62ffd2y4f0Pva9DCnRb XvP1aHvdfwOyLIUvIwaC5Qi42zjvZSFeC/03Z8g7iLyPNtHK88pclbxARecz0kiJsiQ3zfPQ 7rNJk6TJc9uR93AWgk3IakuwIEwhsb+wyR4tE3HpQrfTgoAixAHCo8PuL2E6XXKRUchTFQU5 jNKCNlCkOEhY4wqTiXAGrWKyGSafUayqHMovRI2KQiNPaR/7u3p3O4YMJ8/+esUkB9edGS+/ dayAWlMqvudwnk4KH5FPpraUd9fEPqgc9u9jhJMlJ3Cc+uD+zPkMDV3cPN1WZo+rejbTo54e 7jsW8aSBceqSl2s6bRBYhUwXkk0d1ekTg0XmQ52Whr7jYRX1h+ulP2ub7WUHrHViUplJR4YT CiX9F4pGeXQ0AwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42LhivJm1U39ax5lcO2xgcWHU2/ZLF4eMLaY 0t/JZDF97zV2BxaPtd1X2TyWLPnJ5NH5mzmAOYrLJiU1J7MstUjfLoEr496iGcwFhx0qFj7b yd7AeNSki5GTQ0LARGLvzn2MXYxcHEIC3xgl7uydxQbhHGGUmPejkRXCecEosf76NLAyFoFO ZomT849AZaYySextP8QI1/P/xAQ2kMlsAnoSR//eAasSEVjDKHFp90FGkISwgI9Ew46/LCC2 iICvxKaJ55kgbCuJlycuM4PYLAKqEqe7N7B3MXJw8ArESDy9Iw+xYAK7xLemF2C9nAK2Els7 zrCD2IwCYhLfT60Bm8MsIC5x68l8Joj3BCSW7DnPDGGLSrx8/I8VwlaUWPvpCJQtK3FpfjfY BxICh9gl5t5vZYdI6ElsnfiWEcL2lTj9/ylU0RKgb94ugtqgJfH05gNmiCtiJE6tfQW1LVvi 7ucJUBtiJHYfusgO0byAWWLO5iY2iISMxOMj3SwTGPVmIbkcwjaQeH9uPjOErS2xbOFrMJtX QFDi5MwnLAsYWVYxKiQWJxXnluSWJCYWZBoY6hVX5iaDiERgsknWS87P3cQITji/xXYwHvjj c4hRgINRiYd3xlXzKCHWxDKgykOM0hwsSuK8jzWYooQE0hNLUrNTUwtSi+KLSnNSiw8xMnFw SjUw7inYE96ZK7tO3meaCu/XIAnH1kPHZ70Wrgl2+jUxM0Rk946CY+n6W2fl/rx08K+sRd7F lx+eNy748urF0S42I3fhlLKbWxf9ZA+udpu/yGXC1QU7iiq5FZvuej7QmHnecmfYPi7e2QXX edy4Q1ki1gSu7XixNZFrW1oDG1eoyZaVUlPTOJd+UWIpzkg01GIuKk4EAOh2YcwZAwAA X-CFilter-Loop: ASB04 Archived-At: Subject: Re: [saag] [EXT] Re: [Patient] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 17:39:53 -0000 Hi Stephen, =A0 Thank you for taking time to reply over a weekend.=A0 The extra effort is a= ppreciated. =A0 Where you say, =93Middleboxes are as likely to have bugs,=94 this is of cou= rse completely consistent with my emphasis in Singapore that =93all softwar= e has bugs & vulnerabilities,=94 including both endpoints and network appli= ances, virtual and physical.=A0 One of my points that you might=92ve missed= in Singapore was that =93when something goes wrong,=94 such as a vulnerabi= lity being exploited, I=92d much rather have that "blow up" in some remote = (and easily reset) network thing (virtual appliance, container, or lambda) = rather than in the endpoint.=A0 Why? Network =93things=94 can be dedicated= to flows that are specific to a remote endpoint, like a client running a s= et of proxies in a cloud based infrastructure that they and millions of oth= ers trust, with each software instance of the proxy dedicated to mediating = communication with a different server.=A0 In this context, if the server ha= cks the middlebox, it only hears it=92s own conversation with the client.= =A0 In contrast, if the server manages to hack a client, it can hear all th= at client is doing, including today lots of location based information, as = well as seeing state accumulated from past conversations with other servers= .=A0 So, I=92ll stand by my two assertions: =93All software has vulnerabili= ties,=94 and =93When things go wrong, I=92d rather have them go wrong in an= easily reset network thing, much rather than having things go wrong in the= endpoint.=94 =A0 Back to the thought that =93all software has vulnerabilities,=94 taking the= discussion further, in fact, just as some endpoints have more vulnerabilit= ies than others, some network appliances have more vulnerabilities than oth= ers. That=92s of course among the reasons I believe it=92s good for endpoin= ts to know as much as possible about the network appliances which they are = considering trusting with cleartext.=A0 Some people in this discussion have= proposed narrowing the scope so that endpoints only trust a set of well-kn= own, manually pre-configured set of such appliances, but still tackle chall= enges like end2end integrity.=A0 Others see value in tackling the more flex= ible, more SDN/NFV like aspects.=A0 I=92d be happy with either scope. Eithe= r scope would be better than trying to pretend that network appliances aren= =92t needed for security, or trying to pretend that network appliances neve= r need to see cleartext to be effective. Re, =93That's incomplete to the point of being misleading,=94 it would have= been incomplete if I hadn=92t already said much of what I=92d said above, = but I=92m happy to repeat myself here to be sure all is captured electronic= ally for everyone, and, as promised, I=92ll try to similarly consolidate al= l of these points into the v01 of the Internet Draft. =A0 On your reference to analysis of encrypted traffic without decryption, that= can be great for detecting =93command and control=94 communications after = an infection, and maybe sometimes even for blocking later stages of a multi= -stage attack, but of course it=92s not always very effective against block= ing initial infection. =A0 Re Diego=92s points I agree with him completely on all the points he mentio= ned yesterday, including changing the phrasing of point (3) to =93may requi= re.=94=A0 Some endpoints are easily updated, others are not.=A0 Even for = =93easily updated=94 endpoints, people operating many endpoints often find = that network protection is an efficient way to quickly protect many, many d= evices, all at once, while endpoints individually update their protection. =A0 Re =93random person can sensibly decide 269 times,=94 um, no.=A0 I=92ve rep= eated myself here on this a few times, but I=92m happy to do it at least on= e more time.=A0 Power users might choose to run their own protection in the= ir own cloud based infrastructure, but that=92s not a random person.=A0 Man= y people choose to have someone or something help protect them.=A0 Many emp= loyees choose to let their employer help protect them.=A0 Many people often= choose to have security companies help protect them.=A0 Some people choose= to have network providers help protect them.=A0 I believe people have a ri= ght to choose who protects from them from potentially malicious servers.=A0= I believe people have a right to choose protection from someone other than= the endpoint maker and someone other than the remote server.=A0 Maybe we d= iffer on this. =A0 Re shutting down the dedicated list for this discussion, we all recognize t= hat has been your desire from the start.=A0 In contrast, some of us see val= ue in the discussion.=A0 Where you concluded PATIENT was started for only w= atching what people do on the web, and not helping protect IOT =93things,= =94 that view is of course surprising to me as one of my earlier notes high= lighted =93particulary for =85 IOT devices,=94 and I continue emphasizing = =93increasingly closed=94 endpoints including both mobile & IOT.=A0 Of cour= se, like TLS, PATIENT would be most valuable well-covering a broad range of= settings, including Web, Mobile Apps, and IOT. =A0 Re, =93no clue how that can reflect a genuine technical opinion,=94 I=92m h= appy to talk by phone if that=92s more convenient for you.=A0 I=92m hoping = that you are willing to grow past your (actually quite famous) a priori bia= ses on this topic.=A0 Re, =93magical thinking =85 new lies =85 and =85snow = job,=94 I find your choice of such words simply insulting and not construct= ive, but I=92m willing to look past that here.=A0 It=92s an important discu= ssion, and I have a thick skin.=A0 I=92m sure there=92s a joke somewhere ne= ar that re thick headed.=A0 More importantly though, as I was saying, =93ho= w we (as a community) protect increasingly closed endpoints, at scale, now = that we are beginning to enjoy the fruits of pervasive encryption,=94 is an= important topic.=A0 I=92m obviously eager to continue the discussion.=A0 T= hank You Again. Brian =20 From: Stephen Farrell Sent: Sunday, December 17, 2017 4:23 PM To: Diego R. Lopez; Brian Witten; patient@ietf.org; saag@ietf.org Subject: [EXT] Re: [Patient] [saag] Internet Draft posted as requested - =A0=20 Diego, I generally disagree with some of your earlier points where you disagree with me:-) I do agree that there are hard problems with updates and bugs in general for endpoints and devices in the middle. I don't agree that breaking TLS or HTTPs is a viable way to improve that, It'd make it worse. But rather than repeat things I've said to you in person before, for this threat, maybe it is work saying that the proponent here claimed to be interested in a new multiparty security protocol (in the mailing list description) which could have been a worthy, if unlikely to succeed endeavour. In Singapore, I concluded that they are primarily or maybe only interested in the web as used by people and in mitm'ing that. So personally I think the separate mailing list would be better closed down as it seems to have been started on the basis of some confusion wrt folks' goals. On 17/12/17 23:19, Diego R. Lopez wrote: >=20 > I am afraid I don=92t follow you here=85 What do you mean by =93random > name/address that claims to be =93good=94=94? Given there are appropriate > roots of trust, how is this =93random=94 trust different from the > certificate verification process in TLS? The difference in the above context is the the proponents here want TTPs that tell lies all the time, and that are so wide-spread and not well-known that they appear to the endpoints indistinguishable from a random router. The public Web PKI TTPs we have are far from perfect but at least they don't do that so far. There also appears to be some magical thinking that allows some proponents to say that they think these new lies can benefit the user and give the user more control. I have no clue how that can reflect a genuine technical opinion. S. = From nobody Mon Dec 18 11:15:19 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661D412D848; Mon, 18 Dec 2017 11:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.11 X-Spam-Level: X-Spam-Status: No, score=-0.11 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=nohats.ca 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 9LRgQeNIcNI5; Mon, 18 Dec 2017 11:15:13 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 1621412D80F; Mon, 18 Dec 2017 11:15:13 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3z0rMg04BHz3DD; Mon, 18 Dec 2017 20:15:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1513624511; bh=oD1+SFvd7QJNLAxrkZ50KfQhZ/WnuXg1qgv5YYGfapc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Ldx3SvdsQBSQKRgaKPm58m2Z/71yTpiYyNxk8JuCZ5lFhXOf7j0B86SQUoX4T4klT W2rjprwyWYJDIl8Sd61D65OLbzbDTNcpppbIFstTCwL1LmJanwvNMclNQnnzNPFzeS jmO5H4WZ/B5D+mHv8N7D+BNX8HEVd6Ko1CuFJmx4= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 4Lkt3GJZ60CY; Mon, 18 Dec 2017 20:15:09 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 18 Dec 2017 20:15:09 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 2640F70A3E7; Mon, 18 Dec 2017 14:15:08 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 2640F70A3E7 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0F41A43A0D45; Mon, 18 Dec 2017 14:15:08 -0500 (EST) Date: Mon, 18 Dec 2017 14:15:07 -0500 (EST) From: Paul Wouters To: Stephen Farrell cc: "patient@ietf.org" , "saag@ietf.org" In-Reply-To: <19005081-c8fc-8090-d6f6-ab61855db793@cs.tcd.ie> Message-ID: References: <19005081-c8fc-8090-d6f6-ab61855db793@cs.tcd.ie> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [saag] [Patient] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 19:15:14 -0000 On Mon, 18 Dec 2017, Stephen Farrell wrote: > If the proponents of these mitm schemes honestly and openly > faced up to such issues and argued for another decades-long > arms-race and acknowledged the downsides (e.g. assisting > censorship, breaking all sorts of application assumptions, > and enabling pervasive monitoring) of mitm'ing https and/or > tls then that at least would be credible. It'd still be a bad > plan, but at least one for which we could discuss the technical > (de)merits and not have to deal with the nonsense claims such > at the one we both noted above. If we did an use-cases document for this, to seperate the technical aspects from the business aspects, the first item I would insist on would be: - Protection service MUST NOT be in the possession of any private key material that will allow it to impersonate the client identity to a remove server. If a client wants to delegate this responsibility, it MUST be able to communicate this to the server and the server MUST be able to deny such a request (upon which the client may decide to close the connection) The problem here is that providers of these services don't want to double the traffic load where the client decrypts then forwards for blessing. But simply insisting that decryption has to move to the network service isn't going to work. Another way to accomplish this would be to have signed web pages, so clients could send hashes for verification. But in today's dynamic web that is also pretty problematic and would require major changes. Of course it has the benefit of the provider not even being able to read the users content. The IETF discussion should not center around the business model, but should center around designing (or not) a useful new protocol or existing protocol modification that addresses a well defined issue. Instead, I hear about desires and potential business models and how some of our new technology has affected existing business models. I also detect a culture clash where I see a lot of praise to proponents and opponents without technical backing. At the IETF, we try to reach consensus based on technical merit, for example by stating you agree or disagree with certain items and why, and don't do "me too" messages to get a count. Paul From nobody Mon Dec 18 15:01:28 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0384912AF77; Mon, 18 Dec 2017 15:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=symc.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 UoUE9ESz6Qbn; Mon, 18 Dec 2017 15:01:21 -0800 (PST) Received: from asbsmtoutape01.symantec.com (asbsmtoutape01.symantec.com [155.64.138.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 1B2DA126C3D; Mon, 18 Dec 2017 15:01:21 -0800 (PST) Received: from asbsmtmtaapi02.symc.symantec.com (asb1-f5-symc-ext-prd-snat9.net.symantec.com [10.90.75.9]) by asbsmtoutape01.symantec.com (Symantec Messaging Gateway) with SMTP id 19.CB.35258.0C8483A5; Mon, 18 Dec 2017 23:01:20 +0000 (GMT) X-AuditID: 0a5af819-80ab69c0000089ba-57-5a3848c0a18f Received: from tus3xchcaspin01.SYMC.SYMANTEC.COM (asb1-f5-symc-ext-prd-snat8.net.symantec.com [10.90.75.8]) by asbsmtmtaapi02.symc.symantec.com (Symantec Messaging Gateway) with SMTP id CA.AC.04178.0C8483A5; Mon, 18 Dec 2017 23:01:20 +0000 (GMT) Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) by tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 18 Dec 2017 15:01:19 -0800 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.128.2) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Mon, 18 Dec 2017 15:01:19 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wuergpblpOnf/6hDPvUboO0VPbx80m7S9xDiAcJp64s=; b=kNzX1X/4xr6X/QFMWaX6MydqmgpjWPGQL4cK80+wvM8Y8jvaYvcnQRXDcz2t36lDVcR94SzkypDIWMURbekOei/5+86N33Z4yarjuUgcHn3MeduDjAzXSX4BmxBVG4Rk0yAH83nSRSZB00WCc2QqpEYTeZa0Pc9rekc6G+Dx3rg= Received: from MWHPR16MB1488.namprd16.prod.outlook.com (10.175.4.146) by MWHPR16MB1488.namprd16.prod.outlook.com (10.175.4.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Mon, 18 Dec 2017 23:01:17 +0000 Received: from MWHPR16MB1488.namprd16.prod.outlook.com ([10.175.4.146]) by MWHPR16MB1488.namprd16.prod.outlook.com ([10.175.4.146]) with mapi id 15.20.0302.017; Mon, 18 Dec 2017 23:01:17 +0000 From: Brian Witten To: Paul Wouters , Stephen Farrell CC: "patient@ietf.org" , "saag@ietf.org" Thread-Topic: [EXT] Re: [saag] [Patient] Internet Draft posted as requested - Thread-Index: AQHTeDShd1yZtpRskESPqueRR6NGWqNJtPZv Date: Mon, 18 Dec 2017 23:01:17 +0000 Message-ID: References: <19005081-c8fc-8090-d6f6-ab61855db793@cs.tcd.ie>, In-Reply-To: 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=brian_witten@symantec.com; x-originating-ip: [155.64.38.94] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR16MB1488; 6:ZcWKtlTEoQZ8KnN+O0dJ2CoD8lJ6+yccLN44xhBJlcwdp7pdpfmK20zPAti4MHbtwDFGXdNskacD09I2jC0ASYK9oqGM1ir9broCi4WJT+Fgpzvjl5SqKi7+cCqMQf23uiG4q/2R0qsCIKX/sXSPzQr5Gj/UmZi40LoSyMGct+M2dqgOpVOR19f3nTk/m2nR8rQBjaBiUCZJO77XtCVjxyL9fXpSDvH0uYwWjpmbUsDODBZg3C2C+4brN8DIPI52BoGs/4raYXKgqJr+AzH9ymjHUHBM0SlLCdYqGsMxsY9NnBCR3Mm7lswPpkJDLMIaoW0H4Eq9rdVxm6Y9SAtICjhgMpzjvxT1qeTYPsu8et0=; 5:65JPDqwjah0YFi5MxwpHAKTThN9qq9gLDCHhMU8i6p1LhdGzPtiQ7AkHhQ7I21a02PiTLD+aQ0Z+UvgIZ/heYlEANixJrz0ne4bgK9/Tybkqdr3CHpuc7NoHyQM+FMNEj/zJImb3nmuPMQoaoG9EVCMsQ+KOb39lDEj3GY+nvfM=; 24:+cQY29R+H/NoksclwXiC+gmOuBNhpCT7ScQ5pFPA+pQrXX1Y95HJqcKvTLhkGYL+0zEd/hmgfqHpajfmFWXyqxvHMgQ8qdyB4eMx5/nVJ1U=; 7:uvaCaXQ0sGNlYZzaXxXAV1MI1/uZKm8wP1wKPvofDSH8KEp0XMlUvjnYrbMt07TjmgbffqF5Gk8IYGbTA5Xx/AC5inqomr4eA3eAL7HcLKvij0chQYuwr7jLt3j2ezbJGKHQ6dgrk5Xs9EaIDPFEH4kwMwpLdz01jmSuAug5rRxaOiS2jHQnPAWa0NUccUslGDQlvGpq+ZXC9kajv9T67O8JXSKsX7LQU8dFpPgMEbndgNL0AY2a/XtW9BYsxIlx x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0e389f8c-9e05-49f6-65f2-08d5466b3efe x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:MWHPR16MB1488; x-ms-traffictypediagnostic: MWHPR16MB1488: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(258766100185102)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231023)(93006095)(93001095)(6041248)(20161123564025)(20161123555025)(20161123558100)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR16MB1488; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR16MB1488; x-forefront-prvs: 0525BB0ADF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(346002)(366004)(39860400002)(43784003)(189003)(199004)(24454002)(7736002)(54906003)(2900100001)(110136005)(74316002)(97736004)(6506007)(93886005)(966005)(14454004)(305945005)(99286004)(53546011)(76176011)(316002)(59450400001)(7696005)(2950100002)(6306002)(105586002)(3846002)(6116002)(77096006)(102836003)(68736007)(575784001)(3660700001)(9686003)(10290500003)(478600001)(8676002)(81156014)(66066001)(81166006)(106356001)(2906002)(53936002)(4326008)(5660300001)(6246003)(6436002)(3280700002)(229853002)(33656002)(8936002)(55016002)(25786009)(86362001)(9010500006); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR16MB1488; H:MWHPR16MB1488.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: symantec.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0e389f8c-9e05-49f6-65f2-08d5466b3efe X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2017 23:01:17.4160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR16MB1488 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsXCFeXNqXvAwyLK4P9EPouXB4wt3t+6xGQx pb+TyWL63mvsDiwea7uvsnksWfKTyeP7PKYA5igum5TUnMyy1CJ9uwSujL+/drMVnFequNR2 jamB8Y5MFyMnh4SAicS3i7/Yuxi5OIQEPjJKHNj0hRUm0fK+gw0i8Z1R4uHzWYwgCSGBo4wS P897QiReMEoc/XaSGcRhEehklni5cxkrRNUUJolH0+Ihqo4wSix59wKsnU1AT+Lo3ztgRSIC fhI7l10AizMLeEl8mvucBcQWBopfed8GVRMo8fPyDSCbA8g2krh4KwokzCKgKvHry0GwEl6B GIkl+zqYIHa9ZpdYPe8g2ExOAUeJ38cfsYHYjAJiEt9PrWGC2CUucevJfCaIPwUkluw5zwxh i0q8fPyPFaI+RuLU2ldQcQWJRT/boGxZiUvzuxlBlkkIHGKXOPP9G9QgPYmtE98yghwqIeAr 8bDNBqJmCaPEjgOn2SBqtCSWN01hg6jJlrg6wXYCo/EsJCdB2HoSN6ZOYYOwtSWWLXzNPAvs T0GJkzOfsCxgZFnFqJBYnFScW5JfWpJYkGpgqFdcmZsMIhKBKSZZLzk/dxMjOM38kNzBeOSE zyFGAQ5GJR5eCV2LKCHWxDKgykOMEhzMSiK8fmfNo4R4UxIrq1KL8uOLSnNSiw8xSnOwKInz TvqmFiUkkJ5YkpqdmlqQWgSTZeLglGpgbI9qCj0yX7TUsf/pz8NPqvhNZt3sFUl/mfYk6XNo yoa7h1Zs1Sgv0zvsar/x+k+bo2ktM3Vez+xf2bx5X+yVBMXTlZq3jeRC94TP1/NPustmx/F6 nqF/5vPfKw583Pnu5fQd+z46+yS92Dp7SZ71z2oJiyDJgPVB76u6dt4WVBf7kKTTLDX9vRJL cUaioRZzUXEiAEW972cvAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42LhivLm0D3gYRFlcPQPl8XLA8YW729dYrKY 0t/JZDF97zV2BxaPtd1X2TyWLPnJ5PF9HlMAcxSXTUpqTmZZapG+XQJXxt9fu9kKzitVXGq7 xtTAeEemi5GTQ0LARKLlfQdbFyMXh5DAd0aJh89nMYIkhASOMkr8PO8JkXjBKHH020lmEIdF oJNZ4uXOZawQVVOYJB5Ni4eoOsIoseTdC7B2NgE9iaN/74AViQj4SexcdgEszizgJfFp7nMW EFsYKH7lfRtUTaDEz8s3gGwOINtI4uKtKJAwi4CqxK8vB8FKeAViJJbs62CC2PWaXWL1vINg MzkFHCV+H3/EBmIzCohJfD+1hglil7jErSfzmSD+FJBYsuc8M4QtKvHy8T9WiPoYiVNrX0HF FSQW/WyDsmUlLs3vZgRZJiFwiF3izPdvUIP0JLZOfMsIcqiEgK/EwzYbiJoljBI7Dpxmg6jR kljeNIUNoiZb4uoEW4hwrkTL8R3MEPULmIEB95dlAqP+LCS3Qth6EjemTmGDsLUlli18zTwL HACCEidnPmFZwMiyilEhsTipOLcktyQxsSDTwEivuDI3GUQkAlNMsl5yfu4mRnCa+S2+g/Hc H59DjAIcjEo8vDOumkcJsSaWAVUeYpTmYFES532swRQlJJCeWJKanZpakFoUX1Sak1p8iJGJ g1OqgTHo3CnZzOSuGJH13zPKrKf/yA8v4c7qXD1xVcVdRe4y5TM31IsKmLbk59WssLzPa846 k6FSSOkPa9GTnZd9JRiL7s7gKL7CVTfh3+sr7Xt++RQaMUz30jzldcJ7Y99VwVOFZ0pPal// r1ZoyyN36kTSFaeXmjcOVcVlb3pawtG/8IR57CbvrUosxRmJhlrMRcWJAJB88EIUAwAA X-CFilter-Loop: ASB04 Archived-At: Subject: Re: [saag] [EXT] Re: [Patient] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 23:01:24 -0000 Hi Paul, Thanks Again. Re, "...NOT be in the possession of any private key material that will allo= w it to impersonate the client identity to a remove (sic, remote) server," = I believe this could be achieved through "mutual authentication leveraging = client-side certs," where the client-side certs are provisioned either thro= ugh in-factory credential-provisioning, which is quite common in IOT today,= or through some other provisioning mechanism, such as Enterprise PKI or ho= w some banks do "out-of-band" (OOB) credential provisioning to client devic= es. Of course, the keys & roots need to be set up properly so that the ser= ver can verify the client-side credentials and the Protection Service can't= forge such credentials, but that's straight forward. That would seem to p= revent impersonation. Also, the client could then also it use it's Private= Key to sign anything it sends back to the server, "akin to Stickler, but p= roviding end2end integrity protection from the client back to the server." = Please LMK if you disagree? Either Way, Thank You Again! Brian =20 From: saag on behalf of Paul Wouters Sent: Monday, December 18, 2017 11:15 AM To: Stephen Farrell Cc: patient@ietf.org; saag@ietf.org Subject: [EXT] Re: [saag] [Patient] Internet Draft posted as requested - =A0=20 On Mon, 18 Dec 2017, Stephen Farrell wrote: > If the proponents of these mitm schemes honestly and openly > faced up to such issues and argued for another decades-long > arms-race and acknowledged the downsides (e.g. assisting > censorship, breaking all sorts of application assumptions, > and enabling pervasive monitoring) of mitm'ing https and/or > tls then that at least would be credible. It'd still be a bad > plan, but at least one for which we could discuss the technical > (de)merits and not have to deal with the nonsense claims such > at the one we both noted above. If we did an use-cases document for this, to seperate the technical aspects from the business aspects, the first item I would insist on would be: - Protection service MUST NOT be in the possession of any private =A0=A0 key material that will allow it to impersonate the client identity =A0=A0 to a remove server. If a client wants to delegate this responsibilit= y, =A0=A0 it MUST be able to communicate this to the server and the server MUS= T =A0=A0 be able to deny such a request (upon which the client may decide to =A0=A0 close the connection) The problem here is that providers of these services don't want to double the traffic load where the client decrypts then forwards for blessing. But simply insisting that decryption has to move to the network service isn't going to work. Another way to accomplish this would be to have signed web pages, so clients could send hashes for verification. But in today's dynamic web that is also pretty problematic and would require major changes. Of course it has the benefit of the provider not even being able to read the users content. The IETF discussion should not center around the business model, but should center around designing (or not) a useful new protocol or existing protocol modification that addresses a well defined issue. Instead, I hear about desires and potential business models and how some of our new technology has affected existing business models. I also detect a culture clash where I see a lot of praise to proponents and opponents without technical backing. At the IETF, we try to reach consensus based on technical merit, for example by stating you agree or disagree with certain items and why, and don't do "me too" messages to get a count. Paul _______________________________________________ saag mailing list saag@ietf.org https://clicktime.symantec.com/a/1/fiazdLFK3QUq7FT-i8r9StLrGbk9GfOa_1goF9oh= iHM=3D?d=3DpDpEfizpaOoyRJu2SzY3dci6RLYb38UoHcO56rWd_Waa-XH4XaU_PbZEq2F_Ots1= eFq9hFcrLyPIEy48XVNkNuVNaOs-hoRY9sYCvwwTKpc4f-YKEqzZth1bnGLIzloRCg-0QnQdNv5= 6mIQtGktlHz8TajPdmMikqWjbs6jf4VPYjcczDAj9jNyaxcx2IKQYHLloy8tT3EpQiziv7EBh2X= dL0QhQnkkhSzCFPg_DkAVAp0nHRv2IKkK8evQNjlGIG5n4l5H7ZK-c5O7bxd8T5NvfXPwX_fA1a= XxbKcyxcBBCAsuxquW-NErNyP3CsvoqB9y33t-tWDXxs9RHYaIEEdCZpVKVj6nws46A-ieYJWuM= ViPN3fvhBKGW1VS3xyIUDcLeTBbhiy_-WdDGzGvoxW-BueESNFM%3D&u=3Dhttps%3A%2F%2Fww= w.ietf.org%2Fmailman%2Flistinfo%2Fsaag = From nobody Mon Dec 18 16:19:00 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75406126C22; Mon, 18 Dec 2017 16:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 Kt1MvcnFXHPQ; Mon, 18 Dec 2017 16:18:54 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30105.outbound.protection.outlook.com [40.107.3.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E11A12422F; Mon, 18 Dec 2017 16:18:54 -0800 (PST) Received: from AM5PR0602MB3251.eurprd06.prod.outlook.com (10.167.170.156) by AM5PR0602MB3249.eurprd06.prod.outlook.com (10.167.170.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Tue, 19 Dec 2017 00:18:51 +0000 Received: from AM5PR0602MB3251.eurprd06.prod.outlook.com ([fe80::5e9:e441:e61f:7696]) by AM5PR0602MB3251.eurprd06.prod.outlook.com ([fe80::5e9:e441:e61f:7696%13]) with mapi id 15.20.0323.018; Tue, 19 Dec 2017 00:18:51 +0000 From: "Diego R. Lopez" To: Stephen Farrell , Brian Witten , "patient@ietf.org" , "saag@ietf.org" Thread-Topic: [Patient] [saag] Internet Draft posted as requested - Thread-Index: AQHTd42wukyhoX4twUmW0ABJZQSMiaNIPdsAgAGhsYA= Date: Tue, 19 Dec 2017 00:18:51 +0000 Message-ID: <98E78B0A-0351-4702-98F5-62DAF2C125CD@telefonica.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.8.0.171210 authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-originating-ip: [83.42.130.160] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0602MB3249; 6:fCWufTc9rsNvzqUFs2xI84kIXariHS+VnypwrnuVuzWv1JTKMOWX0+PP5cwTl0OnStBKONOQHgpg5sQnAu0MNPc2AjasQ29y/WG6l8+ZV2LFy2SJwHPfDaQHY64CzgxgD349ncmnGXUccEE4qHIEgULl1N44A2VhSFHd97/qx3UuX6LP4ZreF0gLnyvdy+HiGKzsZq/6UOqIVM1pXcEkYQjXuHsSMfU3dl/lbMzEx1hIuXzbgiZGRSB4sU8eKHsys6jYhnfbggDx0Ut7X3QDcX7dyV58P0ZiDNZKULyN0QqBvWPSmu9r0Y32AcgMEVeun/dCwhjafWktdRLpTJS5oje5oXj5AJOe/OCvPsUtqGc=; 5:wGfn58HIVU+ry+8nSVoqkAgRo9b+bL20eYbR9T7MbyQ0zixL6aOCCpYrPpNmlwvLJyFMxpJ8UpxmFQtd95TOz0fVtCftmAXrOi3dXtoyC2jjgtHGlDcBlgQcpj0DPu7EyZVGusIlh9k7P+n1RL6xYnhdKGIeThIjdivA0NYtNPk=; 24:HixjhGwRKT2jQJTc+cqe64EPkaL0DwAJ6SkVMYAxlv6DjnSiWk7XPHyJt6alfFjPM6o8RaBwTIf0GEdzmt2Z5Hvn6VSYbeOLahPqfRGjOdg=; 7:6BqphXct4fX+88bnuQxuL/Cg99p+h+8umDIq4+aw1gL/vuN9GFEqXivGJL2akN6vSUkLVhxYCIMUbGjKgjPyRcckXAFL+EDRsjkO8joQZMaqXfHLC9rTCakr7C0XmVPVXUaBzpYsi8HT/56LzRDRVQuFJuvlyea97qHnL5O6aK0im3XSS1T0xj6se7jt2k9YgPLBecijVdQskdG1I6mgtl3pYmtHGJ/rbO2GRF6koLAzM6eLyMa1oMTN6uohDXrg x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: aa744c2e-d83a-4500-54c7-08d546761537 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603307); SRVR:AM5PR0602MB3249; x-ms-traffictypediagnostic: AM5PR0602MB3249: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(40392960112811)(192374486261705)(128460861657000)(81160342030619); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231023)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(20161123558100)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011); SRVR:AM5PR0602MB3249; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM5PR0602MB3249; x-forefront-prvs: 052670E5A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(346002)(396003)(376002)(252514010)(24454002)(199004)(189003)(25724002)(40134004)(229853002)(2900100001)(966005)(82746002)(6486002)(93886005)(2906002)(99286004)(83716003)(316002)(6436002)(76176011)(2201001)(478600001)(83506002)(25786009)(8936002)(86362001)(58126008)(2950100002)(110136005)(6512007)(97736004)(3280700002)(5660300001)(8676002)(36756003)(6306002)(106356001)(7736002)(105586002)(14454004)(68736007)(81156014)(81166006)(53546011)(305945005)(66066001)(786003)(6246003)(45080400002)(5250100002)(6506007)(3660700001)(59450400001)(102836003)(3846002)(53936002)(6116002)(33656002)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0602MB3249; H:AM5PR0602MB3251.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9544009794314C44958234F7869E5534@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-Network-Message-Id: aa744c2e-d83a-4500-54c7-08d546761537 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2017 00:18:51.7888 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0602MB3249 Archived-At: Subject: Re: [saag] [Patient] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 00:18:58 -0000 SGkgU3RlcGhlbiwNCg0KSSBhZ3JlZSB3ZSBzaG91bGQgbm90IGJvcmUgdGhlIGxpc3QgKGFuZCBv dXJzZWx2ZXMpIHJlcGVhdGluZyB0aGUgZGlzYWdyZWVtZW50cyB3ZSBoYXZlLiBUaG9zZSBhcmUg dGhlIGtpbmQgb2YgZGlzY3Vzc2lvbnMgZm9yIHRoZSB0aGlyZCBvciBmb3VydGggYmVlcnMuLi4N Cg0KSnVzdCBsZXQgbWUgcmVtYXJrIGEgY291cGxlIG9mIHRoaW5ncyBJIGhhdmUgc2VlbiB3aGVu IHJldmlld2luZyB0b2RheSdzIG1lc3NhZ2VzIHRoYXQgSSB0aGluayBhcmUgd29ydGggbm90aW5n Og0KDQoxKSBZb3UgZG8gbm90IG5lZWQgdG8gYnJlYWsgVExTIG9yIEhUVFBTLCBhcyB0aGVyZSBh cmUgcG90ZW50aWFsIGFsdGVybmF0aXZlcyB0aGF0IGNvdWxkIGJlIGFwcGxpY2FibGUsIGRlcGVu ZGluZyBvbiB0aGUgY2FzZS4gRm9yIElvVCBlbnZpcm9ubWVudHMgSSBmb3Jlc2VlIG11bHRpcGFy dHkgc2VjdXJpdHkgY291bGQgYmUgYSByZWFzb25hYmxlIGNob2ljZS4gRm9yIHBlcnNvbmFsIGVu dmlyb25tZW50cywgSSB0aGluayBQYXVsJ3MgaWRlYSBvZiBkZWNyeXB0LWFuZC1ibGVzcyBjb3Vs ZCBiZSBzb21ldGhpbmcgaW50ZXJlc3RpbmcgdG8gZXhwbG9yZS4gQW5kIHJlcGx5aW5nIHRvIE1l bGluZGEsIHRob3NlIHByb3Bvc2FscyBkbyBub3QgaW1wbHkgc2hhcmluZyBzZXNzaW9uIGtleXMg KHRob3VnaCB0aGVyZSBpcyBhIGRyYWZ0IG9uIGVudGVycHJpc2UgZGF0YWNlbnRlcnMgYXJndWlu ZyBmb3IgYSByZWxhdGVkIGFwcHJvYWNoIHRoYXQgSSB0aGluayBoYXMgYSBzb2xpZCBjYXNlIGJl aGluZC4uLikgSW4gc3VtbWFyeTogdGhlcmUgYXJlIG9wdGlvbnMgb24gdGhlIHRhYmxlIHRoYXQg ZGVzZXJ2ZSBzb21lIGF0dGVudGlvbiwgYW5kIGRvIG5vdCBpbXBseSBicmVha2luZyBUTFMNCg0K MikgV2hhdCBJIGhhZCBpbiBtaW5kIHdoZW4gcmVwbHlpbmcgdG8geW91IHdhcyBub3QgYXJiaXRy YXJ5IHJvdXRlcnMsIG9yIFdpRmkgQXBzLCBvciBhbnkgb3RoZXIgbmV0d29yayBib3ggYmVpbmcg YXV0aG9yaXplZCB0byBpbnNwZWN0IGVuY3J5cHRlZCB0cmFmZmljLiBJIGZvcmVzZWUgYSBzaW5n bGUgKG9yIHZlcnkgZmV3KSBlZGdlIGRldmljZXMgdGhhdCBhcmUgcHJvcGVybHkgYXV0aGVudGlj YXRlZCwgYXV0aG9yaXplZCAoaW4gYSBQb0Mgd2UgaGF2ZSB3ZSBldmVuIGF0dGVzdCB0aGVpciBz b2Z0d2FyZS4uLikgdXNpbmcgdGhlIHNhbWUga2luZCBvZiBUVFBzIHlvdSBtZW50aW9uLg0KDQpC ZSBnb29kZSwNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8i DQoNCkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cHM6Ly93d3cubGlua2Vk aW4uY29tL2luL2RyMmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5j b20NClRlbDogICAgICAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogICszNCA2ODIgMDUxIDA5 MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K77u/T24gMTgvMTIvMjAxNywg MDE6MjMsICJTdGVwaGVuIEZhcnJlbGwiIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPiB3cm90 ZToNCg0KDQogICAgRGllZ28sDQoNCiAgICBJIGdlbmVyYWxseSBkaXNhZ3JlZSB3aXRoIHNvbWUg b2YgeW91ciBlYXJsaWVyIHBvaW50cyB3aGVyZQ0KICAgIHlvdSBkaXNhZ3JlZSB3aXRoIG1lOi0p IEkgZG8gYWdyZWUgdGhhdCB0aGVyZSBhcmUgaGFyZA0KICAgIHByb2JsZW1zIHdpdGggdXBkYXRl cyBhbmQgYnVncyBpbiBnZW5lcmFsIGZvciBlbmRwb2ludHMgYW5kDQogICAgZGV2aWNlcyBpbiB0 aGUgbWlkZGxlLiBJIGRvbid0IGFncmVlIHRoYXQgYnJlYWtpbmcgVExTIG9yDQogICAgSFRUUHMg aXMgYSB2aWFibGUgd2F5IHRvIGltcHJvdmUgdGhhdCwgSXQnZCBtYWtlIGl0IHdvcnNlLg0KICAg IEJ1dCByYXRoZXIgdGhhbiByZXBlYXQgdGhpbmdzIEkndmUgc2FpZCB0byB5b3UgaW4gcGVyc29u DQogICAgYmVmb3JlLCBmb3IgdGhpcyB0aHJlYXQsIG1heWJlIGl0IGlzIHdvcmsgc2F5aW5nIHRo YXQgdGhlDQogICAgcHJvcG9uZW50IGhlcmUgY2xhaW1lZCB0byBiZSBpbnRlcmVzdGVkIGluIGEg bmV3IG11bHRpcGFydHkNCiAgICBzZWN1cml0eSBwcm90b2NvbCAoaW4gdGhlIG1haWxpbmcgbGlz dCBkZXNjcmlwdGlvbikgd2hpY2gNCiAgICBjb3VsZCBoYXZlIGJlZW4gYSB3b3J0aHksIGlmIHVu bGlrZWx5IHRvIHN1Y2NlZWQgZW5kZWF2b3VyLg0KICAgIEluIFNpbmdhcG9yZSwgSSBjb25jbHVk ZWQgdGhhdCB0aGV5IGFyZSBwcmltYXJpbHkgb3IgbWF5YmUNCiAgICBvbmx5IGludGVyZXN0ZWQg aW4gdGhlIHdlYiBhcyB1c2VkIGJ5IHBlb3BsZSBhbmQgaW4gbWl0bSdpbmcNCiAgICB0aGF0LiBT byBwZXJzb25hbGx5IEkgdGhpbmsgdGhlIHNlcGFyYXRlIG1haWxpbmcgbGlzdCB3b3VsZA0KICAg IGJlIGJldHRlciBjbG9zZWQgZG93biBhcyBpdCBzZWVtcyB0byBoYXZlIGJlZW4gc3RhcnRlZCBv bg0KICAgIHRoZSBiYXNpcyBvZiBzb21lIGNvbmZ1c2lvbiB3cnQgZm9sa3MnIGdvYWxzLg0KDQog ICAgT24gMTcvMTIvMTcgMjM6MTksIERpZWdvIFIuIExvcGV6IHdyb3RlOg0KICAgID4NCiAgICA+ IEkgYW0gYWZyYWlkIEkgZG9u4oCZdCBmb2xsb3cgeW91IGhlcmXigKYgV2hhdCBkbyB5b3UgbWVh biBieSDigJxyYW5kb20NCiAgICA+IG5hbWUvYWRkcmVzcyB0aGF0IGNsYWltcyB0byBiZSDigJxn b29k4oCd4oCdPyBHaXZlbiB0aGVyZSBhcmUgYXBwcm9wcmlhdGUNCiAgICA+IHJvb3RzIG9mIHRy dXN0LCBob3cgaXMgdGhpcyDigJxyYW5kb23igJ0gdHJ1c3QgZGlmZmVyZW50IGZyb20gdGhlDQog ICAgPiBjZXJ0aWZpY2F0ZSB2ZXJpZmljYXRpb24gcHJvY2VzcyBpbiBUTFM/DQogICAgVGhlIGRp ZmZlcmVuY2UgaW4gdGhlIGFib3ZlIGNvbnRleHQgaXMgdGhlIHRoZSBwcm9wb25lbnRzDQogICAg aGVyZSB3YW50IFRUUHMgdGhhdCB0ZWxsIGxpZXMgYWxsIHRoZSB0aW1lLCBhbmQgdGhhdCBhcmUN CiAgICBzbyB3aWRlLXNwcmVhZCBhbmQgbm90IHdlbGwta25vd24gdGhhdCB0aGV5IGFwcGVhciB0 byB0aGUNCiAgICBlbmRwb2ludHMgaW5kaXN0aW5ndWlzaGFibGUgZnJvbSBhIHJhbmRvbSByb3V0 ZXIuIFRoZSBwdWJsaWMNCiAgICBXZWIgUEtJIFRUUHMgd2UgaGF2ZSBhcmUgZmFyIGZyb20gcGVy ZmVjdCBidXQgYXQgbGVhc3QgdGhleQ0KICAgIGRvbid0IGRvIHRoYXQgc28gZmFyLg0KDQogICAg VGhlcmUgYWxzbyBhcHBlYXJzIHRvIGJlIHNvbWUgbWFnaWNhbCB0aGlua2luZyB0aGF0IGFsbG93 cw0KICAgIHNvbWUgcHJvcG9uZW50cyB0byBzYXkgdGhhdCB0aGV5IHRoaW5rIHRoZXNlIG5ldyBs aWVzIGNhbg0KICAgIGJlbmVmaXQgdGhlIHVzZXIgYW5kIGdpdmUgdGhlIHVzZXIgbW9yZSBjb250 cm9sLiBJIGhhdmUgbm8NCiAgICBjbHVlIGhvdyB0aGF0IGNhbiByZWZsZWN0IGEgZ2VudWluZSB0 ZWNobmljYWwgb3Bpbmlvbi4NCg0KICAgIFMuDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4g ZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFj acOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8g ZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRl c3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwg dXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1 ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUu IFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5v cyBsbyBjb211bmlxdWUgaW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2Nl ZGEgYSBzdSBkZXN0cnVjY2nDs24uDQoNClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9u IGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5h bWVkIGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5h dGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9u IGluIGVycm9yLCBkbyBub3QgcmVhZCBpdC4gUGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRo ZSBzZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJy b3IgYW5kIHRoZW4gZGVsZXRlIGl0Lg0KDQpFc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2Ug ZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIg aW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBvdSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBl eGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9z c2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlvIGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUg cXVlIGEgbGVpdHVyYSwgdXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2Vt IGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHD p8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3Mt bGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEg ZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8Ojbw0K From nobody Tue Dec 19 02:43:08 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55926127873; Tue, 19 Dec 2017 02:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 0SG7aLRJHVb8; Tue, 19 Dec 2017 02:43:05 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 072B5127869; Tue, 19 Dec 2017 02:43:04 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id vBJAgtTB008354 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Dec 2017 12:42:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id vBJAgqwp018010; Tue, 19 Dec 2017 12:42:52 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <23096.60715.827133.431108@fireball.acr.fi> Date: Tue, 19 Dec 2017 12:42:51 +0200 From: Tero Kivinen To: Brian Witten Cc: Stephen Farrell , "Diego R. Lopez" , "patient\@ietf.org" , "saag\@ietf.org" In-Reply-To: References: X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 44 min X-Total-Time: 49 min Archived-At: Subject: Re: [saag] [EXT] Re: [Patient] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 10:43:06 -0000 I have not followed this discussion in Singapore or in the patient list, so my knowledge about this is what has been sent to here to the saag list, so I am sorry if I misunderstood something. Brian Witten writes: > Where you say, =E2=80=9CMiddleboxes are as likely to have bugs,=E2=80= =9D this is of > course completely consistent with my emphasis in Singapore that =E2=80= =9Call > software has bugs & vulnerabilities,=E2=80=9D including both endpoint= s and > network appliances, virtual and physical. > > One of my points that you might=E2=80=99ve missed in Singapore was th= at > =E2=80=9Cwhen something goes wrong,=E2=80=9D such as a vulnerability = being > exploited, I=E2=80=99d much rather have that "blow up" in some remote= (and > easily reset) network thing (virtual appliance, container, or > lambda) rather than in the endpoint. I do not agree on that. I think it is better to have something to "blow up" in some location that I can actually do something about. If my laptop blows up, I can reboot it myself and install updates to it when it boots up. If some remote cloud based system crashes, it will most likely crash again when I try to do same thing again, and I have no control on updating the software in there. If my IoT device crashes when someone makes some new remote attack to it, I will change configuration of my local "thing" called firewall and block all access to IoT device, except to those few addresses it will need to connect to. IoT devices usually only require connection to the one of two locations, i.e., their own cloud service, or to my local home are IoT gateway. In both cases protecting the IoT device is best done by limiting access to device using normal firewall rules. Installing firewall rules does not require seeing the traffic inside the encrypted flow. I might also want to add rule to say that the IoT device is only allowed to talk to the given IP address using some specific certificate (i.e., perhaps implement certificate pinning on the firewall), or even make separate TLS session from the firewall to the vendors cloud and run tls inside tls to protect the IoT device. > Why=3F Network =E2=80=9Cthings=E2=80=9D can be dedicated to flows tha= t are specific to > a remote endpoint, like a client running a set of proxies in a cloud > based infrastructure that they and millions of others trust, with > each software instance of the proxy dedicated to mediating > communication with a different server. > > In this context, if the server hacks the middlebox, it only hears > it=E2=80=99s own conversation with the client. > > In contrast, if the server manages to hack a client, it > can hear all that client is doing, including today lots of location > based information, as well as seeing state accumulated from past > conversations with other servers. My local endpoint can similarly be dedicated to the flows, i.e., I can run separate hardware protected address space for every single web page I am viewing (I.e., start separate unix process for each web page). I think some browsers might actually do that, as it also means that if that process dies, you only loose one tab not the whole browser... Then you say that there can be attacks which breaks out from the jail and manages to attack my whole operating system, but same is possible also with the network "thing". I.e., worst case is that someone manages to make attack that will break out from the cloud based network thing and manages to gain access the actual operating system and then to perhaps even the virtualization system also. Note, that in this case the attacker might be both the server and client using the "thing". i.e., attacker can use the server it controls with the client it control to attack the clould based network "thing" that millions of people are trusting, and gain access to everything that goes through that cloud based system. This kind of attack is much worse than getting access to all traffic one user is sending / receiving. There is no difference what kind of protections can be done on the "things" in network or in the local end point. Both can be written using secure methods, or they can be written in not so safe ways and contain huge security vulnerabitilies. Updating the local endpoint might be faster or slower than updating the network "thing". Latest operating systems will automatically install critical security updates, browsers already either install updates automatically or inform you about new updates immediately when they are available. The problem with partially invisible "things" is that for end user do not have good visibility to them, and end user might not even be able to update it, but must wait for the vendor to put out update. > So, I=E2=80=99ll stand by my two assertions: =E2=80=9CAll software ha= s > vulnerabilities,=E2=80=9D and =E2=80=9CWhen things go wrong, I=E2=80=99= d rather have them go > wrong in an easily reset network thing, much rather than having > things go wrong in the endpoint.=E2=80=9D I rather have things go wrong in location which I control, and which I can update so after the update everything works. I do not like to wait for days or weeks (or months/years) to get vendor install update. My laptop vendor has not yet published updates for the Intel ME firmware bugs.... > Back to the thought that =E2=80=9Call software has vulnerabilities,=E2= =80=9D taking > the discussion further, in fact, just as some endpoints have more > vulnerabilities than others, some network appliances have more > vulnerabilities than others. That=E2=80=99s of course among the reaso= ns I > believe it=E2=80=99s good for endpoints to know as much as possible a= bout > the network appliances which they are considering trusting with > cleartext. Usually also the fewer features the software has, the fewer vulnerabilities it also has. Basic firewall doing blocking based on the TCP flows and IP/port numbers is much simplier than full stack application gateway acting as man in the middle of my encrypted communications. I would trust much more with the basic firewall "thing" than much more compicated cloud based network "thing". > Some people in this discussion have proposed narrowing the scope so > that endpoints only trust a set of well-known, manually > pre-configured set of such appliances, but still tackle challenges > like end2end integrity. I think set of well-known pre-configured set of device is good idea for most of the IoT devices. IoT devices usually do not want to talk to random devices in the internet, they will need to talk to the few things pre-configured to them. And for that filtering basic firewall is usually enough. This does not work for laptops or similar, but works for most of the IoT devices. > Power users might choose to run their own protection in their own > cloud based infrastructure, but that=E2=80=99s not a random person. > > Many people choose to have someone or something help protect them. >=20 > Many employees choose to let their employer help protect them. Usually employees do not have choice, the employer will choose to "help protect" them and employee cannot opt-out... > Many people often choose to have security companies help protect > them. And quite often people do not choose that either, it is chosen for them by their laptop vendor pre-installing all kind of junk on their new laptop which is almost impossible to get rid of...=20 > Some people choose to have network providers help protect them. Again quite often there is no opt-in in that, the ISP will "protect" its users regardless whether they want or not. > I believe people have a right to choose who protects from them from > potentially malicious servers. Yes, they should have right to choose, but in most cases they do not. The protection is done in a way they cannot choose not to do it or even who does it. All this is done to protect the "normal" user, so "normal" user cannot disable security "software/thing" installed on path by laptop vendor / employer / ISP etc... > I believe people have a right to choose protection from someone > other than the endpoint maker and someone other than the remote > server. Perhaps. I think the logical way of doing that is to install software (agant) on their endpoint they want to protect and use that to do the opt-in...=20 --=20 kivinen@iki.fi From nobody Tue Dec 19 12:39:07 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C799212D858; Tue, 19 Dec 2017 12:39:00 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=cIP0PVnX; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=jroOeya1 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 Z_DnvY_u02-q; Tue, 19 Dec 2017 12:38:58 -0800 (PST) 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 21F3B12D84B; Tue, 19 Dec 2017 12:38:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1513715938; x=1545251938; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8znu+drI66u2wOT6cKvNAdn5LrEUL2ayzg39jgE3ti8=; b=cIP0PVnXTE78eqhcko+yUXXQvFynne+wOOQnJ8y6GCx4LTNBJohSdfyc 5bXeSbiZby6GFwiZ2RNzASU+eAegGEOPdluMMh9/4BXU4YPRFYOS6nq2r ZSroxBaDUBBYW2jV8sVOF2P0biw5Hbf69RsP/sELFhNz8sOd1iP3txzpV 8=; IronPort-PHdr: =?us-ascii?q?9a23=3A0qkkjhK4hsUkbFlY+dmcpTZWNBhigK39O0sv0rFi?= =?us-ascii?q?tYgfKv7xwZ3uMQTl6Ol3ixeRBMOHs6sC07KempujcFRI2YyGvnEGfc4EfD4+ou?= =?us-ascii?q?JSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47xaFLIv3K98yMZFAnhOgpp?= =?us-ascii?q?POT1HZPZg9iq2+yo9JDffxhEiCChbb9uMR67sRjfus4KjIV4N60/0AHJonxGe+?= =?us-ascii?q?RXwWNnO1eelAvi68mz4ZBu7T1et+ou+MBcX6r6eb84TaFDAzQ9L281/szrugLd?= =?us-ascii?q?QgaJ+3ART38ZkhtMAwjC8RH6QpL8uTb0u+ZhxCWXO9D9QKsqUjq+8ahkVB7oiD?= =?us-ascii?q?8GNzEn9mHXltdwh79frB64uhBz35LYbISTOfFjfK3SYMkaSHJBUMhPSiJBHo2y?= =?us-ascii?q?YYgBD+UDPOZXs4bzqFQVoBuiHgahAP/jxiNUinL026AxzuQvERvB3AwlB98Cvm?= =?us-ascii?q?nZrNHvO6gOUuC51LTDwzvZYPNI2Dfy9YbEeQ0mrP+CR71wb8vRxlQ1Gw7YilWf?= =?us-ascii?q?s5DqPzCO2+sQrWeb6+5gWfizhG4grgF8uz6izdovhInRno8Yy1PJ+T9nzIs7O9?= =?us-ascii?q?G0UlN3bN6rHZdKsyyXNJN6Tt4+T21ypio3xL4LtYS0cSUF0pgr2hDSZv+ff4iG?= =?us-ascii?q?/B3uV/qdLDJ9iX9md7+ygxiy/E2gx+LhTMa4zlNHojdYntbXs30A2BLe58uHR/?= =?us-ascii?q?Z740yvwyyA1xrJ5eFBOU00kK3bJIM/zbMojZoTtFjDHjfxmEXrkK+abkUk9fas?= =?us-ascii?q?6+TgerjpuIScOJV7hw3kL6shhMi/AeAhPggJQmib5f+z1Lr+/U3/XbpGkOc6kq?= =?us-ascii?q?jBsJDaIMQaqbS1DBNS0oYm8xq/DjGm38oEnXQfLV9IewiLg5bnNl3QOvz0EPey?= =?us-ascii?q?jlu2nDpvxP3KJrjhDY/MLnjHnrfhZ7F960tExQQ9199f+ZNUBawbLP/uXk/+rs?= =?us-ascii?q?DXDhwiPgOp3ennDNF92pkCVmKIB6+VKLnSvkOQ5uIzP+mMY5cYuC3nJPc/6P7j?= =?us-ascii?q?ln45lkEBfamnx5cXb2q4Hvt+KUWDfXXsmssBEXsNvgcmVOzlkkGCUT9NaHa0Q6?= =?us-ascii?q?Ix/TA7B5y6DYfNXIyth6aB3CjoVqFRM1xLEFfEMnb2doOJXb9YayOMI8lslBQF?= =?us-ascii?q?VrnnRY53hj+0swqvgZBjJ+HXvmU0vIzi2JI9s8HaixA+sxZwBs+e+22AS2UylW?= =?us-ascii?q?QNEWxllJtjqFBwnw/QmZNzhOZVQJkKv6tE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FZAADEdzlah2Ka6ERdGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJsI4EVdCcHhAmZLIIClyQUgT5DChgLgV6DOgIahHRAFwEBAQEBAQE?= =?us-ascii?q?BAQECEAEBAQgNCQgoL4I4JAEOSyEGBgEBAQEBASYBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEXAj0BEgEBGAEBAQECAQEBIREMHw0CCAMBBAcEAgEIEQQBAQMCBh0DAgICJQs?= =?us-ascii?q?UAQgIAgQOBQiKGwgBD6hAgieDEYdfAQEBAQEBAQMBAQEBAQEBAQEBARUDBYEPg?= =?us-ascii?q?lsEgTY7IYFXhAaBDoMvAYEyIAUBGIMUMYIykiGRIAYCiRmOKJFgik2LfwIEAgQ?= =?us-ascii?q?FAhqBOyEBggZvUYIpglQQDIFneIk+gRUBAQE?= X-IPAS-Result: =?us-ascii?q?A2FZAADEdzlah2Ka6ERdGgEBAQEBAgEBAQEIAQEBAYJsI4E?= =?us-ascii?q?VdCcHhAmZLIIClyQUgT5DChgLgV6DOgIahHRAFwEBAQEBAQEBAQECEAEBAQgNC?= =?us-ascii?q?QgoL4I4JAEOSyEGBgEBAQEBASYBAQEBAQEBAQEBAQEBAQEBAQEXAj0BEgEBGAE?= =?us-ascii?q?BAQECAQEBIREMHw0CCAMBBAcEAgEIEQQBAQMCBh0DAgICJQsUAQgIAgQOBQiKG?= =?us-ascii?q?wgBD6hAgieDEYdfAQEBAQEBAQMBAQEBAQEBAQEBARUDBYEPglsEgTY7IYFXhAa?= =?us-ascii?q?BDoMvAYEyIAUBGIMUMYIykiGRIAYCiRmOKJFgik2LfwIEAgQFAhqBOyEBggZvU?= =?us-ascii?q?YIpglQQDIFneIk+gRUBAQE?= Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2017 14:38:56 -0600 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Dec 2017 02:38:55 +0600 Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vBJKcrcK002490 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Dec 2017 15:38:55 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com vBJKcrcK002490 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1513715935; bh=s4kDKs0frKNGFL3D8ffRRBK7Y8Y=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=jroOeya1d4JfmzJ2391SeUCXr6J19ymAE5Q71417ht6/4PIyubecMw55dOswbqG+F uBJ4gCo615giq3zceouml25RWpsXpBtb4bWHMEoD2+lfNF8k3dgH4/KVGxcfy8563S 67wtijIrq769EtbHS+iFeTTpB3k7Y4V42vnjqAZ8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com vBJKcrcK002490 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd53.lss.emc.com (RSA Interceptor); Tue, 19 Dec 2017 15:38:16 -0500 Received: from MXHUB306.corp.emc.com (MXHUB306.corp.emc.com [10.146.3.32]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vBJKciQa025306 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Tue, 19 Dec 2017 15:38:44 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB306.corp.emc.com ([10.146.3.32]) with mapi id 14.03.0352.000; Tue, 19 Dec 2017 15:38:43 -0500 To: Tero Kivinen CC: "patient@ietf.org" , "saag@ietf.org" Thread-Topic: [saag] [EXT] Re: [Patient] Internet Draft posted as requested - Thread-Index: AQHTeCdBzbkDHAKlYE678r2VE4IbwqNKz7+AgABLxOA= Date: Tue, 19 Dec 2017 20:38:43 +0000 Message-ID: References: <23096.60715.827133.431108@fireball.acr.fi> In-Reply-To: <23096.60715.827133.431108@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.138] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [saag] [EXT] Re: [Patient] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 20:39:01 -0000 SSBoYXZlIGEgZmV3IHJlYWN0aW9ucyB0byBUZXJvJ3MgbWVzc2FnZSwgd2hpY2ggbWF5IG5vdCBi ZSBjb2hlcmVudCBvciBjb25zaXN0ZW50IHRha2VuIGFzIGEgd2hvbGUuICBJJ3ZlIGV4Y2VycHRl ZCB0aGUgdGV4dCBvZiBpbnRlcmVzdC4gDQoNCj4gSWYgbXkgSW9UIGRldmljZSBjcmFzaGVzIHdo ZW4gc29tZW9uZSBtYWtlcyBzb21lIG5ldyByZW1vdGUgYXR0YWNrIHRvDQo+IGl0LCBJIHdpbGwg Y2hhbmdlIGNvbmZpZ3VyYXRpb24gb2YgbXkgbG9jYWwgInRoaW5nIiBjYWxsZWQgZmlyZXdhbGwN Cj4gYW5kIGJsb2NrIGFsbCBhY2Nlc3MgdG8gSW9UIGRldmljZSwgZXhjZXB0IHRvIHRob3NlIGZl dyBhZGRyZXNzZXMgaXQNCj4gd2lsbCBuZWVkIHRvIGNvbm5lY3QgdG8uDQoNClNvbWUgb2YgdGhl IHBlb3BsZSBvbiB0aGlzIGxpc3QgYXJlIGFtb25nIHRoZSBmcmFjdGlvbiBvZiAxJSBvZiBJbnRl cm5ldCB1c2VycyB3aG8gY2FuIGNvbmZpZ3VyZSBhIGZpcmV3YWxsLg0KDQpIb3dldmVyLCB0aGF0 J3MgcHJvYmFibHkgbW9yZSBvZiBhbiBhcmd1bWVudCBmb3IgSVNQL0lTVi9JSFYgZmlyZXdhbGwg bWFuYWdlbWVudCBhcyBhIHNlY3VyaXR5IHNlcnZpY2UgdGhhdCBtYXkgb3IgbWF5IG5vdCBiZSBi dW5kbGVkIHdpdGggb3RoZXIgc2VydmljZXMgdGhhbiBhbiBhcmd1bWVudCBmb3IgZW5jcnlwdGVk IHRyYWZmaWMgYWNjZXNzLg0KDQo+IElvVCBkZXZpY2VzIHVzdWFsbHkgb25seSByZXF1aXJlIGNv bm5lY3Rpb24gdG8gdGhlIG9uZSBvZiB0d28NCj4gbG9jYXRpb25zLCBpLmUuLCB0aGVpciBvd24g Y2xvdWQgc2VydmljZSwgb3IgdG8gbXkgbG9jYWwgaG9tZSBhcmUgSW9UDQo+IGdhdGV3YXkuIElu IGJvdGggY2FzZXMgcHJvdGVjdGluZyB0aGUgSW9UIGRldmljZSBpcyBiZXN0IGRvbmUgYnkNCj4g bGltaXRpbmcgYWNjZXNzIHRvIGRldmljZSB1c2luZyBub3JtYWwgZmlyZXdhbGwgcnVsZXMuIElu c3RhbGxpbmcNCj4gZmlyZXdhbGwgcnVsZXMgZG9lcyBub3QgcmVxdWlyZSBzZWVpbmcgdGhlIHRy YWZmaWMgaW5zaWRlIHRoZQ0KPiBlbmNyeXB0ZWQgZmxvdy4NCg0KVGhhdCdzIG5vdCBhcyBzaW1w bGUgYXMgb25lIG1pZ2h0IGxpa2UuICAgSSByZWNlbnRseSBoYWQgdG8gcmVxdWVzdCBvcGVuaW5n IHVwIHRoZSBjb3Jwb3JhdGUgZmlyZXdhbGwgdG8gYWxsb3cgYSB3ZWIgY29uZmVyZW5jaW5nIHNl cnZpY2UgKG5hbWUgb2Ygc2VydmljZSBvbWl0dGVkIHRvIHByb3RlY3QgdGhlIGlubm9jZW50IC4u LiBhbmQgdGhlIGd1aWx0eSkuICBUaGF0IHJlcXVlc3QgaW52b2x2ZWQgdHdvIFRDUCBwb3J0cyAo aW4gYWRkaXRpb24gdG8gNDQzKSBwbHVzIGEgbGFyZ2UgVURQIHBvcnQgcmFuZ2UgKGZvciBSVFAp IGFjcm9zcyBzZXZlbiBJUHY0IGFkZHJlc3MgYmxvY2tzIHdob3NlIHNpemUgcmFuZ2VzIGZyb20g LzI2IHRvIC8yMS4gICBUaGF0J3MgcXVpdGUgYSBiaXQgbW9yZSB0aGFuICJ0d28gbG9jYXRpb25z LCIgYW5kIHRoaXMgaXMgc29tZXRoaW5nIHRoYXQgYW4gSW9UIHdlYiBjb25mZXJlbmNpbmcgc3lz dGVtIGNvdWxkIHJlcXVpcmUuDQoNCj4gPiAgU29tZSBwZW9wbGUgaW4gdGhpcyBkaXNjdXNzaW9u IGhhdmUgcHJvcG9zZWQgbmFycm93aW5nIHRoZSBzY29wZSBzbw0KPiA+ICB0aGF0IGVuZHBvaW50 cyBvbmx5IHRydXN0IGEgc2V0IG9mIHdlbGwta25vd24sIG1hbnVhbGx5DQo+ID4gIHByZS1jb25m aWd1cmVkIHNldCBvZiBzdWNoIGFwcGxpYW5jZXMsIGJ1dCBzdGlsbCB0YWNrbGUgY2hhbGxlbmdl cw0KPiA+ICBsaWtlIGVuZDJlbmQgaW50ZWdyaXR5Lg0KPiANCj4gSSB0aGluayBzZXQgb2Ygd2Vs bC1rbm93biBwcmUtY29uZmlndXJlZCBzZXQgb2YgZGV2aWNlIGlzIGdvb2QgaWRlYQ0KPiBmb3Ig bW9zdCBvZiB0aGUgSW9UIGRldmljZXMuIElvVCBkZXZpY2VzIHVzdWFsbHkgZG8gbm90IHdhbnQg dG8gdGFsaw0KPiB0byByYW5kb20gZGV2aWNlcyBpbiB0aGUgaW50ZXJuZXQsIHRoZXkgd2lsbCBu ZWVkIHRvIHRhbGsgdG8gdGhlIGZldw0KPiB0aGluZ3MgcHJlLWNvbmZpZ3VyZWQgdG8gdGhlbS4g QW5kIGZvciB0aGF0IGZpbHRlcmluZyBiYXNpYyBmaXJld2FsbA0KPiBpcyB1c3VhbGx5IGVub3Vn aC4NCj4gDQo+IFRoaXMgZG9lcyBub3Qgd29yayBmb3IgbGFwdG9wcyBvciBzaW1pbGFyLCBidXQg d29ya3MgZm9yIG1vc3Qgb2YgdGhlDQo+IElvVCBkZXZpY2VzLg0KDQpUaGF0IHN1Z2dlc3RzIHNl cGFyYXRpb24gb2YgdGhvc2UgdHdvIGNsYXNzZXMgb2YgdXNlIGNhc2VzIGluIGRpc2N1c3Npb24g YW5kIGRlc2lnbiBhcHBsaWNhYmlsaXR5LiAgVGhlIGFib3ZlIGxpbmUgb2YgcmVhc29uaW5nIGFs c28gYXBwZWFycyB0byBhc3N1bWUgdGhhdCBpdCdzIGFjY2VwdGFibGUgdG8gcHJvaGliaXQgUDJQ IGZ1bmN0aW9uYWxpdHkgKGkuZS4sICJ0YWxrW2luZ10gdG8gcmFuZG9tIGRldmljZXMgaW4gdGhl IEludGVybmV0IikgaW4gSW9UIGRldmljZXMuICBJJ20gbm90IHN1cmUgYWJvdXQgdGhhdC4NCg0K VGhhbmtzLCAtLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog c2FhZyBbbWFpbHRvOnNhYWctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlcm8gS2l2 aW5lbg0KPiBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAxOSwgMjAxNyA1OjQzIEFNDQo+IFRvOiBC cmlhbiBXaXR0ZW4gPGJyaWFuX3dpdHRlbkBzeW1hbnRlYy5jb20+DQo+IENjOiBwYXRpZW50QGll dGYub3JnOyBzYWFnQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc2FhZ10gW0VYVF0gUmU6IFtQ YXRpZW50XSBJbnRlcm5ldCBEcmFmdCBwb3N0ZWQgYXMgcmVxdWVzdGVkIC0NCj4gDQo+IEkgaGF2 ZSBub3QgZm9sbG93ZWQgdGhpcyBkaXNjdXNzaW9uIGluIFNpbmdhcG9yZSBvciBpbiB0aGUgcGF0 aWVudA0KPiBsaXN0LCBzbyBteSBrbm93bGVkZ2UgYWJvdXQgdGhpcyBpcyB3aGF0IGhhcyBiZWVu IHNlbnQgdG8gaGVyZSB0byB0aGUNCj4gc2FhZyBsaXN0LCBzbyBJIGFtIHNvcnJ5IGlmIEkgbWlz dW5kZXJzdG9vZCBzb21ldGhpbmcuDQo+IA0KPiBCcmlhbiBXaXR0ZW4gd3JpdGVzOg0KPiA+IFdo ZXJlIHlvdSBzYXksIOKAnE1pZGRsZWJveGVzIGFyZSBhcyBsaWtlbHkgdG8gaGF2ZSBidWdzLOKA nSB0aGlzIGlzIG9mDQo+ID4gY291cnNlIGNvbXBsZXRlbHkgY29uc2lzdGVudCB3aXRoIG15IGVt cGhhc2lzIGluIFNpbmdhcG9yZSB0aGF0IOKAnGFsbA0KPiA+IHNvZnR3YXJlIGhhcyBidWdzICYg dnVsbmVyYWJpbGl0aWVzLOKAnSBpbmNsdWRpbmcgYm90aCBlbmRwb2ludHMgYW5kDQo+ID4gbmV0 d29yayBhcHBsaWFuY2VzLCB2aXJ0dWFsIGFuZCBwaHlzaWNhbC4NCj4gPg0KPiA+IE9uZSBvZiBt eSBwb2ludHMgdGhhdCB5b3UgbWlnaHTigJl2ZSBtaXNzZWQgaW4gU2luZ2Fwb3JlIHdhcyB0aGF0 DQo+ID4g4oCcd2hlbiBzb21ldGhpbmcgZ29lcyB3cm9uZyzigJ0gc3VjaCBhcyBhIHZ1bG5lcmFi aWxpdHkgYmVpbmcNCj4gPiBleHBsb2l0ZWQsIEnigJlkIG11Y2ggcmF0aGVyIGhhdmUgdGhhdCAi YmxvdyB1cCIgaW4gc29tZSByZW1vdGUgKGFuZA0KPiA+IGVhc2lseSByZXNldCkgbmV0d29yayB0 aGluZyAodmlydHVhbCBhcHBsaWFuY2UsIGNvbnRhaW5lciwgb3INCj4gPiBsYW1iZGEpIHJhdGhl ciB0aGFuIGluIHRoZSBlbmRwb2ludC4NCj4gDQo+IEkgZG8gbm90IGFncmVlIG9uIHRoYXQuIEkg dGhpbmsgaXQgaXMgYmV0dGVyIHRvIGhhdmUgc29tZXRoaW5nIHRvDQo+ICJibG93IHVwIiBpbiBz b21lIGxvY2F0aW9uIHRoYXQgSSBjYW4gYWN0dWFsbHkgZG8gc29tZXRoaW5nIGFib3V0LiBJZg0K PiBteSBsYXB0b3AgYmxvd3MgdXAsIEkgY2FuIHJlYm9vdCBpdCBteXNlbGYgYW5kIGluc3RhbGwg dXBkYXRlcyB0byBpdA0KPiB3aGVuIGl0IGJvb3RzIHVwLiBJZiBzb21lIHJlbW90ZSBjbG91ZCBi YXNlZCBzeXN0ZW0gY3Jhc2hlcywgaXQgd2lsbA0KPiBtb3N0IGxpa2VseSBjcmFzaCBhZ2FpbiB3 aGVuIEkgdHJ5IHRvIGRvIHNhbWUgdGhpbmcgYWdhaW4sIGFuZCBJIGhhdmUNCj4gbm8gY29udHJv bCBvbiB1cGRhdGluZyB0aGUgc29mdHdhcmUgaW4gdGhlcmUuDQo+IA0KPiBJZiBteSBJb1QgZGV2 aWNlIGNyYXNoZXMgd2hlbiBzb21lb25lIG1ha2VzIHNvbWUgbmV3IHJlbW90ZSBhdHRhY2sgdG8N Cj4gaXQsIEkgd2lsbCBjaGFuZ2UgY29uZmlndXJhdGlvbiBvZiBteSBsb2NhbCAidGhpbmciIGNh bGxlZCBmaXJld2FsbA0KPiBhbmQgYmxvY2sgYWxsIGFjY2VzcyB0byBJb1QgZGV2aWNlLCBleGNl cHQgdG8gdGhvc2UgZmV3IGFkZHJlc3NlcyBpdA0KPiB3aWxsIG5lZWQgdG8gY29ubmVjdCB0by4N Cj4gDQo+IElvVCBkZXZpY2VzIHVzdWFsbHkgb25seSByZXF1aXJlIGNvbm5lY3Rpb24gdG8gdGhl IG9uZSBvZiB0d28NCj4gbG9jYXRpb25zLCBpLmUuLCB0aGVpciBvd24gY2xvdWQgc2VydmljZSwg b3IgdG8gbXkgbG9jYWwgaG9tZSBhcmUgSW9UDQo+IGdhdGV3YXkuIEluIGJvdGggY2FzZXMgcHJv dGVjdGluZyB0aGUgSW9UIGRldmljZSBpcyBiZXN0IGRvbmUgYnkNCj4gbGltaXRpbmcgYWNjZXNz IHRvIGRldmljZSB1c2luZyBub3JtYWwgZmlyZXdhbGwgcnVsZXMuIEluc3RhbGxpbmcNCj4gZmly ZXdhbGwgcnVsZXMgZG9lcyBub3QgcmVxdWlyZSBzZWVpbmcgdGhlIHRyYWZmaWMgaW5zaWRlIHRo ZQ0KPiBlbmNyeXB0ZWQgZmxvdy4NCj4gDQo+IEkgbWlnaHQgYWxzbyB3YW50IHRvIGFkZCBydWxl IHRvIHNheSB0aGF0IHRoZSBJb1QgZGV2aWNlIGlzIG9ubHkNCj4gYWxsb3dlZCB0byB0YWxrIHRv IHRoZSBnaXZlbiBJUCBhZGRyZXNzIHVzaW5nIHNvbWUgc3BlY2lmaWMNCj4gY2VydGlmaWNhdGUg KGkuZS4sIHBlcmhhcHMgaW1wbGVtZW50IGNlcnRpZmljYXRlIHBpbm5pbmcgb24gdGhlDQo+IGZp cmV3YWxsKSwgb3IgZXZlbiBtYWtlIHNlcGFyYXRlIFRMUyBzZXNzaW9uIGZyb20gdGhlIGZpcmV3 YWxsIHRvIHRoZQ0KPiB2ZW5kb3JzIGNsb3VkIGFuZCBydW4gdGxzIGluc2lkZSB0bHMgdG8gcHJv dGVjdCB0aGUgSW9UIGRldmljZS4NCj4gDQo+ID4gV2h5PyBOZXR3b3JrIOKAnHRoaW5nc+KAnSBj YW4gYmUgZGVkaWNhdGVkIHRvIGZsb3dzIHRoYXQgYXJlIHNwZWNpZmljIHRvDQo+ID4gYSByZW1v dGUgZW5kcG9pbnQsIGxpa2UgYSBjbGllbnQgcnVubmluZyBhIHNldCBvZiBwcm94aWVzIGluIGEg Y2xvdWQNCj4gPiBiYXNlZCBpbmZyYXN0cnVjdHVyZSB0aGF0IHRoZXkgYW5kIG1pbGxpb25zIG9m IG90aGVycyB0cnVzdCwgd2l0aA0KPiA+IGVhY2ggc29mdHdhcmUgaW5zdGFuY2Ugb2YgdGhlIHBy b3h5IGRlZGljYXRlZCB0byBtZWRpYXRpbmcNCj4gPiBjb21tdW5pY2F0aW9uIHdpdGggYSBkaWZm ZXJlbnQgc2VydmVyLg0KPiA+DQo+ID4gSW4gdGhpcyBjb250ZXh0LCBpZiB0aGUgc2VydmVyIGhh Y2tzIHRoZSBtaWRkbGVib3gsIGl0IG9ubHkgaGVhcnMNCj4gPiBpdOKAmXMgb3duIGNvbnZlcnNh dGlvbiB3aXRoIHRoZSBjbGllbnQuDQo+ID4NCj4gPiBJbiBjb250cmFzdCwgaWYgdGhlIHNlcnZl ciBtYW5hZ2VzIHRvIGhhY2sgYSBjbGllbnQsIGl0DQo+ID4gY2FuIGhlYXIgYWxsIHRoYXQgY2xp ZW50IGlzIGRvaW5nLCBpbmNsdWRpbmcgdG9kYXkgbG90cyBvZiBsb2NhdGlvbg0KPiA+IGJhc2Vk IGluZm9ybWF0aW9uLCBhcyB3ZWxsIGFzIHNlZWluZyBzdGF0ZSBhY2N1bXVsYXRlZCBmcm9tIHBh c3QNCj4gPiBjb252ZXJzYXRpb25zIHdpdGggb3RoZXIgc2VydmVycy4NCj4gDQo+IE15IGxvY2Fs IGVuZHBvaW50IGNhbiBzaW1pbGFybHkgYmUgZGVkaWNhdGVkIHRvIHRoZSBmbG93cywgaS5lLiwg SSBjYW4NCj4gcnVuIHNlcGFyYXRlIGhhcmR3YXJlIHByb3RlY3RlZCBhZGRyZXNzIHNwYWNlIGZv ciBldmVyeSBzaW5nbGUgd2ViDQo+IHBhZ2UgSSBhbSB2aWV3aW5nIChJLmUuLCBzdGFydCBzZXBh cmF0ZSB1bml4IHByb2Nlc3MgZm9yIGVhY2ggd2ViDQo+IHBhZ2UpLiBJIHRoaW5rIHNvbWUgYnJv d3NlcnMgbWlnaHQgYWN0dWFsbHkgZG8gdGhhdCwgYXMgaXQgYWxzbyBtZWFucw0KPiB0aGF0IGlm IHRoYXQgcHJvY2VzcyBkaWVzLCB5b3Ugb25seSBsb29zZSBvbmUgdGFiIG5vdCB0aGUgd2hvbGUN Cj4gYnJvd3Nlci4uLg0KPiANCj4gVGhlbiB5b3Ugc2F5IHRoYXQgdGhlcmUgY2FuIGJlIGF0dGFj a3Mgd2hpY2ggYnJlYWtzIG91dCBmcm9tIHRoZSBqYWlsDQo+IGFuZCBtYW5hZ2VzIHRvIGF0dGFj ayBteSB3aG9sZSBvcGVyYXRpbmcgc3lzdGVtLCBidXQgc2FtZSBpcyBwb3NzaWJsZQ0KPiBhbHNv IHdpdGggdGhlIG5ldHdvcmsgInRoaW5nIi4gSS5lLiwgd29yc3QgY2FzZSBpcyB0aGF0IHNvbWVv bmUNCj4gbWFuYWdlcyB0byBtYWtlIGF0dGFjayB0aGF0IHdpbGwgYnJlYWsgb3V0IGZyb20gdGhl IGNsb3VkIGJhc2VkDQo+IG5ldHdvcmsgdGhpbmcgYW5kIG1hbmFnZXMgdG8gZ2FpbiBhY2Nlc3Mg dGhlIGFjdHVhbCBvcGVyYXRpbmcgc3lzdGVtDQo+IGFuZCB0aGVuIHRvIHBlcmhhcHMgZXZlbiB0 aGUgdmlydHVhbGl6YXRpb24gc3lzdGVtIGFsc28uIE5vdGUsIHRoYXQgaW4NCj4gdGhpcyBjYXNl IHRoZSBhdHRhY2tlciBtaWdodCBiZSBib3RoIHRoZSBzZXJ2ZXIgYW5kIGNsaWVudCB1c2luZyB0 aGUNCj4gInRoaW5nIi4gaS5lLiwgYXR0YWNrZXIgY2FuIHVzZSB0aGUgc2VydmVyIGl0IGNvbnRy b2xzIHdpdGggdGhlIGNsaWVudA0KPiBpdCBjb250cm9sIHRvIGF0dGFjayB0aGUgY2xvdWxkIGJh c2VkIG5ldHdvcmsgInRoaW5nIiB0aGF0IG1pbGxpb25zIG9mDQo+IHBlb3BsZSBhcmUgdHJ1c3Rp bmcsIGFuZCBnYWluIGFjY2VzcyB0byBldmVyeXRoaW5nIHRoYXQgZ29lcyB0aHJvdWdoDQo+IHRo YXQgY2xvdWQgYmFzZWQgc3lzdGVtLiBUaGlzIGtpbmQgb2YgYXR0YWNrIGlzIG11Y2ggd29yc2Ug dGhhbg0KPiBnZXR0aW5nIGFjY2VzcyB0byBhbGwgdHJhZmZpYyBvbmUgdXNlciBpcyBzZW5kaW5n IC8gcmVjZWl2aW5nLg0KPiANCj4gVGhlcmUgaXMgbm8gZGlmZmVyZW5jZSB3aGF0IGtpbmQgb2Yg cHJvdGVjdGlvbnMgY2FuIGJlIGRvbmUgb24gdGhlDQo+ICJ0aGluZ3MiIGluIG5ldHdvcmsgb3Ig aW4gdGhlIGxvY2FsIGVuZCBwb2ludC4gQm90aCBjYW4gYmUgd3JpdHRlbg0KPiB1c2luZyBzZWN1 cmUgbWV0aG9kcywgb3IgdGhleSBjYW4gYmUgd3JpdHRlbiBpbiBub3Qgc28gc2FmZSB3YXlzIGFu ZA0KPiBjb250YWluIGh1Z2Ugc2VjdXJpdHkgdnVsbmVyYWJpdGlsaWVzLg0KPiANCj4gVXBkYXRp bmcgdGhlIGxvY2FsIGVuZHBvaW50IG1pZ2h0IGJlIGZhc3RlciBvciBzbG93ZXIgdGhhbiB1cGRh dGluZw0KPiB0aGUgbmV0d29yayAidGhpbmciLiBMYXRlc3Qgb3BlcmF0aW5nIHN5c3RlbXMgd2ls bCBhdXRvbWF0aWNhbGx5DQo+IGluc3RhbGwgY3JpdGljYWwgc2VjdXJpdHkgdXBkYXRlcywgYnJv d3NlcnMgYWxyZWFkeSBlaXRoZXIgaW5zdGFsbA0KPiB1cGRhdGVzIGF1dG9tYXRpY2FsbHkgb3Ig aW5mb3JtIHlvdSBhYm91dCBuZXcgdXBkYXRlcyBpbW1lZGlhdGVseSB3aGVuDQo+IHRoZXkgYXJl IGF2YWlsYWJsZS4NCj4gDQo+IFRoZSBwcm9ibGVtIHdpdGggcGFydGlhbGx5IGludmlzaWJsZSAi dGhpbmdzIiBpcyB0aGF0IGZvciBlbmQgdXNlciBkbw0KPiBub3QgaGF2ZSBnb29kIHZpc2liaWxp dHkgdG8gdGhlbSwgYW5kIGVuZCB1c2VyIG1pZ2h0IG5vdCBldmVuIGJlIGFibGUNCj4gdG8gdXBk YXRlIGl0LCBidXQgbXVzdCB3YWl0IGZvciB0aGUgdmVuZG9yIHRvIHB1dCBvdXQgdXBkYXRlLg0K PiANCj4gPiBTbywgSeKAmWxsIHN0YW5kIGJ5IG15IHR3byBhc3NlcnRpb25zOiDigJxBbGwgc29m dHdhcmUgaGFzDQo+ID4gdnVsbmVyYWJpbGl0aWVzLOKAnSBhbmQg4oCcV2hlbiB0aGluZ3MgZ28g d3JvbmcsIEnigJlkIHJhdGhlciBoYXZlIHRoZW0gZ28NCj4gPiB3cm9uZyBpbiBhbiBlYXNpbHkg cmVzZXQgbmV0d29yayB0aGluZywgbXVjaCByYXRoZXIgdGhhbiBoYXZpbmcNCj4gPiB0aGluZ3Mg Z28gd3JvbmcgaW4gdGhlIGVuZHBvaW50LuKAnQ0KPiANCj4gSSByYXRoZXIgaGF2ZSB0aGluZ3Mg Z28gd3JvbmcgaW4gbG9jYXRpb24gd2hpY2ggSSBjb250cm9sLCBhbmQgd2hpY2ggSQ0KPiBjYW4g dXBkYXRlIHNvIGFmdGVyIHRoZSB1cGRhdGUgZXZlcnl0aGluZyB3b3Jrcy4gSSBkbyBub3QgbGlr ZSB0byB3YWl0DQo+IGZvciBkYXlzIG9yIHdlZWtzIChvciBtb250aHMveWVhcnMpIHRvIGdldCB2 ZW5kb3IgaW5zdGFsbCB1cGRhdGUuDQo+IA0KPiBNeSBsYXB0b3AgdmVuZG9yIGhhcyBub3QgeWV0 IHB1Ymxpc2hlZCB1cGRhdGVzIGZvciB0aGUgSW50ZWwgTUUNCj4gZmlybXdhcmUgYnVncy4uLi4N Cj4gDQo+ID4gQmFjayB0byB0aGUgdGhvdWdodCB0aGF0IOKAnGFsbCBzb2Z0d2FyZSBoYXMgdnVs bmVyYWJpbGl0aWVzLOKAnSB0YWtpbmcNCj4gPiB0aGUgZGlzY3Vzc2lvbiBmdXJ0aGVyLCBpbiBm YWN0LCBqdXN0IGFzIHNvbWUgZW5kcG9pbnRzIGhhdmUgbW9yZQ0KPiA+IHZ1bG5lcmFiaWxpdGll cyB0aGFuIG90aGVycywgc29tZSBuZXR3b3JrIGFwcGxpYW5jZXMgaGF2ZSBtb3JlDQo+ID4gdnVs bmVyYWJpbGl0aWVzIHRoYW4gb3RoZXJzLiBUaGF04oCZcyBvZiBjb3Vyc2UgYW1vbmcgdGhlIHJl YXNvbnMgSQ0KPiA+IGJlbGlldmUgaXTigJlzIGdvb2QgZm9yIGVuZHBvaW50cyB0byBrbm93IGFz IG11Y2ggYXMgcG9zc2libGUgYWJvdXQNCj4gPiB0aGUgbmV0d29yayBhcHBsaWFuY2VzIHdoaWNo IHRoZXkgYXJlIGNvbnNpZGVyaW5nIHRydXN0aW5nIHdpdGgNCj4gPiBjbGVhcnRleHQuDQo+IA0K PiBVc3VhbGx5IGFsc28gdGhlIGZld2VyIGZlYXR1cmVzIHRoZSBzb2Z0d2FyZSBoYXMsIHRoZSBm ZXdlcg0KPiB2dWxuZXJhYmlsaXRpZXMgaXQgYWxzbyBoYXMuIEJhc2ljIGZpcmV3YWxsIGRvaW5n IGJsb2NraW5nIGJhc2VkIG9uDQo+IHRoZSBUQ1AgZmxvd3MgYW5kIElQL3BvcnQgbnVtYmVycyBp cyBtdWNoIHNpbXBsaWVyIHRoYW4gZnVsbCBzdGFjaw0KPiBhcHBsaWNhdGlvbiBnYXRld2F5IGFj dGluZyBhcyBtYW4gaW4gdGhlIG1pZGRsZSBvZiBteSBlbmNyeXB0ZWQNCj4gY29tbXVuaWNhdGlv bnMuIEkgd291bGQgdHJ1c3QgbXVjaCBtb3JlIHdpdGggdGhlIGJhc2ljIGZpcmV3YWxsDQo+ICJ0 aGluZyIgdGhhbiBtdWNoIG1vcmUgY29tcGljYXRlZCBjbG91ZCBiYXNlZCBuZXR3b3JrICJ0aGlu ZyIuDQo+IA0KPiA+ICBTb21lIHBlb3BsZSBpbiB0aGlzIGRpc2N1c3Npb24gaGF2ZSBwcm9wb3Nl ZCBuYXJyb3dpbmcgdGhlIHNjb3BlIHNvDQo+ID4gIHRoYXQgZW5kcG9pbnRzIG9ubHkgdHJ1c3Qg YSBzZXQgb2Ygd2VsbC1rbm93biwgbWFudWFsbHkNCj4gPiAgcHJlLWNvbmZpZ3VyZWQgc2V0IG9m IHN1Y2ggYXBwbGlhbmNlcywgYnV0IHN0aWxsIHRhY2tsZSBjaGFsbGVuZ2VzDQo+ID4gIGxpa2Ug ZW5kMmVuZCBpbnRlZ3JpdHkuDQo+IA0KPiBJIHRoaW5rIHNldCBvZiB3ZWxsLWtub3duIHByZS1j b25maWd1cmVkIHNldCBvZiBkZXZpY2UgaXMgZ29vZCBpZGVhDQo+IGZvciBtb3N0IG9mIHRoZSBJ b1QgZGV2aWNlcy4gSW9UIGRldmljZXMgdXN1YWxseSBkbyBub3Qgd2FudCB0byB0YWxrDQo+IHRv IHJhbmRvbSBkZXZpY2VzIGluIHRoZSBpbnRlcm5ldCwgdGhleSB3aWxsIG5lZWQgdG8gdGFsayB0 byB0aGUgZmV3DQo+IHRoaW5ncyBwcmUtY29uZmlndXJlZCB0byB0aGVtLiBBbmQgZm9yIHRoYXQg ZmlsdGVyaW5nIGJhc2ljIGZpcmV3YWxsDQo+IGlzIHVzdWFsbHkgZW5vdWdoLg0KPiANCj4gVGhp cyBkb2VzIG5vdCB3b3JrIGZvciBsYXB0b3BzIG9yIHNpbWlsYXIsIGJ1dCB3b3JrcyBmb3IgbW9z dCBvZiB0aGUNCj4gSW9UIGRldmljZXMuDQo+IA0KPiA+IFBvd2VyIHVzZXJzIG1pZ2h0IGNob29z ZSB0byBydW4gdGhlaXIgb3duIHByb3RlY3Rpb24gaW4gdGhlaXIgb3duDQo+ID4gY2xvdWQgYmFz ZWQgaW5mcmFzdHJ1Y3R1cmUsIGJ1dCB0aGF04oCZcyBub3QgYSByYW5kb20gcGVyc29uLg0KPiA+ DQo+ID4gTWFueSBwZW9wbGUgY2hvb3NlIHRvIGhhdmUgc29tZW9uZSBvciBzb21ldGhpbmcgaGVs cCBwcm90ZWN0IHRoZW0uDQo+ID4NCj4gPiBNYW55IGVtcGxveWVlcyBjaG9vc2UgdG8gbGV0IHRo ZWlyIGVtcGxveWVyIGhlbHAgcHJvdGVjdCB0aGVtLg0KPiANCj4gVXN1YWxseSBlbXBsb3llZXMg ZG8gbm90IGhhdmUgY2hvaWNlLCB0aGUgZW1wbG95ZXIgd2lsbCBjaG9vc2UgdG8NCj4gImhlbHAg cHJvdGVjdCIgdGhlbSBhbmQgZW1wbG95ZWUgY2Fubm90IG9wdC1vdXQuLi4NCj4gDQo+ID4gTWFu eSBwZW9wbGUgb2Z0ZW4gY2hvb3NlIHRvIGhhdmUgc2VjdXJpdHkgY29tcGFuaWVzIGhlbHAgcHJv dGVjdA0KPiA+IHRoZW0uDQo+IA0KPiBBbmQgcXVpdGUgb2Z0ZW4gcGVvcGxlIGRvIG5vdCBjaG9v c2UgdGhhdCBlaXRoZXIsIGl0IGlzIGNob3NlbiBmb3INCj4gdGhlbSBieSB0aGVpciBsYXB0b3Ag dmVuZG9yIHByZS1pbnN0YWxsaW5nIGFsbCBraW5kIG9mIGp1bmsgb24gdGhlaXINCj4gbmV3IGxh cHRvcCB3aGljaCBpcyBhbG1vc3QgaW1wb3NzaWJsZSB0byBnZXQgcmlkIG9mLi4uDQo+IA0KPiA+ IFNvbWUgcGVvcGxlIGNob29zZSB0byBoYXZlIG5ldHdvcmsgcHJvdmlkZXJzIGhlbHAgcHJvdGVj dCB0aGVtLg0KPiANCj4gQWdhaW4gcXVpdGUgb2Z0ZW4gdGhlcmUgaXMgbm8gb3B0LWluIGluIHRo YXQsIHRoZSBJU1Agd2lsbCAicHJvdGVjdCINCj4gaXRzIHVzZXJzIHJlZ2FyZGxlc3Mgd2hldGhl ciB0aGV5IHdhbnQgb3Igbm90Lg0KPiANCj4gPiBJIGJlbGlldmUgcGVvcGxlIGhhdmUgYSByaWdo dCB0byBjaG9vc2Ugd2hvIHByb3RlY3RzIGZyb20gdGhlbSBmcm9tDQo+ID4gcG90ZW50aWFsbHkg bWFsaWNpb3VzIHNlcnZlcnMuDQo+IA0KPiBZZXMsIHRoZXkgc2hvdWxkIGhhdmUgcmlnaHQgdG8g Y2hvb3NlLCBidXQgaW4gbW9zdCBjYXNlcyB0aGV5IGRvIG5vdC4NCj4gVGhlIHByb3RlY3Rpb24g aXMgZG9uZSBpbiBhIHdheSB0aGV5IGNhbm5vdCBjaG9vc2Ugbm90IHRvIGRvIGl0IG9yDQo+IGV2 ZW4gd2hvIGRvZXMgaXQuIEFsbCB0aGlzIGlzIGRvbmUgdG8gcHJvdGVjdCB0aGUgIm5vcm1hbCIg dXNlciwgc28NCj4gIm5vcm1hbCIgdXNlciBjYW5ub3QgZGlzYWJsZSBzZWN1cml0eSAic29mdHdh cmUvdGhpbmciIGluc3RhbGxlZCBvbg0KPiBwYXRoIGJ5IGxhcHRvcCB2ZW5kb3IgLyBlbXBsb3ll ciAvIElTUCBldGMuLi4NCj4gDQo+ID4gIEkgYmVsaWV2ZSBwZW9wbGUgaGF2ZSBhIHJpZ2h0IHRv IGNob29zZSBwcm90ZWN0aW9uIGZyb20gc29tZW9uZQ0KPiA+ICBvdGhlciB0aGFuIHRoZSBlbmRw b2ludCBtYWtlciBhbmQgc29tZW9uZSBvdGhlciB0aGFuIHRoZSByZW1vdGUNCj4gPiAgc2VydmVy Lg0KPiANCj4gUGVyaGFwcy4gSSB0aGluayB0aGUgbG9naWNhbCB3YXkgb2YgZG9pbmcgdGhhdCBp cyB0byBpbnN0YWxsIHNvZnR3YXJlDQo+IChhZ2FudCkgb24gdGhlaXIgZW5kcG9pbnQgdGhleSB3 YW50IHRvIHByb3RlY3QgYW5kIHVzZSB0aGF0IHRvIGRvIHRoZQ0KPiBvcHQtaW4uLi4NCj4gLS0N Cj4ga2l2aW5lbkBpa2kuZmkNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IHNhYWcgbWFpbGluZyBsaXN0DQo+IHNhYWdAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFnDQo= From nobody Tue Dec 19 13:07:29 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117AA1270A0; Tue, 19 Dec 2017 13:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 ds5XgwQfeTTP; Tue, 19 Dec 2017 13:07:22 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 C8AB9124239; Tue, 19 Dec 2017 13:07:21 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id vBJL75vc026599 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Dec 2017 23:07:09 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id vBJL6xpf014208; Tue, 19 Dec 2017 23:06:59 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23097.32627.710293.414741@fireball.acr.fi> Date: Tue, 19 Dec 2017 23:06:59 +0200 From: Tero Kivinen To: "Black\, David" Cc: "patient\@ietf.org" , "saag\@ietf.org" In-Reply-To: References: <23096.60715.827133.431108@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 20 min X-Total-Time: 20 min Archived-At: Subject: Re: [saag] [EXT] Re: [Patient] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 21:07:24 -0000 Black, David writes: > Some of the people on this list are among the fraction of 1% of > Internet users who can configure a firewall. True. On the other hand most of the network access devices (ADSL modems, LTE modems etc) already have firewall built in and the default configuration quite commonly is, outbound traffic allowed, inbound traffic forbidden. This already protects quite a lot of devices... On the other hand as that configuration is so common, lots of IoT devices have "call home" protocol, i.e., they will periodically connect to some home server and ask if there is anything they need to do, and this allows attack vector for attacking those devices. > However, that's probably more of an argument for ISP/ISV/IHV > firewall management as a security service that may or may not be > bundled with other services than an argument for encrypted traffic > access. Yep. Offloading firewall configuration to security service vendor makes lots of sense, as they can then change configuration quickly when some kind of new attack is found out. > That's not as simple as one might like. I recently had to request > opening up the corporate firewall to allow a web conferencing > service (name of service omitted to protect the innocent ... and the > guilty). That request involved two TCP ports (in addition to 443) > plus a large UDP port range (for RTP) across seven IPv4 address > blocks whose size ranges from /26 to /21. That's quite a bit more > than "two locations," and this is something that an IoT web > conferencing system could require. What, no /48 networks? Bad, bad system, you should require proper software that actually works on the internet instead of those old legacy systems :-) > That suggests separation of those two classes of use cases in > discussion and design applicability. The above line of reasoning > also appears to assume that it's acceptable to prohibit P2P > functionality (i.e., "talk[ing] to random devices in the Internet") > in IoT devices. I'm not sure about that. Yes. They are different use cases. But even then there is multiple different use cases in the IoT too. IoT is quite often used to mean devices that do machine to machine communications, i.e., where there is no user or user interface on the device. I.e., the thermostat sending temperature, or fetching the configuration from the cloud or local server. For those devices connecting random IP-address in the world is not usually needed. They only communicate with the machines they are configured to communicate with and thats it. These devices have also long lifetime, i.e., they might be installed once and assumed to work for next decade or two. For those devices there might also be long term support for them, including firmware updates. Another class of IoT, is the cheap devices connected to the internet doing something. Those devices can include toys, webcams etc. Those devices might actually want to do peer to peer or similar systems as they might want to create network of other people using same devices etc. Protecting them is going to very difficult as their behavior can be very random or unpredictable, thus making rules for them in firewall etc can be hard. Also those are quite often throw-away devices, meaning that if they are broken, they are thrown away, and there is no point of repairing them. Updating the firmware can be considered as repairing it, thus vendors might even not make them so they can be updated, if something goes wrong they just say throw it away and buy new one... -- kivinen@iki.fi From nobody Tue Dec 19 14:56:36 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323DB12D878; Tue, 19 Dec 2017 14:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 7mJkeZjePQ3M; Tue, 19 Dec 2017 14:56:28 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4653612D86E; Tue, 19 Dec 2017 14:56:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 91D28BE4C; Tue, 19 Dec 2017 22:56:25 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyGVEZGMyeor; Tue, 19 Dec 2017 22:56:23 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4DBE6BE2F; Tue, 19 Dec 2017 22:56:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1513724183; bh=ZVksAc/jyUoyPb+no27+GIDfcZDY8/6kAaJfkZvv1Tw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=4JUb4HkttD6yAJMNd6HY0SR37k/stknc74hcMGmDi4vpRqKHz567nX7X8LjoGBx+K DRUZtY14t0LJUkvYNjcBRgFdL+DGhDnVUAlzjbA0BDk/pl86RPqQ8ZkOyxc+NmHQj0 jYmLtukmrI2zQbmSrIE5Fm5djbs6OdufM3pDef3Q= To: Brian Witten , "Diego R. Lopez" , "patient@ietf.org" , "saag@ietf.org" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5d0b7ed5-7bef-2c09-6d89-4d841f230b9c@cs.tcd.ie> Date: Tue, 19 Dec 2017 22:56:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gA9zsIkRqIHsylvHrsmPCkz2Cy1EaV1yI" Archived-At: Subject: Re: [saag] [EXT] Re: [Patient] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 22:56:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gA9zsIkRqIHsylvHrsmPCkz2Cy1EaV1yI Content-Type: multipart/mixed; boundary="RLS9gr7XqCC6vfUE9mJrdmPESqNvw0CGA"; protected-headers="v1" From: Stephen Farrell To: Brian Witten , "Diego R. Lopez" , "patient@ietf.org" , "saag@ietf.org" Message-ID: <5d0b7ed5-7bef-2c09-6d89-4d841f230b9c@cs.tcd.ie> Subject: Re: [EXT] Re: [Patient] [saag] Internet Draft posted as requested - References: In-Reply-To: --RLS9gr7XqCC6vfUE9mJrdmPESqNvw0CGA Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable I think Tero's answers to many of the points raised here are good ones. Some additional points below... On 18/12/17 17:39, Brian Witten wrote: > In this context, if the > server hacks the middlebox, it only hears it=E2=80=99s own conversation= with > the client.=20 I don't think Tero sufficiently refuted that. It's nonsense. When a web site is breached, pretty much all database records accessible to the breached box are considered to have been at risk. The same is true of middleboxes, whatever that middlebox could have seen in the relevant timeframe needs to be considered at risk. The concept of a server attacking a single endpoint's traffic via a middlebox is not even vaguely realistic as a way to think about the risks of middlebox vs. endpoint vulns. > Either scope would be better than trying to pretend that network > appliances aren=E2=80=99t needed for security,=20 Sorry - you already said that "needed" isn't correct. Why do you now go back on that? Do we have to correct every single mail you send? > Re Diego=E2=80=99s points I agree with him completely on all the points= he > mentioned yesterday, including changing the phrasing of point (3) to > =E2=80=9Cmay require.=E2=80=9D =20 And yet just above you accuse others on the basis that they say these things aren't needed? Please try be consistent. Also - "may require" is just silly. There's no reason why middlebox security services are needed, so they are optional. > Re =E2=80=9Crandom person can sensibly decide 269 times,=E2=80=9D um, n= o. =20 Um yes. You specifically said this was about giving users more control and visibility. If you're going to say such things you ought expect to be called out for doing that. > Many employees choose to let their employer help > protect them.=20 That's just funny. In 30 years in this business over a range of companies and academic engagements, I have never heard anyone say that they chose to let their IT dept do anything like that. > I believe people have > a right to choose protection from someone other than the endpoint > maker and someone other than the remote server. Maybe we differ on > this. You'd be better off just admitting that you want to sell product and services TBH. Miscasting that as some kind of effort aimed at better user control and visibility is just not credible. > Re shutting down the dedicated list for this discussion, we all > recognize that has been your desire from the start.=20 I didn't know you could speak for everyone. Thanks for clearing that up;-) As I said before, if this had actually been about a new multi-party security protocol as stated in the list description then I'd have been fine with that. But it is not about that, it's about yet another mitm https and/or tls effort. That was my conclusion from ietf-100. Feel free to try convince folks otherwise. > In contrast, > some of us see value in the discussion. Where you concluded PATIENT > was started for only watching what people do on the web, and not > helping protect IOT =E2=80=9Cthings,=E2=80=9D that view is of course su= rprising to me > as one of my earlier notes highlighted =E2=80=9Cparticulary for =E2=80=A6= IOT > devices,=E2=80=9D and I continue emphasizing =E2=80=9Cincreasingly clos= ed=E2=80=9D endpoints > including both mobile & IOT. Of course, like TLS, PATIENT would be > most valuable well-covering a broad range of settings, including Web, > Mobile Apps, and IOT. The so-called IoT argument here isn't convincing at all. You have classes of device that'll never do tls (e.g. lpwan stuff as described in [1]) for layer 1/2 reasons, there are cases where something needs to poll the device, there are cases where the applications need to deal in vendor-independent messages and various others all of which mean that there are many points where you can try sell your security services without impacting on encryption at all. [1] https://tools.ietf.org/html/draft-ietf-lpwan-overview In addition, devices need to be secured against local attack, whether that's a drone outside the office window taking over the lights [2], or because the device is more capable and runs lighttpd or similar. So you cannot get away from endpoint security actually being necessary on the devices. [2] https://www.pcmag.com/news/349323/philips-smart-lights-hacked-using-a-dro= ne And of course, your putative mitm-modified https or tls is going to be more complex than https or tls and those are already too complex for many small device developers. So no, your so-called IoT argument doesn't stack up at all. >=20 > I=E2=80=99m hoping > that you are willing to grow past your (actually quite famous) a > priori biases on this topic. =20 That's rubbish. My position here reflects conclusions having thought about these issues for years. A-prori bias my arse. > Re, =E2=80=9Cmagical thinking =E2=80=A6 new lies =E2=80=A6 and > =E2=80=A6snow job,=E2=80=9D I find your choice of such words simply ins= ulting and not > constructive, but I=E2=80=99m willing to look past that here. Good, you'll need that if you keep making such bad arguments. I think the IETF should be a welcoming place for newcomers and a cold and hard place for terrible ideas. I have no problem myself in balancing those two things, esp when a terrible idea is presented in a wildly inept manner. S. --RLS9gr7XqCC6vfUE9mJrdmPESqNvw0CGA-- --gA9zsIkRqIHsylvHrsmPCkz2Cy1EaV1yI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaOZkWAAoJEC88hzaAX42iP2MH/3XI+19qDofW6oN7hViIz7/W WaqqrR3mR7EqeN/y9G0ihz61tlWcR9yrHG6rAWTEZSsL6pfyOAB+1cLisBWs8/++ Xm5frUgSYKQCxkSWAq0udlC85LbIBp1jQuS04VH6gnN3iXUdJHLF5ZsaY4OIduIj 64Xu+0gEQMPP4xAi6ZfR0h9KN8qEpoliOuv5pat1Vc+cvgcGye9fkcIHjPiwPKcs 0NKy0M+oT2qDurPQiO2oOKKhLnQFXWa0P7atmtWWr0XlETkM2KJpHe+gHE4GjmVX puhdMB3rn9MtQbqMjuBvWqSNfm5e36xDXvXDMQc33QOE44nN7kvRA3rDVBqfg54= =deZK -----END PGP SIGNATURE----- --gA9zsIkRqIHsylvHrsmPCkz2Cy1EaV1yI-- From nobody Tue Dec 19 17:21:35 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D40D126C89; Tue, 19 Dec 2017 17:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MEiL13cqtrEG; Tue, 19 Dec 2017 17:21:31 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F057D1205F1; Tue, 19 Dec 2017 17:21:30 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2650D2008D; Tue, 19 Dec 2017 20:25:10 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 33C3881AFF; Tue, 19 Dec 2017 20:21:29 -0500 (EST) From: Michael Richardson To: "Black\, David" cc: Tero Kivinen , "patient\@ietf.org" , "saag\@ietf.org" In-Reply-To: References: <23096.60715.827133.4311 08@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] [EXT] Re: [Patient] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 01:21:33 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Black, David wrote: > I have a few reactions to Tero's message, which may not be coherent or > consistent taken as a whole. I've excerpted the text of interest.=20= =20 >> If my IoT device crashes when someone makes some new remote attack to >> it, I will change configuration of my local "thing" called firewall >> and block all access to IoT device, except to those few addresses it >> will need to connect to. > Some of the people on this list are among the fraction of 1% of > Internet users who can configure a firewall. But, MUD will let us automate it this configuration. > However, that's probably more of an argument for ISP/ISV/IHV firewall > management as a security service that may or may not be bundled with > other services than an argument for encrypted traffic access. Agreed. We don't need to see the traffic to authorize it. If we had some better home-router/desktop/phone integration, end users could get requests and might authorize things sensibly. Or not, but at least, th= ey would realize what's going on. Again, MUD. >> IoT devices usually only require connection to the one of two >> locations, i.e., their own cloud service, or to my local home are IoT >> gateway. In both cases protecting the IoT device is best done by >> limiting access to device using normal firewall rules. Installing >> firewall rules does not require seeing the traffic inside the >> encrypted flow. > That's not as simple as one might like. I recently had to request > opening up the corporate firewall to allow a web conferencing service > (name of service omitted to protect the innocent ... and the guilty). > That request involved two TCP ports (in addition to 443) plus a large > UDP port range (for RTP) across seven IPv4 address blocks whose size > ranges from /26 to /21. That's quite a bit more than "two locations= ," > and this is something that an IoT web conferencing system could > require. It would be interesting if applications could emit a cooked (JSON or maybe XML format) file that users could forward to corporate IT that made the request precise and exact. Well, really we could reuse MUD format for that, along with the signature format, it's just that the statement would come out of a browser rather than via https from MUD URL. >> > Some people in this discussion have proposed narrowing the scope = so >> > that endpoints only trust a set of well-known, manually >> > pre-configured set of such appliances, but still tackle challenges >> > like end2end integrity. >>=20 >> I think set of well-known pre-configured set of device is good idea >> for most of the IoT devices. IoT devices usually do not want to talk >> to random devices in the internet, they will need to talk to the few >> things pre-configured to them. And for that filtering basic firewall >> is usually enough. >>=20 >> This does not work for laptops or similar, but works for most of the >> IoT devices. > That suggests separation of those two classes of use cases in > discussion and design applicability. The above line of reasoning also > appears to assume that it's acceptable to prohibit P2P functionality > (i.e., "talk[ing] to random devices in the Internet") in IoT devices. > I'm not sure about that. Given that we have no real technical definition of IoT (I've proposed some, btw), it's hard to make categories. 95% of devices that currently are call= ed IoT are really in my definition, "Web Connected Devices", because they never talk to anything other than the "cloud", and sometimes they want to open a port-80 equivalent. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlo5uxgACgkQgItw+93Q 3WWZngf+K4v8bN5IcoMpkrNVLprud3xka5v57y6DhevfPdT9FXzcZKDyXGLS5cfd s7lVwjIPj2QOZel9uhcY3pojNlLaBHE4QFfUTJs4FzhkALYxAElsv0L5Si5PlkpH AXqyFgFVaNQBWtiyIjLtmlpWfwJHPMATTBx8vx66h1us2pX/AsCbImouVR2S7GBi AW2Jg2gbwu/Lgh4XGzOD6Qxk+1ug6ONah/AvOjFKAb8SCfpVsjQtU9VVewWYeBg0 0qMjf1sp2BU9o6eU19/cM2xIaezesyX8JbeGC8dDkg/sk4FhzBkPAokN1CrYwEMt kqVbPR8YxtoPnbH+BUZ8bPh83BxdiA== =aFDN -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 19 17:31:04 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF4B128961; Tue, 19 Dec 2017 17:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 RR43qv_npJgE; Tue, 19 Dec 2017 17:31:01 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9510D124D85; Tue, 19 Dec 2017 17:31:01 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7BC282008D; Tue, 19 Dec 2017 20:34:41 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7DF2081AFF; Tue, 19 Dec 2017 20:31:00 -0500 (EST) From: Michael Richardson To: Tero Kivinen cc: "Black\, David" , "patient\@ietf.org" , "saag\@ietf.org" In-Reply-To: <23097.32627.710293.414741@fireball.acr.fi> References: <23096.60715.827133.4311 08@fireball.acr.fi> <23097.32627.710293.414741@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] [EXT] Re: [Patient] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 01:31:03 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: > On the other hand as that configuration is so common, lots of IoT > devices have "call home" protocol, i.e., they will periodically > connect to some home server and ask if there is anything they need to > do, and this allows attack vector for attacking those devices.=20 that is, "Web Connected Devices", rather IoT, which would: > IoT is quite often used to mean devices that do machine to machine > communications, i.e., where there is no user or user interface on the > device. I.e., the thermostat sending temperature, or fetching the > configuration from the cloud or local server. > For those devices connecting random IP-address in the world is not > usually needed. They only communicate with the machines they are > configured to communicate with and thats it. These devices have also =20=20=20=20 Thermostat sending temperature to furnace would be IoT. Thermostat sending temperature to cloud so that furnace can retrieve it is Web Connected Device. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlo5vVQACgkQgItw+93Q 3WV8OAf/YRCsdGEcYAYWBC/nj3AgEKaI/F9XNWC6PsxJ/I2Hd3tlHtoncC+1iZXu q3Hh2ggQby+REKOLDOSMYIDNf0+9k4Sv1+3DKkv1ZVlgA0TyVKvVMLSd8zynb2XH 9jBbKXxIab26QX1RlFlNB+mx6FkkwHmH3/MU6cHHWTix2DIM+wo9K5gvyLj5mY8l fOyrZprl3t+xeUVuKsADaDEkJrAzR5rixyV+SPJewTfWrR9D4Aot/g9Cqa2cdWVU /svhSZ4LfV6yuZs+GuptZw1F6+LihXA7YJOyOlU3sR5BmbX59Z9J1YyRZyhgXnaP 0h0An//VnIxuxjZb/miNYporyByU1g== =PcLr -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 19 17:46:58 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B9D126C83; Tue, 19 Dec 2017 17:46:57 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 TDzhW5HeYPyZ; Tue, 19 Dec 2017 17:46:55 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 94ABB124D85; Tue, 19 Dec 2017 17:46:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1513734414; x=1545270414; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3RqtFr1zo/6OszrdqAc5Fd2lv/LChW5pjwDXaHZVVkY=; b=ZiG38+jGy9eeKX98pFnNydHhxopW7yz2GPAY8V5KlAze7lNmGYjv3SFW +3zrs0zNXagRHfNkpquOedM4G159GVVkoYQ8rjB5yzEB4O+l+dJBDcCWF K15abp4ybKUpNn7yNYo8m/jWebA01z/RYsOpI9EjqOykY25iqWJtKh4fu sTx4o4nr7hiZeZ3qB+PwESMvnIkDDvaolSu93z+hwzFefNl91IfH2ZD9Z 2exRNTVPULWqvBPQehAnv7LIxm33X991CkHpj+9Qyo0xxJQMpWXS5RT+h uZ8x04rIURUYakwiayeX2BlOQ8++eHxFaqbmx3Y6fhoZhDqn4GXpkjFct w==; X-IronPort-AV: E=Sophos;i="5.45,429,1508756400"; d="scan'208";a="204760792" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-c.UoA.auckland.ac.nz) ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Dec 2017 14:46:52 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.4) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 20 Dec 2017 14:46:52 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Wed, 20 Dec 2017 14:46:52 +1300 From: Peter Gutmann To: Tero Kivinen , "Black, David" CC: "patient@ietf.org" , "saag@ietf.org" Thread-Topic: [saag] [EXT] Re: [Patient] Internet Draft posted as requested - Thread-Index: AQHTeCdAqRYgAb7440utfVulMGX/iaNJof+AgACmfICAAAfmgIABJ/t+ Date: Wed, 20 Dec 2017 01:46:51 +0000 Message-ID: <1513734394190.22316@cs.auckland.ac.nz> References: <23096.60715.827133.431108@fireball.acr.fi> , <23097.32627.710293.414741@fireball.acr.fi> In-Reply-To: <23097.32627.710293.414741@fireball.acr.fi> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] [EXT] Re: [Patient] Internet Draft posted as requested - X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 01:46:57 -0000 Tero Kivinen writes:=0A= =0A= >On the other hand as that configuration is so common, lots of IoT devices= =0A= >have "call home" protocol, i.e., they will periodically connect to some ho= me=0A= >server and ask if there is anything they need to do, and this allows attac= k=0A= >vector for attacking those devices.=0A= =0A= Implementation of the equivalent of RFC 3093 is so widespread that I don't= =0A= know why it wasn't issued as standards-track...=0A= =0A= The near-universal use of rendezvous servers as an extension of 3093 may=0A= actually be worse than leaving the things exposed on the Internet [0]. Inst= ead=0A= of having to locate and compromise thousands or millions of individual=0A= devices, all an attacker needs to do is get the rendezvous server and they = own=0A= all of them at once.=0A= =0A= Peter.=0A= =0A= [0] Comment based on no evidence whatsoever.=0A=