From nobody Tue Jul 2 05:49:26 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEDE1200B7 for ; Tue, 2 Jul 2019 05:49:20 -0700 (PDT) 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, SPF_HELO_NONE=0.001, 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 xJ-GxcIRBUsX for ; Tue, 2 Jul 2019 05:49:18 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0785E12006A for ; Tue, 2 Jul 2019 05:49:18 -0700 (PDT) Received: from [192.168.1.114] (unknown [160.176.57.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id BA08D93F84; Tue, 2 Jul 2019 14:49:15 +0200 (CEST) To: IETF SecDispatch , "pearg@irtf.org" From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Cc: =?UTF-8?Q?Iv=c3=a1n_Arce_=28Quarkslab=29?= Message-ID: <3ef209f1-19f4-1ae9-d04b-a9bfa94810d4@si6networks.com> Date: Tue, 2 Jul 2019 13:49:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Secdispatch] Predictable numeric IDs (here we go again) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 12:49:20 -0000 Folks, The issue of predictable numeric IDs keeps popping up. This time: * In 6man, wrt embedding MAC addresses in Interface Identifiers: https://mailarchive.ietf.org/arch/msg/ipv6/U3ZCkirsTIs6uvacyo4WsZPdPI0 and, * In NTP, wrt to employing predictable port numbers unnecessarily. See: https://mailarchive.ietf.org/arch/browse/static/ntp/2019-05/ We authored an I-D (https://tools.ietf.org/html/draft-gont-predictable-numeric-ids) to proactively address these issues, and even provided a split version of it: * https://tools.ietf.org/html/draft-gont-numeric-ids-history * https://tools.ietf.org/html/draft-gont-numeric-ids-generation * https://tools.ietf.org/html/draft-gont-numeric-ids-sec-considerations We did presentations at the sec area (back in Buenos Aires, IIRC) and secdispatch -- in different timeframes, but this still seems to be stalled somewhere. We hope the IETF gets to work on this, instead of having to re-hash the same discussions over and over again every time, for different protocols, in different wgs, and then having to patch specs where applicable. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jul 2 06:06:31 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47160120096 for ; Tue, 2 Jul 2019 06:06:30 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 mRdjwbeQ5Uh6 for ; Tue, 2 Jul 2019 06:06:29 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 851E3120059 for ; Tue, 2 Jul 2019 06:06:28 -0700 (PDT) Received: from [192.168.1.114] (unknown [160.176.57.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id D11D5943FF; Tue, 2 Jul 2019 15:05:58 +0200 (CEST) To: Kathleen Moriarty , IETF SecDispatch References: From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Tue, 2 Jul 2019 13:53:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Secdispatch] Call for Agenda items X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 13:06:30 -0000 On 26/6/19 19:55, Kathleen Moriarty wrote: > Hello, > > If you wish to present at SecDispatch in Montreal, please send a message > to the chairs and preferably to the list with the draft link that you > plan to present. Not sure whether another presentation is needed... but we'd like to hear thoughts on how to make progress on our draft on numeric IDs (or its splited version). If a presentation is needed, I could do a remote one. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jul 3 18:06:30 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E7512024F for ; Wed, 3 Jul 2019 18:06:28 -0700 (PDT) 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_HELO_NONE=0.001, 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 LGR5fHnnAJfP for ; Wed, 3 Jul 2019 18:06:27 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 32B381202AD for ; Wed, 3 Jul 2019 18:06:26 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6416LeI016290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 3 Jul 2019 21:06:24 -0400 Date: Wed, 3 Jul 2019 20:06:21 -0500 From: Benjamin Kaduk To: Fernando Gont Cc: Kathleen Moriarty , IETF SecDispatch Message-ID: <20190704010620.GK13047@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Secdispatch] Call for Agenda items X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 01:06:29 -0000 On Tue, Jul 02, 2019 at 01:53:25PM +0100, Fernando Gont wrote: > On 26/6/19 19:55, Kathleen Moriarty wrote: > > Hello, > > > > If you wish to present at SecDispatch in Montreal, please send a message > > to the chairs and preferably to the list with the draft link that you > > plan to present. > > Not sure whether another presentation is needed... but we'd like to hear > thoughts on how to make progress on our draft on numeric IDs (or its > splited version). FWIW, if I remember correctly the history it would be reasonable for me to AD-sponsor draft-gont-numeric-ids-sec-considerations, but I haven't had a chance to double-check my memory yet. > If a presentation is needed, I could do a remote one. I'd love to hear feedback from people about draft-gont-numeric-ids-sec-considerations even before Montreal; it's not really clear to me yet whether a presentation is needed, either. -Ben From nobody Thu Jul 4 13:27:11 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF79612016E for ; Thu, 4 Jul 2019 13:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 VunYeFXRlsL4 for ; Thu, 4 Jul 2019 13:27:07 -0700 (PDT) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (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 6C5A1120232 for ; Thu, 4 Jul 2019 13:27:07 -0700 (PDT) Received: by mail-ot1-f44.google.com with SMTP id l15so6977574otn.9 for ; Thu, 04 Jul 2019 13:27:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z+TnrFrdkma9/ByZECtAVJSuNDaiPwsRgU4kaLJFqRQ=; b=pZ0ror5qWqpAlcwaxhYMHC1m8AevV+XPZJEQ/6bVEzBBRu5p7F4K398WKxMVdQwtpm JPPIcRXOnvBxooOhrVr/wBWwcEbKeof20dkbHmQs0ban9z0X5Hek7lx2UpVPZ6XY6eOK BLaKuQFyDfsvDkxPAvEPlLJyExbgjtT0trOXqTKSydoaEvFMiU07K6FGFS+5SLEs738h vzmaor6Ep6xU2om2y3W7P6p/0n+RG3aPd5gDwSTyEs7jMyVpAVcuzvRq+QIB1DSLXodV K1ecLtMItRQqj40RVN1/Zta3hG2iXG4PNxBg0mn4ebH8k1V3lnxRKvXMglOY1tryGJWi RFSA== X-Gm-Message-State: APjAAAWlbGneVIlnSgYJgE+olTrVL71paLkjlJdv1weec/VHVgt2wM3H DTVeKkwe46CmjWi+oEaCAvX6I1xPpwu11YvJQec= X-Google-Smtp-Source: APXvYqw3WJ2xyRdpsNFxpkj6A1VJHwTnhTV0XLN9vK4NOEcAUUvI0CW11Y786SEiEf55wXtzUYQYiwW/3Sab+HOLKuM= X-Received: by 2002:a9d:7d02:: with SMTP id v2mr13594563otn.112.1562272026406; Thu, 04 Jul 2019 13:27:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Thu, 4 Jul 2019 16:26:56 -0400 Message-ID: To: Kathleen Moriarty Cc: IETF SecDispatch Content-Type: multipart/alternative; boundary="0000000000002d3423058ce0cdf7" Archived-At: Subject: Re: [Secdispatch] Call for Agenda items X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 20:27:10 -0000 --0000000000002d3423058ce0cdf7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would like to present the Mathematical Mesh I have been working on. I would also like to arrange to meet people who may be interested in this work at a BAR BOF. Preferably one in an actual bar at this point. Right now, the only person funding this work is me (though I am grateful for the considerable amount of support from Comodo). I am currently looking at options to take the work further. The one non-negotiable criteria being that this is at root a communications system, it can only reach its full potential if it is unencumbered, that means anyone can use it or extend it without fees, licenses or permission. The objective of the Mesh is to make computers easier to use by providing a security infrastructure that works without users needing to be aware that they are using it. The Mesh can be used as a mechanism for managing credentials (passwords, private keys, etc.) for existing security applications (SSH, OpenPGP, S/MIME) or it can be used as a platform for developing new applications (end-to-end secure password catalog, secure contact exchange). One of my frustrations with the current situation in the industry is that we haven't moved on from cryptography developed in the 1980s. We have better algorithms to use in place of DES, MD5 and RSA but we haven't added a new capability since BitCoin added hash chains to the canon ten years ago and the patent on that was 1990. The Mesh introduces a new set of cryptographic techniques: *Uniform Data Fingerprints*: Think of this as 'Cryptography on rails'. Rails is a powerful framework because it uses the same name for the same field in every situation. UDF does the same for cryptographic keys. *QR Codes*: Imagine being able to scan a QR code on your bills, your pay stubs, tax advice, etc and get to a machine readable copy of the document you are reading. That is what EARLs provide. *Multi-Party Key Generation*: Weak keys have been a problem for decades and now we have to consider the possibility that a key was compromised by the device manufacturer. But keys generated during manufacture that cannot be extracted could be the very best keys to use (if we can trust them). Combining keys generated on multiple devices allows this concern to be mitigated. *Multi-Party Decryption*: Traditional CRM schemes use the Ford-Wiener key release with a key server in the cloud dispensing decryption keys to authorized readers. The problem with this approach is that our chief data confidentiality concern is a breach of the cloud, i.e. the key server. Separating the decryption function into two parts and requiring both to participate enables a key server to control decryption of data without being able to decrypt. *DARE Envelope*: This is a new PKCS#7 type format built on JOSE which provides the hooks needed to support the Multi-Party Decryption scheme DARE Container. *DARE Container*: An append only log format supporting incremental encryption and authentication. If I am talking to VC, I might even call it a block chain. *Shamir Secret Sharing*: Personal Escrow of the user's keys is supported with up to 16 shares and a quorum of 1-15. There is quite a bit more to the system but it remains remarkably compact and especially so considering the scope of its capabilities. One innovation that addresses a current concern is that Mesh Accounts are the property of a user and not the service provider. So if I want to change my service provider from example.com to example.net, I can do that at any time of my choosing and I don't need example.com to co-operate of give permission for the transfer. The trust model does have a role for Certificate Authorities but this is optional and limited to the discovery process, CAs are not ongoing participants in every transaction. Direct exchange is also supported via both an in-person model (e.g. QR code exchange or bump phones) or remotely. All the reference code is MIT License and copyright Comodo Group (to Version 2.0) and Comodo Group and myself (3.0 on). The tool chain used to build the system is MIT License and my copyright. I have attempted to avoid encumbered technology and I am not aware of any valid claims on the current specs but make no warranties in that regard. I have submitted all the documents as Internet drafts but there is a catch, I am writing the documents assuming that the transition to HTML RFCs is going to happen. So you can read them as plaintext drafts if you insist. But the HTML documents have diagrams and use superscripts and subscripts for the math rather than X_A which makes them a lot easier to read. The architecture draft provides an overview of the project: http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html The following drafts are nearing completion. I am currently working on getting the worked examples from the running code worked in: http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html http://mathmesh.com/Docume=E2=80=A6/draft-hallambaker-mesh-dare.html http://mathmesh.com/Docu=E2=80=A6/draft-hallambaker-mesh-schema.html http://mathmesh.com/Documents/draft-hallambaker-mesh-cryptography.html I might have the protocol specification available by Montreal but that might slip. On Wed, Jun 26, 2019 at 2:55 PM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hello, > > If you wish to present at SecDispatch in Montreal, please send a message > to the chairs and preferably to the list with the draft link that you pla= n > to present. > > Thank you. > > -- > > Best regards, > Kathleen > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --0000000000002d3423058ce0cdf7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I w= ould like to present the Mathematical Mesh I have been working on. I would = also like to arrange to meet people who may be interested in this work at a= BAR BOF. Preferably one in an actual bar at this point.

Right now, the only person funding this wor= k is me (though I am grateful for the considerable amount of support from C= omodo). I am currently looking at options to take the work further. The one= non-negotiable criteria being that this is at root a communications system= , it can only reach its full potential if it is unencumbered, that means an= yone can use it or extend it without fees, licenses or permission.


The objective of the Mesh is to make comput= ers easier to use by providing a security infrastructure that works without= users needing to be aware that they are using it.

The Mesh can be used as a mechanism for managing = credentials (passwords, private keys, etc.) for existing security applicati= ons (SSH, OpenPGP, S/MIME) or it can be used as a platform for developing n= ew applications (end-to-end secure password catalog, secure contact exchang= e).

<= div class=3D"gmail_default" style=3D"font-size:small">One of my frustration= s with the current situation in the industry is that we haven't moved o= n from cryptography developed in the 1980s. We have better algorithms to us= e in place of DES, MD5 and RSA but we haven't added a new capability si= nce BitCoin added hash chains to the canon ten years ago and the patent on = that was 1990.
=
The Mesh i= ntroduces a new set of cryptographic techniques:

Uniform Data Fingerprints: Think of this as = 'Cryptography on rails'. Rails is a powerful framework because it u= ses the same name for the same field in every situation. UDF does the same = for cryptographic keys.

<= b>QR Codes: Imagine being able to scan a QR code on your bills, your pa= y stubs, tax advice, etc and get to a machine readable copy of the document= you are reading. That is what EARLs provide.

Multi-Party Key Generation: Weak keys have been= a problem for decades and now we have to consider the possibility that a k= ey was compromised by the device manufacturer. But keys generated during ma= nufacture that cannot be extracted could be the very best keys to use (if w= e can trust them). Combining keys generated on multiple devices allows this= concern to be mitigated.

Multi-Party Decryption: Traditional CRM schemes use the Ford-Wiener= key release with a key server in the cloud dispensing decryption keys to a= uthorized readers. The problem with this approach is that our chief data co= nfidentiality concern is a breach of the cloud, i.e. the key server. Separa= ting the decryption function into two parts and requiring both to participa= te enables a key server to control decryption of data without being able to= decrypt.

<= /div>
DARE Envelop= e: This is a new PKCS#7 type format built on JOSE which provides the ho= oks needed to support the Multi-Party Decryption scheme DARE Container.

DARE Container: An ap= pend only log format supporting incremental encryption and authentication. = If I am talking to VC, I might even call it a block chain.

Shamir Secret Sharing: Persona= l Escrow of the user's keys is supported with up to 16 shares and a quo= rum of 1-15.=C2=A0

There = is quite a bit more to the system but it remains remarkably compact and esp= ecially so considering the scope of its capabilities.=C2=A0

One innovation that addresses a current = concern is that Mesh Accounts are the property of a user and not the servic= e provider. So if I want to change my service provider from example.com to example.n= et, I can do that at any time of my choosing and I don't need example.com to co-operate of give permission = for the transfer.=C2=A0

T= he trust model does have a role for Certificate Authorities but this is opt= ional and limited to the discovery process, CAs are not ongoing participant= s in every transaction. Direct exchange is also supported via both an in-pe= rson model (e.g. QR code exchange or bump phones) or remotely.=C2=A0
<= div class=3D"gmail_default" style=3D"font-size:small">

All the reference code is MIT License an= d copyright Comodo Group (to Version 2.0) and Comodo Group and myself (3.0 = on). The tool chain used to build the system is MIT License and my copyrigh= t. I have attempted to avoid encumbered technology and I am not aware of an= y valid claims on the current specs but make no warranties in that regard.<= /div>


I have submitted all the documents = as Internet drafts but there is a catch, I am writing the documents assumin= g that the transition to HTML RFCs is going to happen. So you can read them= as plaintext drafts if you insist. But the HTML documents have diagrams an= d use superscripts and subscripts for the math rather than X_A which makes = them a lot easier to read.

The architecture draft provides an overview of the project:

http://mathmesh.com/Documents/= draft-hallambaker-mesh-architecture.html

The following drafts a= re nearing completion. I am currently working on getting the worked example= s from the running code worked in:

http://mathmesh.com/Documents/draf= t-hallambaker-mesh-udf.html
= http://mathmesh.com/Docume=E2=80=A6/draft-hallambaker-mesh-dare.html = =C2=A0
http://mathmesh.com/Docu=E2=80=A6/draft-hallambaker-mesh-schema.html=C2=A0=C2=A0


I might have the protocol spec= ification available by Montreal but that might slip.



=
On Wed, Jun 26, 2019 at 2:55 PM Kathl= een Moriarty <kathle= en.moriarty.ietf@gmail.com> wrote:
Hello,

If you= wish to present at SecDispatch in Montreal, please send a message to the c= hairs and preferably to the list with the draft link that you plan to prese= nt.

Thank you.

-- =
=

Best regards,
Kathleen
_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--0000000000002d3423058ce0cdf7-- From nobody Mon Jul 8 11:08:40 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A96812051D for ; Mon, 8 Jul 2019 11:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 qJvsdHvCOoLw for ; Mon, 8 Jul 2019 11:08:29 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 821EF1205DC for ; Mon, 8 Jul 2019 11:08:29 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id r6so17153511oti.3 for ; Mon, 08 Jul 2019 11:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CUhl18UsOv1cYfqUOgPnsQER8en/6L6O9FGJZe6Aj84=; b=qK4YrzloeisLulnT5q89o46sgksKRkp4PSi6zUXdr6P2SVM4SlRBasPw29Jn1ABRVo oyplV9pDEE6xRMTxIREif0zqRaeuQJ+rTuOrXb4E3ie8AWNHLEK+o5YxK6JXkyrtzF1e I+8iQIIqOEB1xqYMXx4vkgXb8RvwRVfHSUl1VagzyEKalBj6LqFqPyigzu6aRDywCYo+ GzgclH3USbUqEl//noypMHLOMkMcumiaVnoiALCEkc3Hp4ObL4RPcOEp8m2t5973YDt3 SiSMA7YzjRbzPvG+m5gmffWD0+A/clie3lmpI6ksD2YWpb1mCD1XZWNZYoUWV/qgE0z1 8dBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CUhl18UsOv1cYfqUOgPnsQER8en/6L6O9FGJZe6Aj84=; b=uYSr2PnXVx9MitopO8g5uGl75iNrgucGQMSyb6a630bCvwv//HaxMfsP6zZnKeUpDb Bz0uVcMXiAOKDWwDqvDUQ8PR8MAXiEy3ssOtExtzorRtdzszsjH2ka2or+PbGmMzaBdC djUYYFlV1SLqrT5oqsPHejINWNjUmyAzgvamsYMqJedyTpP8EMnoKmslaaDFmmSsZS9e hCfOrsvfAa6vQ9t7ZTOlGnESB3DuB5GdE3C5rA7mZNMGrkITtu4i5QyLsUfx229zDS5J ihQaQx1uMIvGkZ5YD/CN5X0jq2AKece+jmg11gi3+a1M4oNs2MhefK81f4CgrtCr9aY+ 6FNg== X-Gm-Message-State: APjAAAWUnINZPFNcb3ZQ/ImIOi0gQOEV9DYY02COJ0by8Is58xHUz8/z gbHnK7aguo8QnWLE+Kb5KoCfC71Obn27KKo10k8= X-Google-Smtp-Source: APXvYqyN1TpNLUNGB+q3ASaFgX+nAZk2lCJlQkbXQapUGfEQi+34vBR6OVTASA+AyEu+DGKaapNXwf4xcyx+vWXfnCI= X-Received: by 2002:a9d:6394:: with SMTP id w20mr1370782otk.151.1562609308724; Mon, 08 Jul 2019 11:08:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kathleen Moriarty Date: Mon, 8 Jul 2019 14:07:52 -0400 Message-ID: To: Phillip Hallam-Baker Cc: IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000c4f1a6058d2f5425" Archived-At: Subject: Re: [Secdispatch] Call for Agenda items X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 18:08:40 -0000 --000000000000c4f1a6058d2f5425 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Phil. Please feel free to comment on Phil's proposal and drafts in a new thread. Best regards, Kathleen On Thu, Jul 4, 2019 at 4:27 PM Phillip Hallam-Baker wrote: > I would like to present the Mathematical Mesh I have been working on. I > would also like to arrange to meet people who may be interested in this > work at a BAR BOF. Preferably one in an actual bar at this point. > > Right now, the only person funding this work is me (though I am grateful > for the considerable amount of support from Comodo). I am currently looki= ng > at options to take the work further. The one non-negotiable criteria bein= g > that this is at root a communications system, it can only reach its full > potential if it is unencumbered, that means anyone can use it or extend i= t > without fees, licenses or permission. > > > The objective of the Mesh is to make computers easier to use by providing > a security infrastructure that works without users needing to be aware th= at > they are using it. > > The Mesh can be used as a mechanism for managing credentials (passwords, > private keys, etc.) for existing security applications (SSH, OpenPGP, > S/MIME) or it can be used as a platform for developing new applications > (end-to-end secure password catalog, secure contact exchange). > > One of my frustrations with the current situation in the industry is that > we haven't moved on from cryptography developed in the 1980s. We have > better algorithms to use in place of DES, MD5 and RSA but we haven't adde= d > a new capability since BitCoin added hash chains to the canon ten years a= go > and the patent on that was 1990. > > The Mesh introduces a new set of cryptographic techniques: > > *Uniform Data Fingerprints*: Think of this as 'Cryptography on rails'. > Rails is a powerful framework because it uses the same name for the same > field in every situation. UDF does the same for cryptographic keys. > > *QR Codes*: Imagine being able to scan a QR code on your bills, your pay > stubs, tax advice, etc and get to a machine readable copy of the document > you are reading. That is what EARLs provide. > > *Multi-Party Key Generation*: Weak keys have been a problem for decades > and now we have to consider the possibility that a key was compromised by > the device manufacturer. But keys generated during manufacture that canno= t > be extracted could be the very best keys to use (if we can trust them). > Combining keys generated on multiple devices allows this concern to be > mitigated. > > *Multi-Party Decryption*: Traditional CRM schemes use the Ford-Wiener key > release with a key server in the cloud dispensing decryption keys to > authorized readers. The problem with this approach is that our chief data > confidentiality concern is a breach of the cloud, i.e. the key server. > Separating the decryption function into two parts and requiring both to > participate enables a key server to control decryption of data without > being able to decrypt. > > *DARE Envelope*: This is a new PKCS#7 type format built on JOSE which > provides the hooks needed to support the Multi-Party Decryption scheme DA= RE > Container. > > *DARE Container*: An append only log format supporting incremental > encryption and authentication. If I am talking to VC, I might even call i= t > a block chain. > > *Shamir Secret Sharing*: Personal Escrow of the user's keys is supported > with up to 16 shares and a quorum of 1-15. > > There is quite a bit more to the system but it remains remarkably compact > and especially so considering the scope of its capabilities. > > One innovation that addresses a current concern is that Mesh Accounts are > the property of a user and not the service provider. So if I want to chan= ge > my service provider from example.com to example.net, I can do that at any > time of my choosing and I don't need example.com to co-operate of give > permission for the transfer. > > The trust model does have a role for Certificate Authorities but this is > optional and limited to the discovery process, CAs are not ongoing > participants in every transaction. Direct exchange is also supported via > both an in-person model (e.g. QR code exchange or bump phones) or remotel= y. > > > All the reference code is MIT License and copyright Comodo Group (to > Version 2.0) and Comodo Group and myself (3.0 on). The tool chain used to > build the system is MIT License and my copyright. I have attempted to avo= id > encumbered technology and I am not aware of any valid claims on the curre= nt > specs but make no warranties in that regard. > > > I have submitted all the documents as Internet drafts but there is a > catch, I am writing the documents assuming that the transition to HTML RF= Cs > is going to happen. So you can read them as plaintext drafts if you insis= t. > But the HTML documents have diagrams and use superscripts and subscripts > for the math rather than X_A which makes them a lot easier to read. > > The architecture draft provides an overview of the project: > > http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html > > The following drafts are nearing completion. I am currently working on > getting the worked examples from the running code worked in: > > http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html > http://mathmesh.com/Docume=E2=80=A6/draft-hallambaker-mesh-dare.html > http://mathmesh.com/Docu=E2=80=A6/draft-hallambaker-mesh-schema.html > http://mathmesh.com/Documents/draft-hallambaker-mesh-cryptography.html > > > I might have the protocol specification available by Montreal but that > might slip. > > > > On Wed, Jun 26, 2019 at 2:55 PM Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> Hello, >> >> If you wish to present at SecDispatch in Montreal, please send a message >> to the chairs and preferably to the list with the draft link that you pl= an >> to present. >> >> Thank you. >> >> -- >> >> Best regards, >> Kathleen >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch >> > --=20 Best regards, Kathleen --000000000000c4f1a6058d2f5425 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Phil.=C2=A0=C2=A0

Please feel f= ree to comment on Phil's proposal and drafts in a new thread.

Best regards,
Kathleen

On Thu, Jul 4, 2019 = at 4:27 PM Phillip Hallam-Baker <phill@hallambaker.com> wrote:
I would like to present the Mathematical Mesh I have b= een working on. I would also like to arrange to meet people who may be inte= rested in this work at a BAR BOF. Preferably one in an actual bar at this p= oint.

Right now, the only= person funding this work is me (though I am grateful for the considerable = amount of support from Comodo). I am currently looking at options to take t= he work further. The one non-negotiable criteria being that this is at root= a communications system, it can only reach its full potential if it is une= ncumbered, that means anyone can use it or extend it without fees, licenses= or permission.


The objective of th= e Mesh is to make computers easier to use by providing a security infrastru= cture that works without users needing to be aware that they are using it.<= /div>

The Mesh can be used as a= mechanism for managing credentials (passwords, private keys, etc.) for exi= sting security applications (SSH, OpenPGP, S/MIME) or it can be used as a p= latform for developing new applications (end-to-end secure password catalog= , secure contact exchange).

One of my frustrations with the current situation in the industry is tha= t we haven't moved on from cryptography developed in the 1980s. We have= better algorithms to use in place of DES, MD5 and RSA but we haven't a= dded a new capability since BitCoin added hash chains to the canon ten year= s ago and the patent on that was 1990.

The Mesh introduces a new set of cryptographic techniques:

Uniform Data Fingerprint= s: Think of this as 'Cryptography on rails'. Rails is a powerfu= l framework because it uses the same name for the same field in every situa= tion. UDF does the same for cryptographic keys.

QR Codes: Imagine being able to scan a QR cod= e on your bills, your pay stubs, tax advice, etc and get to a machine reada= ble copy of the document you are reading. That is what EARLs provide.
=

Multi-Party Key Generation<= /b>: Weak keys have been a problem for decades and now we have to consider = the possibility that a key was compromised by the device manufacturer. But = keys generated during manufacture that cannot be extracted could be the ver= y best keys to use (if we can trust them). Combining keys generated on mult= iple devices allows this concern to be mitigated.

Multi-Party Decryption: Traditional CRM sch= emes use the Ford-Wiener key release with a key server in the cloud dispens= ing decryption keys to authorized readers. The problem with this approach i= s that our chief data confidentiality concern is a breach of the cloud, i.e= . the key server. Separating the decryption function into two parts and req= uiring both to participate enables a key server to control decryption of da= ta without being able to decrypt.

DARE Envelope: This is a new PKCS#7 type format built on = JOSE which provides the hooks needed to support the Multi-Party Decryption = scheme DARE Container.

DARE Container: An append only log format supporting incremental encry= ption and authentication. If I am talking to VC, I might even call it a blo= ck chain.
<= br>
Shamir S= ecret Sharing: Personal Escrow of the user's keys is supported with= up to 16 shares and a quorum of 1-15.=C2=A0

There is quite a bit more to the system but it remains= remarkably compact and especially so considering the scope of its capabili= ties.=C2=A0
One innovatio= n that addresses a current concern is that Mesh Accounts are the property o= f a user and not the service provider. So if I want to change my service pr= ovider from example.com to example.net, I ca= n do that at any time of my choosing and I don't need example.com to co-operate of give permi= ssion for the transfer.=C2=A0

The trust model does have a role for Certificate Authorities but this = is optional and limited to the discovery process, CAs are not ongoing parti= cipants in every transaction. Direct exchange is also supported via both an= in-person model (e.g. QR code exchange or bump phones) or remotely.=C2=A0<= /div>


All the reference code is MIT Licen= se and copyright Comodo Group (to Version 2.0) and Comodo Group and myself = (3.0 on). The tool chain used to build the system is MIT License and my cop= yright. I have attempted to avoid encumbered technology and I am not aware = of any valid claims on the current specs but make no warranties in that reg= ard.

=

I have submitted all the docum= ents as Internet drafts but there is a catch, I am writing the documents as= suming that the transition to HTML RFCs is going to happen. So you can read= them as plaintext drafts if you insist. But the HTML documents have diagra= ms and use superscripts and subscripts for the math rather than X_A which m= akes them a lot easier to read.

The architecture draft provides an overview of the project:

http://= mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html
The following drafts are nearing completion. I am currently working on get= ting the worked examples from the running code worked in:

http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html http://mathmesh.= com/Docume=E2=80=A6/draft-hallambaker-mesh-dare.html =C2=A0
http://mathmesh.com/Docu=E2=80=A6/draft-hallambaker-mesh-schema.html=C2=A0=C2=A0

I might have= the protocol specification available by Montreal but that might slip.



On Wed, Jun 26, 201= 9 at 2:55 PM Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrot= e:
Hello,

If you wish to present at SecDispatch in Mont= real, please send a message to the chairs and preferably to the list with t= he draft link that you plan to present.

Thank you.=

--

Best regards,
Kathleen
_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch


--

Best regards,
Kathleen
--000000000000c4f1a6058d2f5425-- From nobody Mon Jul 8 11:38:09 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5DC1206CD for ; Mon, 8 Jul 2019 11:37:59 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 sq0DnQq_8nR6 for ; Mon, 8 Jul 2019 11:37:57 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 710291206EA for ; Mon, 8 Jul 2019 11:37:43 -0700 (PDT) Received: from [192.168.1.16] (unknown [41.143.218.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 037A784A49; Mon, 8 Jul 2019 20:37:38 +0200 (CEST) To: IETF SecDispatch From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <0930807a-a6a4-b6db-2731-1f14c448ed0b@si6networks.com> Date: Mon, 8 Jul 2019 19:37:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Secdispatch] Security Considerations for Transient Numeric Identifiers Employed in Network Protocols (draft-gont-numeric-ids-sec-considerations) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 18:38:08 -0000 Folks, We have posted a rev of our IETF I-D, in the hopes that protocol specs and implementations stop using flawed transient numeric identifiers. The rev is available at: https://www.ietf.org/id/draft-gont-numeric-ids-sec-considerations-04.txt We have also revised the two companion documents: * History of flawed numeric IDs: https://www.ietf.org/internet-drafts/draft-gont-numeric-ids-history-05.txt * Analysis of algorithms for generating numeric ids:https://www.ietf.org/internet-drafts/draft-gont-numeric-ids-generation-04.txt Your feedback is welcome. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jul 10 08:29:45 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCE012043A for ; Wed, 10 Jul 2019 08:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 uQR3iyvYiUpx for ; Wed, 10 Jul 2019 08:29:38 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 2A8BD120402 for ; Wed, 10 Jul 2019 08:29:09 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id m30so1268904pff.8 for ; Wed, 10 Jul 2019 08:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DEkiuGDIlfYrkeKeYohZZKsyDQB4u1JGyIGHqXI7WNk=; b=RSjO2+VtZ9sgqYm1BE1vv75mLDpVnhOp6qL/T9Upu1qplSdZK5qEYXrYrJDuDoOzAt Aj8M1pH1AKHXtTTUEpwfOCcQ9YXCiruI1LlVbOUFRy33Pmkg1TxJ5rDN/MIn51doT3/Y FvQNPDGSSNffRfXiTlURH9pCDTAge/kffV06Hyf7rgReVJFQrXSxpfEFTxGWlVCQMMM7 Lx92/gQSt+dzaWZLYdzDLcbIM7K6qG5Z9MDQ1oAfay57pz+F5DDwuMAcyVcb+8Rz3y9j Zvqt5OkH2HCc2JlXEVLo0eoNemxpHaD3+/V5U3MtiRmTCrzDgwWonmI9cV2Js1FLn47Y pp4Q== 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=DEkiuGDIlfYrkeKeYohZZKsyDQB4u1JGyIGHqXI7WNk=; b=LEhh57DZJeCYYtnDBUDa/Y+C/AsoeKAv5FGFhqd0kdrZjKJ2rNTgn2dSAkQ+YS+XWK rd4bTbWII3d+vKxCoKxMuL9ujNnn9YX0nD+GK0K4nXhOLrd5FL1nXYovDJMcfVONsdnm TXfK0r9TW3LgFM+PbIclZ6aD0QUM0COIBxpOHYMKzNgIe/krDNHLiTx3atnaSzUxbdbG a1Z0I89ziCTEjZORJlAimQllL5OAEZt8tiZ9Em9CJ9dA2G7gzleBoFK4n/7Zj1hE5etg crEK9J1uMHW1XavUkAWU0+B/zrSJFKsPtYMHdd2dIImSlRvK7g0RGluCkz5iL7+p1H9N 8K3A== X-Gm-Message-State: APjAAAWH9yiBc9febYFN2ifKnQuXlqQjMAZAZyzD7ct3D0lJIq45bk01 +vpqDE6kEyE0Gzf/2jM9c6FlZ1NB X-Google-Smtp-Source: APXvYqyQaFX0LVe2EdoksMB+gueRt0XSJmIiVnCGuJjgy77Cmvxd1R2og14/ONllD3e2xpZH5XTpnw== X-Received: by 2002:a63:1658:: with SMTP id 24mr38872675pgw.167.1562772548505; Wed, 10 Jul 2019 08:29:08 -0700 (PDT) Received: from ?IPv6:2605:a601:a990:4d00:89e2:ec6d:a366:d501? ([2605:a601:a990:4d00:89e2:ec6d:a366:d501]) by smtp.gmail.com with ESMTPSA id v22sm2381652pgk.69.2019.07.10.08.29.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jul 2019 08:29:07 -0700 (PDT) From: Bret Jordan Message-Id: <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_73CBA443-9D1A-4E86-9E67-C5565A0AA455" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 10 Jul 2019 09:29:04 -0600 In-Reply-To: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> Cc: smart@irtf.org, Secdispatch@ietf.org To: Dominique Lazanski References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 15:29:42 -0000 --Apple-Mail=_73CBA443-9D1A-4E86-9E67-C5565A0AA455 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dominique, I have read over your draft, and I think it highlights some very key = things we all need to look at and address. Thanks for putting these = ideas down on paper. Hopefully this I-D can help us all start a broader = discussion to improve things. SMART / SecDispatch, If you have not yet read this I-D, I would encourage you to look at it. = It is a very fast read.=20 Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Jul 8, 2019, at 12:54 PM, Dominique Lazanski = wrote: >=20 > Cross posting to this mailing list. >=20 > Dominique=20 >=20 > A new version of I-D, draft-lazanski-smart-users-internet-00.txt > has been successfully submitted by Dominique Lazanski and posted to = the > IETF repository. >=20 > Name: draft-lazanski-smart-users-internet > Revision: 00 > Title: An Internet for Users Again > Document date: 2019-07-08 > Group: Individual Submission > Pages: 12 > URL: = https://www.ietf.org/internet-drafts/draft-lazanski-smart-users-internet-0= 0.txt = > Status: = https://datatracker.ietf.org/doc/draft-lazanski-smart-users-internet/ = > Htmlized: = https://tools.ietf.org/html/draft-lazanski-smart-users-internet-00 = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-lazanski-smart-users-internet = >=20 >=20 > Abstract: > RFC 3552 introduces a threat model that does not include endpoint > security. In the fifteen years since RFC 3552 security issues and > cyber attacks have increased, especially on the endpoint. This > document proposes a new approach to Internet cyber security protocol > development that focuses on the user of the Internet, namely those > who use the endpoint and are the most vulnerable to attacks.=20 > --=20 > Smart mailing list > Smart@irtf.org > https://www.irtf.org/mailman/listinfo/smart --Apple-Mail=_73CBA443-9D1A-4E86-9E67-C5565A0AA455 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dominique,

I have read over your draft, and I think it highlights some = very key things we all need to look at and address. Thanks for putting = these ideas down on paper.  Hopefully this I-D can help us all = start a broader discussion to improve things.

SMART / SecDispatch,

If you have not yet read = this I-D, I would encourage you to look at it.  It is a very fast = read. 

Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Jul 8, 2019, at 12:54 PM, Dominique Lazanski <dml@lastpresslabel.com> wrote:

Cross posting to this mailing list.

Dominique 

A new version of I-D, = draft-lazanski-smart-users-internet-00.txt
has been = successfully submitted by Dominique Lazanski and posted to the
IETF repository.

Name:   =      draft-lazanski-smart-users-internet
Revision:    00
Title:     =    An Internet for Users Again
Document date: =    2019-07-08
Group:       =  Individual Submission
Pages:       =  12
URL: =            https://www.ietf.org/internet-drafts/draft-lazanski-smart-users= -internet-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-lazanski-smart-users-int= ernet/
Htmlized: =       https://tools.ietf.org/html/draft-lazanski-smart-users-internet= -00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-lazanski-smart-user= s-internet


Abstract:
  RFC 3552 introduces a threat model that does not = include endpoint
  security. In the fifteen = years since RFC 3552 security issues and
  cyber = attacks have increased, especially on the endpoint. This
  document proposes a new approach to Internet = cyber security protocol
  development that = focuses on the user of the Internet, namely those
  who use the endpoint and are the most vulnerable = to attacks. 
--
Smart mailing list
Smart@irtf.org
https://www.irtf.org/mailman/listinfo/smart

= --Apple-Mail=_73CBA443-9D1A-4E86-9E67-C5565A0AA455-- From nobody Thu Jul 11 00:27:55 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C8B120302 for ; Thu, 11 Jul 2019 00:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 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, FROM_WORDY=2.261, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.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 juLL5S0wV9Bj for ; Thu, 11 Jul 2019 00:27:45 -0700 (PDT) Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) (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 6FFA91203A2 for ; Thu, 11 Jul 2019 00:27:44 -0700 (PDT) Date: Thu, 11 Jul 2019 07:27:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1562830060; bh=1FH1MyomDcjYblAAuRq/9glAkHWYlGXXWITs34ehVHE=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=pfwqHhxuz2KYsQTUbZw0aDrM0RIevZi++mAZtLk3ibNe+ICnRmGeYv02kHRAvOdV3 42YYqVDyKL+gs8ZQXzK1aemt013SSStneq6eoCxlB+7oMkEirvs5cLWzXTxdemuft+ jpkFlN0vxbRzTkUh1dKX+NSQef1v+JMHxdbQ0BGA= To: Bret Jordan From: "Arnaud.Taddei.IETF" Cc: Dominique Lazanski , "smart@irtf.org" , "Secdispatch@ietf.org" Reply-To: "Arnaud.Taddei.IETF" Message-ID: In-Reply-To: <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> Feedback-ID: kou6vaSHQeY5dgFN9dCIYKo4z6hnnNmKuV4IBJw2wx4vSVPtftyhWUTBigri6zMJ3K1hxYJjI-3RAIGaizMt5g==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_4ee483934c814a7546b5f65a04ac0a52" Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 07:27:53 -0000 This is a multi-part message in MIME format. --b1_4ee483934c814a7546b5f65a04ac0a52 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 TGlrZXdpc2UsIEkgcmVhZCB0aGlzIEktRCBhbmQgaXQgcHV0cyB0aGUgZmluZ2VyIG9uIHRoZSBy aWdodCBuZXJ2ZXMuIFRoYW5rIHlvdSBmb3IgcHV0dGluZyB0aGlzIG9uZSBpbiBwbGFjZS4KCklu ZGVlZCBpdCBpcyB2ZXJ5IHN0cmFpZ2h0Zm9yd2FyZCByZWFkCgpTZW50IHdpdGggW1Byb3Rvbk1h aWxdKGh0dHBzOi8vcHJvdG9ubWFpbC5jb20pIFNlY3VyZSBFbWFpbC4KCuKAkOKAkOKAkOKAkOKA kOKAkOKAkCBPcmlnaW5hbCBNZXNzYWdlIOKAkOKAkOKAkOKAkOKAkOKAkOKAkApPbiBXZWRuZXNk YXkgMTAgSnVseSAyMDE5IDE3OjI5LCBCcmV0IEpvcmRhbiA8am9yZGFuLmlldGZAZ21haWwuY29t PiB3cm90ZToKCj4gRG9taW5pcXVlLAo+Cj4gSSBoYXZlIHJlYWQgb3ZlciB5b3VyIGRyYWZ0LCBh bmQgSSB0aGluayBpdCBoaWdobGlnaHRzIHNvbWUgdmVyeSBrZXkgdGhpbmdzIHdlIGFsbCBuZWVk IHRvIGxvb2sgYXQgYW5kIGFkZHJlc3MuIFRoYW5rcyBmb3IgcHV0dGluZyB0aGVzZSBpZGVhcyBk b3duIG9uIHBhcGVyLiAgSG9wZWZ1bGx5IHRoaXMgSS1EIGNhbiBoZWxwIHVzIGFsbCBzdGFydCBh IGJyb2FkZXIgZGlzY3Vzc2lvbiB0byBpbXByb3ZlIHRoaW5ncy4KPgo+IFNNQVJUIC8gU2VjRGlz cGF0Y2gsCj4KPiBJZiB5b3UgaGF2ZSBub3QgeWV0IHJlYWQgdGhpcyBJLUQsIEkgd291bGQgZW5j b3VyYWdlIHlvdSB0byBsb29rIGF0IGl0LiAgSXQgaXMgYSB2ZXJ5IGZhc3QgcmVhZC4KPgo+IFRo YW5rcywKPiBCcmV0Cj4gUEdQIEZpbmdlcnByaW50OiA2M0I0IEZDNTMgNjgwQSA2QjdEIDE0NDcg IEYyQzAgNzRGOCBBQ0FFIDc0MTUgMDA1MAo+ICJXaXRob3V0IGNyeXB0b2dyYXBoeSB2aWh2IHZp dmMgY2UgeGhybnJ3LCBob3dldmVyLCB0aGUgb25seSB0aGluZyB0aGF0IGNhbiBub3QgYmUgdW5z Y3JhbWJsZWQgaXMgYW4gZWdnLiIKPgo+PiBPbiBKdWwgOCwgMjAxOSwgYXQgMTI6NTQgUE0sIERv bWluaXF1ZSBMYXphbnNraSA8ZG1sQGxhc3RwcmVzc2xhYmVsLmNvbT4gd3JvdGU6Cj4+Cj4+IENy b3NzIHBvc3RpbmcgdG8gdGhpcyBtYWlsaW5nIGxpc3QuCj4+Cj4+IERvbWluaXF1ZQo+Pgo+PiBB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGF6YW5za2ktc21hcnQtdXNlcnMtaW50ZXJuZXQt MDAudHh0Cj4+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRG9taW5pcXVlIExh emFuc2tpIGFuZCBwb3N0ZWQgdG8gdGhlCj4+IElFVEYgcmVwb3NpdG9yeS4KPj4KPj4gTmFtZTog ICAgICAgIGRyYWZ0LWxhemFuc2tpLXNtYXJ0LXVzZXJzLWludGVybmV0Cj4+IFJldmlzaW9uOiAg ICAwMAo+PiBUaXRsZTogICAgICAgIEFuIEludGVybmV0IGZvciBVc2VycyBBZ2Fpbgo+PiBEb2N1 bWVudCBkYXRlOiAgICAyMDE5LTA3LTA4Cj4+IEdyb3VwOiAgICAgICAgSW5kaXZpZHVhbCBTdWJt aXNzaW9uCj4+IFBhZ2VzOiAgICAgICAgMTIKPj4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1sYXphbnNraS1zbWFydC11c2Vycy1pbnRl cm5ldC0wMC50eHQKPj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWxhemFuc2tpLXNtYXJ0LXVzZXJzLWludGVybmV0Lwo+PiBIdG1saXplZDog ICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxhemFuc2tpLXNtYXJ0LXVz ZXJzLWludGVybmV0LTAwCj4+IEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWxhemFuc2tpLXNtYXJ0LXVzZXJzLWludGVybmV0Cj4+Cj4+ IEFic3RyYWN0Ogo+PiAgIFJGQyAzNTUyIGludHJvZHVjZXMgYSB0aHJlYXQgbW9kZWwgdGhhdCBk b2VzIG5vdCBpbmNsdWRlIGVuZHBvaW50Cj4+ICAgc2VjdXJpdHkuIEluIHRoZSBmaWZ0ZWVuIHll YXJzIHNpbmNlIFJGQyAzNTUyIHNlY3VyaXR5IGlzc3VlcyBhbmQKPj4gICBjeWJlciBhdHRhY2tz IGhhdmUgaW5jcmVhc2VkLCBlc3BlY2lhbGx5IG9uIHRoZSBlbmRwb2ludC4gVGhpcwo+PiAgIGRv Y3VtZW50IHByb3Bvc2VzIGEgbmV3IGFwcHJvYWNoIHRvIEludGVybmV0IGN5YmVyIHNlY3VyaXR5 IHByb3RvY29sCj4+ICAgZGV2ZWxvcG1lbnQgdGhhdCBmb2N1c2VzIG9uIHRoZSB1c2VyIG9mIHRo ZSBJbnRlcm5ldCwgbmFtZWx5IHRob3NlCj4+ICAgd2hvIHVzZSB0aGUgZW5kcG9pbnQgYW5kIGFy ZSB0aGUgbW9zdCB2dWxuZXJhYmxlIHRvIGF0dGFja3MuCj4+IC0tCj4+IFNtYXJ0IG1haWxpbmcg bGlzdAo+PiBTbWFydEBpcnRmLm9yZwo+PiBodHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NtYXJ0 --b1_4ee483934c814a7546b5f65a04ac0a52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5MaWtld2lzZSwgSSByZWFkIHRoaXMgSS1EIGFuZCBpdCBwdXRzIHRoZSBmaW5nZXIgb24g dGhlIHJpZ2h0IG5lcnZlcy4gVGhhbmsgeW91IGZvciBwdXR0aW5nIHRoaXMgb25lIGluIHBsYWNl Ljxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkluZGVlZCBpdCBpcyB2ZXJ5IHN0cmFpZ2h0 Zm9yd2FyZCByZWFkJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBjbGFzcz0icHJvdG9u bWFpbF9zaWduYXR1cmVfYmxvY2siPjxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Js b2NrLXVzZXIgcHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2stZW1wdHkiPjxicj48L2Rpdj48ZGl2 IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay1wcm90b24iPlNlbnQgd2l0aCA8YSBo cmVmPSJodHRwczovL3Byb3Rvbm1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+UHJvdG9uTWFpbDwv YT4gU2VjdXJlIEVtYWlsLjxicj48L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PuKAkOKA kOKAkOKAkOKAkOKAkOKAkCBPcmlnaW5hbCBNZXNzYWdlIOKAkOKAkOKAkOKAkOKAkOKAkOKAkDxi cj48L2Rpdj48ZGl2PiBPbiBXZWRuZXNkYXkgMTAgSnVseSAyMDE5IDE3OjI5LCBCcmV0IEpvcmRh biAmbHQ7am9yZGFuLmlldGZAZ21haWwuY29tJmd0OyB3cm90ZTo8YnI+PC9kaXY+PGRpdj4gPGJy PjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJwcm90b25tYWlsX3F1b3RlIiB0eXBlPSJjaXRlIj48 ZGl2PkRvbWluaXF1ZSw8YnI+PC9kaXY+PGRpdiBjbGFzcz48YnI+PC9kaXY+PGRpdiBjbGFzcz5J IGhhdmUgcmVhZCBvdmVyIHlvdXIgZHJhZnQsIGFuZCBJIHRoaW5rIGl0IGhpZ2hsaWdodHMgc29t ZSB2ZXJ5IGtleSB0aGluZ3Mgd2UgYWxsIG5lZWQgdG8gbG9vayBhdCBhbmQgYWRkcmVzcy4gVGhh bmtzIGZvciBwdXR0aW5nIHRoZXNlIGlkZWFzIGRvd24gb24gcGFwZXIuICZuYnNwO0hvcGVmdWxs eSB0aGlzIEktRCBjYW4gaGVscCB1cyBhbGwgc3RhcnQgYSBicm9hZGVyIGRpc2N1c3Npb24gdG8g aW1wcm92ZSB0aGluZ3MuPGJyPjwvZGl2PjxkaXYgY2xhc3M+PGJyPjwvZGl2PjxkaXYgY2xhc3M+ U01BUlQgLyBTZWNEaXNwYXRjaCw8YnI+PC9kaXY+PGRpdiBjbGFzcz48YnI+PC9kaXY+PGRpdiBj bGFzcz5JZiB5b3UgaGF2ZSBub3QgeWV0IHJlYWQgdGhpcyBJLUQsIEkgd291bGQgZW5jb3VyYWdl IHlvdSB0byBsb29rIGF0IGl0LiAmbmJzcDtJdCBpcyBhIHZlcnkgZmFzdCByZWFkLiZuYnNwOzxi cj48L2Rpdj48ZGl2IGNsYXNzPjxkaXY+PGJyPjwvZGl2PjxkaXYgY2xhc3M+PGRpdiBzdHlsZT0i Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPjxk aXYgY2xhc3Mgc3R5bGU9Im9ycGhhbnM6IDI7IHdpZG93czogMjsgZm9udC12YXJpYW50LWxpZ2F0 dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsOyBmb250LXZhcmlh bnQtcG9zaXRpb246IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgLXdlYmtpdC10ZXh0LWRl Y29yYXRpb25zLWluLWVmZmVjdDogbm9uZTsiPjxzcGFuIHN0eWxlPSJib3JkZXItY29sbGFwc2U6 IHNlcGFyYXRlOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1l YXN0LWFzaWFuOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhl aWdodDogbm9ybWFsOyBib3JkZXItc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtZGVjb3JhdGlv bnMtaW4tZWZmZWN0OiBub25lOyI+VGhhbmtzLDwvc3Bhbj48YnI+PC9kaXY+PGRpdiBjbGFzcyBz dHlsZT0ib3JwaGFuczogMjsgd2lkb3dzOiAyOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlv bjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyAtd2Via2l0LXRleHQtZGVjb3JhdGlvbnMt aW4tZWZmZWN0OiBub25lOyI+PHNwYW4gc3R5bGU9ImJvcmRlci1jb2xsYXBzZTogc2VwYXJhdGU7 IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46 IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IHRleHQtYWxpZ246IC13ZWJraXQtYXV0bzsgYm9yZGVyLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LWRlY29yYXRpb25zLWluLWVmZmVjdDogbm9uZTsiPkJyZXQ8L3NwYW4+PGJyPjwvZGl2 PjxkaXYgY2xhc3Mgc3R5bGU9Im9ycGhhbnM6IDI7IHdpZG93czogMjsiPjxzcGFuIHN0eWxlPSJi b3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyB0ZXh0LWFsaWduOiAtd2Via2l0LWF1dG87IGJvcmRl ci1zcGFjaW5nOiAwcHg7Ij48c3BhbiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsg dGV4dC1hbGlnbjogLXdlYmtpdC1hdXRvOyBib3JkZXItc3BhY2luZzogMHB4OyI+PGRpdiBjbGFz cyBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+PHNwYW4gc3R5bGU9ImJvcmRlci1jb2xs YXBzZTogc2VwYXJhdGU7IHRleHQtYWxpZ246IC13ZWJraXQtYXV0bzsgYm9yZGVyLXNwYWNpbmc6 IDBweDsiPjxkaXYgY2xhc3Mgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1u YnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPjxzcGFuIHN0 eWxlPSJib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyB0ZXh0LWFsaWduOiAtd2Via2l0LWF1dG87 IGJvcmRlci1zcGFjaW5nOiAwcHg7Ij48ZGl2IGNsYXNzIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUt c3BhY2U7Ij48c3BhbiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgdGV4dC1hbGln bjogLXdlYmtpdC1hdXRvOyBib3JkZXItc3BhY2luZzogMHB4OyI+PGRpdiBjbGFzcz48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyZSwgVmVyZGFuYSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3 YzdjN2MiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFweCI+UEdQIEZpbmdlcnByaW50OiZuYnNw Ozwvc3Bhbj48L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFweCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmUsIFZlcmRhbmEiPjxzcGFuIHN0eWxlPSJjb2xvcjoj N2M3YzdjIj42M0I0IEZDNTMgNjgwQSA2QjdEIDE0NDcgJm5ic3A7RjJDMCA3NEY4IEFDQUUgNzQx NSAwMDUwPC9zcGFuPjwvc3Bhbj48L3NwYW4+PGJyPjwvZGl2PjxkaXYgY2xhc3Mgc3R5bGU9ImZv bnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5v cm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IC13ZWJraXQtdGV4dC1kZWNvcmF0aW9ucy1pbi1lZmZlY3Q6IG5vbmU7Ij48c3BhbiBzdHlsZT0i Y29sb3I6cmdiKDEyNCwgMTI0LCAxMjQpIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJy ZSwgVmVyZGFuYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4cHQiPiJXaXRob3V0IGNyeXB0b2dy YXBoeSB2aWh2IHZpdmMgY2UgeGhybnJ3LCBob3dldmVyLCB0aGUgb25seSB0aGluZyB0aGF0IGNh biBub3QgYmUgdW5zY3JhbWJsZWQgaXMgYW4gZWdnLiI8L3NwYW4+PC9zcGFuPjwvc3Bhbj48YnI+ PC9kaXY+PC9zcGFuPjwvZGl2Pjwvc3Bhbj48L2Rpdj48L3NwYW4+PC9kaXY+PC9zcGFuPjwvc3Bh bj48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiIGNsYXNzPjxkaXYgY2xhc3M+T24gSnVsIDgsIDIwMTksIGF0IDEyOjU0IFBNLCBEb21p bmlxdWUgTGF6YW5za2kgJmx0OzxhIGhyZWY9Im1haWx0bzpkbWxAbGFzdHByZXNzbGFiZWwuY29t IiBjbGFzcz5kbWxAbGFzdHByZXNzbGFiZWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXYgY2xhc3M+PGRpdiBkaXI9ImF1dG8iIGNsYXNzPjxkaXYgZGlyPSJs dHIiIGNsYXNzPjxzcGFuIGNsYXNzPjwvc3Bhbj48YnI+PC9kaXY+PGRpdiBkaXI9Imx0ciIgY2xh c3M+PGRpdiBkaXI9Imx0ciIgY2xhc3M+PHNwYW4gY2xhc3M+PC9zcGFuPjxicj48L2Rpdj48ZGl2 IGRpcj0ibHRyIiBjbGFzcz48ZGl2IGRpcj0ibHRyIiBjbGFzcz48c3BhbiBzdHlsZT0iYmFja2dy b3VuZC1jb2xvcjpyZ2JhKDI1NSwgMjU1LCAyNTUsIDApIj5Dcm9zcyBwb3N0aW5nIHRvIHRoaXMg bWFpbGluZyBsaXN0Ljwvc3Bhbj48YnI+PC9kaXY+PGRpdiBkaXI9Imx0ciIgY2xhc3M+PHNwYW4g c3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiYSgyNTUsIDI1NSwgMjU1LCAwKSI+PC9zcGFuPjxi cj48L2Rpdj48ZGl2IGRpcj0ibHRyIiBjbGFzcz48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjpyZ2JhKDI1NSwgMjU1LCAyNTUsIDApIj5Eb21pbmlxdWUmbmJzcDs8L3NwYW4+PGJyPjwvZGl2 PjxkaXYgZGlyPSJsdHIiIGNsYXNzPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYmEo MjU1LCAyNTUsIDI1NSwgMCkiPjxiciBjbGFzcz5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt bGF6YW5za2ktc21hcnQtdXNlcnMtaW50ZXJuZXQtMDAudHh0PGJyIGNsYXNzPmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRG9taW5pcXVlIExhemFuc2tpIGFuZCBwb3N0ZWQgdG8g dGhlPGJyIGNsYXNzPklFVEYgcmVwb3NpdG9yeS48YnIgY2xhc3M+PGJyIGNsYXNzPk5hbWU6ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWxhemFuc2tpLXNtYXJ0LXVzZXJzLWludGVy bmV0PGJyIGNsYXNzPlJldmlzaW9uOiAmbmJzcDsgJm5ic3A7MDA8YnIgY2xhc3M+VGl0bGU6ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0FuIEludGVybmV0IGZvciBVc2VycyBBZ2FpbjxiciBj bGFzcz5Eb2N1bWVudCBkYXRlOiAmbmJzcDsgJm5ic3A7MjAxOS0wNy0wODxiciBjbGFzcz5Hcm91 cDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyIGNs YXNzPlBhZ2VzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsxMjxiciBjbGFzcz5VUkw6ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1sYXphbnNraS1zbWFydC11c2Vycy1pbnRlcm5ldC0wMC50eHQiIGRpcj0ibHRyIiBjbGFzcz5o dHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGF6YW5za2ktc21hcnQt dXNlcnMtaW50ZXJuZXQtMDAudHh0PC9hPjxiciBjbGFzcz5TdGF0dXM6ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxhemFuc2tpLXNtYXJ0LXVzZXJzLWludGVybmV0LyIg ZGlyPSJsdHIiIGNsYXNzPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxh emFuc2tpLXNtYXJ0LXVzZXJzLWludGVybmV0LzwvYT48YnIgY2xhc3M+SHRtbGl6ZWQ6ICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1sYXphbnNraS1zbWFydC11c2Vycy1pbnRlcm5ldC0wMCIgZGlyPSJs dHIiIGNsYXNzPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sYXphbnNraS1zbWFy dC11c2Vycy1pbnRlcm5ldC0wMDwvYT48YnIgY2xhc3M+SHRtbGl6ZWQ6ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtbGF6YW5za2ktc21hcnQtdXNlcnMtaW50ZXJuZXQiIGRpcj0ibHRy IiBjbGFzcz5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxhemFu c2tpLXNtYXJ0LXVzZXJzLWludGVybmV0PC9hPjxiciBjbGFzcz48YnIgY2xhc3M+PGJyIGNsYXNz PkFic3RyYWN0OjxiciBjbGFzcz4mbmJzcDsmbmJzcDtSRkMgMzU1MiBpbnRyb2R1Y2VzIGEgdGhy ZWF0IG1vZGVsIHRoYXQgZG9lcyBub3QgaW5jbHVkZSBlbmRwb2ludDxiciBjbGFzcz4mbmJzcDsm bmJzcDtzZWN1cml0eS4gSW4gdGhlIGZpZnRlZW4geWVhcnMgc2luY2UgUkZDIDM1NTIgc2VjdXJp dHkgaXNzdWVzIGFuZDxiciBjbGFzcz4mbmJzcDsmbmJzcDtjeWJlciBhdHRhY2tzIGhhdmUgaW5j cmVhc2VkLCBlc3BlY2lhbGx5IG9uIHRoZSBlbmRwb2ludC4gVGhpczxiciBjbGFzcz4mbmJzcDsm bmJzcDtkb2N1bWVudCBwcm9wb3NlcyBhIG5ldyBhcHByb2FjaCB0byBJbnRlcm5ldCBjeWJlciBz ZWN1cml0eSBwcm90b2NvbDxiciBjbGFzcz4mbmJzcDsmbmJzcDtkZXZlbG9wbWVudCB0aGF0IGZv Y3VzZXMgb24gdGhlIHVzZXIgb2YgdGhlIEludGVybmV0LCBuYW1lbHkgdGhvc2U8YnIgY2xhc3M+ Jm5ic3A7Jm5ic3A7d2hvIHVzZSB0aGUgZW5kcG9pbnQgYW5kIGFyZSB0aGUgbW9zdCB2dWxuZXJh YmxlIHRvIGF0dGFja3MuJm5ic3A7PC9zcGFuPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxkaXY+ LS0gPGJyPjwvZGl2PjxkaXY+U21hcnQgbWFpbGluZyBsaXN0PGJyPjwvZGl2PjxkaXY+PGEgaHJl Zj0ibWFpbHRvOlNtYXJ0QGlydGYub3JnIiBjbGFzcz5TbWFydEBpcnRmLm9yZzwvYT48YnI+PC9k aXY+PGRpdj5odHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NtYXJ0PGJyPjwv ZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+ PC9kaXY+ --b1_4ee483934c814a7546b5f65a04ac0a52-- From nobody Thu Jul 11 18:23:01 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D20120086 for ; Thu, 11 Jul 2019 18:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.106 X-Spam-Level: X-Spam-Status: No, score=-0.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.247, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 b5xTQ13UvN6K for ; Thu, 11 Jul 2019 18:22:58 -0700 (PDT) Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) (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 E81E1120020 for ; Thu, 11 Jul 2019 18:22:57 -0700 (PDT) Received: by mail-oi1-f171.google.com with SMTP id l12so6080934oil.1 for ; Thu, 11 Jul 2019 18:22:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9ecN4iBbnw+hXvnaekRcOElqsxLz1fQ2oWQJsrPq18M=; b=PKFjFFbzAeZmIl1+X1sOG5UrntYPZQpRoEy/s63f4TEkAztzY7jGVMUK+1lyRheoR6 mUhME/6ON9NQSCAWSRnZIZ/Wx6ONt0d+tsUsAH2r+yMM/O3uf+QX07kr0pW8VBLnZD6Y g+KzgPNamLmQWgTsKj7+O4XT0J1+c8+/gY7aF7hTk4WtB3bcg2p+r9y1N4iLOkVfNmhv vwodvUfF+DtmTF8vPrXqMaoFCP2XQdEIq3nf8NEJGMwZZV+bNiO3q2/BdbJQS3A/WNje ODJYD+iY4gBlM7elryJenQb/x6eZJy/3N/jBUn55eOZh69dW/22jOPS0eNIve+9BbjzD hAog== X-Gm-Message-State: APjAAAWLvr31Q6WpgdfaR367vdEDcY4wvmHkZBkS4IJHSBJs5VeuSPe8 sV9fkhb3QBSClKhLYE5DftoNW9GO39Smh9DyUjU= X-Google-Smtp-Source: APXvYqwSaGw2w0yO6HOBAxpEI5oNV7ssmnCozEbk8aVj0/glzfzjJXgim5n2GMY4oL6hKJV+1AChPUTQ+XP6wxpakc0= X-Received: by 2002:aca:bfd4:: with SMTP id p203mr4533947oif.95.1562894576883; Thu, 11 Jul 2019 18:22:56 -0700 (PDT) MIME-Version: 1.0 References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> In-Reply-To: <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> From: Phillip Hallam-Baker Date: Thu, 11 Jul 2019 21:22:47 -0400 Message-ID: To: Bret Jordan Cc: Dominique Lazanski , smart@irtf.org, IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000139cb3058d71c04f" Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 01:23:00 -0000 --000000000000139cb3058d71c04f Content-Type: text/plain; charset="UTF-8" It is an interesting read. But I see a very important distinction that needs to be made between compromise of user end points and compromise of server end points. Most breaches that occur are when an enterprise is penetrated and the firewall is the first and last line of defense. So Percy the Pinhead clicks on a link in an email and six hours later the attacker has root privilege on the corporate server. This is not Percy's fault, the fault is that a single mistake by a single employee results in compromise of data Percy was never authorized to access. So right now we have systems where one compromise at any one of 10,000 endpoints results in a breach. Now lets consider using some 1980s style end to end cryptography. So that the ultra important recipe data is only available to the dozen members of group. This improves matters because we have reduced the points of compromise from 10,000 cooks and service staff to 12 trusted employees. That is a start but we are still vulnerable to a single end point compromise so lets apply threshold cryptography so members of group W only have one half of the decryption key, the other is on the server and both halves of the key are needed to perform decryption. In this scenario, we now require two separate compromises of two different end points. On Wed, Jul 10, 2019 at 11:29 AM Bret Jordan wrote: > Dominique, > > I have read over your draft, and I think it highlights some very key > things we all need to look at and address. Thanks for putting these ideas > down on paper. Hopefully this I-D can help us all start a broader > discussion to improve things. > > SMART / SecDispatch, > > If you have not yet read this I-D, I would encourage you to look at it. > It is a very fast read. > > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that > can not be unscrambled is an egg." > > On Jul 8, 2019, at 12:54 PM, Dominique Lazanski > wrote: > > Cross posting to this mailing list. > > Dominique > > A new version of I-D, draft-lazanski-smart-users-internet-00.txt > has been successfully submitted by Dominique Lazanski and posted to the > IETF repository. > > Name: draft-lazanski-smart-users-internet > Revision: 00 > Title: An Internet for Users Again > Document date: 2019-07-08 > Group: Individual Submission > Pages: 12 > URL: > https://www.ietf.org/internet-drafts/draft-lazanski-smart-users-internet-00.txt > Status: > https://datatracker.ietf.org/doc/draft-lazanski-smart-users-internet/ > Htmlized: > https://tools.ietf.org/html/draft-lazanski-smart-users-internet-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-lazanski-smart-users-internet > > > Abstract: > RFC 3552 introduces a threat model that does not include endpoint > security. In the fifteen years since RFC 3552 security issues and > cyber attacks have increased, especially on the endpoint. This > document proposes a new approach to Internet cyber security protocol > development that focuses on the user of the Internet, namely those > who use the endpoint and are the most vulnerable to attacks. > -- > Smart mailing list > Smart@irtf.org > https://www.irtf.org/mailman/listinfo/smart > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --000000000000139cb3058d71c04f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It = is an interesting read. But I see a very important distinction that needs t= o be made between compromise of user end points and compromise of server en= d points.

<= /div>
Most breaches t= hat occur are when an enterprise is penetrated and the firewall is the firs= t and last line of defense. So Percy the Pinhead clicks on a link in an ema= il and six hours later the attacker has root privilege on the corporate ser= ver. This is not Percy's fault, the fault is that a single mistake by a= single employee results in compromise of data Percy was never authorized t= o access.

<= /div>
So right now we= have systems where one compromise at any one of 10,000 endpoints results i= n a breach.=C2=A0

Now let= s consider using some 1980s style end to end cryptography. So that the ultr= a important recipe data is only available to the dozen members of group. Th= is improves matters because we have reduced the points of compromise from 1= 0,000 cooks and service staff to 12 trusted employees.

That is a start but we are still vulnerable t= o a single end point compromise so lets apply threshold cryptography so mem= bers of group W only have one half of the decryption key, the other is on t= he server and both halves of the key are needed to perform decryption. In t= his scenario, we now require two separate compromises of two different end = points.


On Wed, Jul 10, 2019 at 11:29 AM Bret Jordan <jordan.ietf@gmail.com> wrote:
Dominique,

I have read over your draft, and I thin= k it highlights some very key things we all need to look at and address. Th= anks for putting these ideas down on paper.=C2=A0 Hopefully this I-D can he= lp us all start a broader discussion to improve things.

SMART / SecDispatch,

If you have not yet rea= d this I-D, I would encourage you to look at it.=C2=A0 It is a very fast re= ad.=C2=A0

Thanks,
Bret
PGP Fingerprint:=C2=A063B4 FC53 680A 6B7D 1447 =C2=A0F2C0 74F8 ACAE 7415 0050
"With= out cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an egg."

On Jul 8, 2019, at 12:54 PM, Domini= que Lazanski <dml@lastpresslabel.com> wrote:

<= div dir=3D"ltr">
Cross posting to this mailing list.

Dominique= =C2=A0

A new version of I-D, draft-lazanski-smart-users-internet= -00.txt
has been successfully submitted by Dominique Lazanski and posted= to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-l= azanski-smart-users-internet
Revision: =C2=A0 =C2=A000
Title: =C2=A0 = =C2=A0 =C2=A0 =C2=A0An Internet for Users Again
Document date: =C2=A0 = =C2=A02019-07-08
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission=
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A012
URL: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-lazanski-smart-use= rs-internet-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0https://datatracker.ietf.org/= doc/draft-lazanski-smart-users-internet/
Htmlized: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0https://tools.ietf.o= rg/html/draft-lazanski-smart-users-internet-00
Htmlized: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0https:/= /datatracker.ietf.org/doc/html/draft-lazanski-smart-users-internet
<= br>
Abstract:
=C2=A0=C2=A0RFC 3552 introduces a threat model that doe= s not include endpoint
=C2=A0=C2=A0security. In the fifteen years since = RFC 3552 security issues and
=C2=A0=C2=A0cyber attacks have increased, e= specially on the endpoint. This
=C2=A0=C2=A0document proposes a new appr= oach to Internet cyber security protocol
=C2=A0=C2=A0development that fo= cuses on the user of the Internet, namely those
=C2=A0=C2=A0who use the = endpoint and are the most vulnerable to attacks.=C2=A0
--
Smart mailing list
Smart@irtf.org
https://www.irtf.org/mailman/listi= nfo/smart

_________________= ______________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--000000000000139cb3058d71c04f-- From nobody Fri Jul 12 09:05:05 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B807120140 for ; Fri, 12 Jul 2019 09:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Me_PnUZgoiRp for ; Fri, 12 Jul 2019 09:05:00 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 676D0120134 for ; Fri, 12 Jul 2019 09:05:00 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id b7so4981356pls.6 for ; Fri, 12 Jul 2019 09:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CJmvHHHj6oXs/IVdWWV/CQRvOj7BxTs3avEYx5Qu6CQ=; b=L4YlFgqixq3hiq8F+Qk1mkbM1JIyo69EDFCMy5W7wXTIqR2UMQ3jX6R6+gSJP74uuV cvCwBy4q6GFZLMdNL52cNzga2BvepohOzj3r9U91uTTkTO9viSP9OpSuzBFOmhxbq24F t1fpBURfLLfRA0AIWLzxmSJ3ej0gk/ZDN1D3a02d6I1cKxtv+bzcWXx5h+fxnTO0XrZK +tlExJjapPE9xwncWQ8Mba4AnmJWnjKunSsrvjRi26PAMcI0eZbw8FpE/Ib3izoxv73V G0YpIn/zpS8EXP1kjTRxzv1p578Xke4q0UYqTFAVc8XxTeNOMp1zftA26IfaAhKC40y9 YqgQ== 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=CJmvHHHj6oXs/IVdWWV/CQRvOj7BxTs3avEYx5Qu6CQ=; b=G/dliW1VJhzZgWTPfqRkLbiEOpRj96RlkOOfUYmSK2vF5Ww1fYImO2tEw54F3hT9IU yfjLn3bJWMgi2yCRc8UbkBk6W4putmpQrGRX7tbmCphGSKVpzJ/HMyAdszFavuhM6E1G 2QtNjhHoTQuH+Cju1DADv+OuGInRaVJt0thLLA93AC31A3MHY/3Xl3mnQ4127IsvNh6i Y/sQhMICyKdWq5SDUOAxZd2B4rxR0H5v0RQZRrAfvfSp7ONkTG5IDkpppEshyOtgSFwi SfPJ90qqNZGz01QZ5gjjovpMDQjZGAI4S+lCcZlyhsQ2zLAQTHVe5qdBxp6Hz4vWYa3c nzkA== X-Gm-Message-State: APjAAAV21D2I0VwW98ivZM8dpuwJrPiEM09674BK83VEsQNLdbdTQ/4z wsteYRCAkBWZLmz9pHMOPmM= X-Google-Smtp-Source: APXvYqxjfOLBSU8Qo3vAYo3xwytxMOTHp9omSTf1XyHqf8hpVNqtZCmB7I+LRntUnuXQKpqHJuEC1w== X-Received: by 2002:a17:902:28e9:: with SMTP id f96mr11839192plb.114.1562947499868; Fri, 12 Jul 2019 09:04:59 -0700 (PDT) Received: from ?IPv6:2605:a601:a990:4d00:515e:2123:8528:f4f5? ([2605:a601:a990:4d00:515e:2123:8528:f4f5]) by smtp.gmail.com with ESMTPSA id m4sm17770645pff.108.2019.07.12.09.04.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jul 2019 09:04:58 -0700 (PDT) From: Bret Jordan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3BBA3A5F-9FBC-4AFB-897F-6ACC2E24EF91" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 12 Jul 2019 10:04:55 -0600 In-Reply-To: Cc: Dominique Lazanski , smart@irtf.org, IETF SecDispatch To: Phillip Hallam-Baker References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 16:05:03 -0000 --Apple-Mail=_3BBA3A5F-9FBC-4AFB-897F-6ACC2E24EF91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Unfortunately I think you are misunderstanding the attack surface how = attacks can work and wrongfully assume how threat actors and intrusions = sets operate. It is not always about exfiltrating your super secret = =E2=80=9Crecipe" as you call it. So database encryption will not always = help you, nor will putting your database on a block chain. Yes, it can = reduce the attack surface or exposure of your data under legitimate use. = But once the server is compromised, the attacker can simply pull = decrypted information from memory. Or can continue to move laterally = through the organization and pull the data of endpoints that do have = access to the data. Further, the threat actor may not be interested in = exfiltrating the data at all. But may simply be interested in using = your =E2=80=9C1980s=E2=80=9D crypto as you call it to encrypt your = database with their own key. This attack is commonly called Ransomware.=20= The key point is that you can not patch your way into security. This is = a common misunderstand that many people have outside of operational = security. End points are always weak and highly vulnerable to attack. = It does not matter if they are end user devices, servers, IoT devices, = or components soldered in to SCADA systems. I would encourage you to look at the MITRE ATT&CK framework to better = understand how these attacks work and how threat actors can disrupt, = exfiltrate, and destroy a company.=20 We have to realize that the security model has changed since some of = these documents were written. Yes, pervasive monitoring of users on the = internet is a problem, but it is only 1 piece of a large pie of = problems. We in the IETF need to communicate better with operational = security, so that we can design solutions that hollistically help = improve security and not make one part better at the huge expense of = everything else.=20 Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Jul 11, 2019, at 7:22 PM, Phillip Hallam-Baker = wrote: >=20 > It is an interesting read. But I see a very important distinction that = needs to be made between compromise of user end points and compromise of = server end points. >=20 > Most breaches that occur are when an enterprise is penetrated and the = firewall is the first and last line of defense. So Percy the Pinhead = clicks on a link in an email and six hours later the attacker has root = privilege on the corporate server. This is not Percy's fault, the fault = is that a single mistake by a single employee results in compromise of = data Percy was never authorized to access. >=20 > So right now we have systems where one compromise at any one of 10,000 = endpoints results in a breach.=20 >=20 > Now lets consider using some 1980s style end to end cryptography. So = that the ultra important recipe data is only available to the dozen = members of group. This improves matters because we have reduced the = points of compromise from 10,000 cooks and service staff to 12 trusted = employees. >=20 > That is a start but we are still vulnerable to a single end point = compromise so lets apply threshold cryptography so members of group W = only have one half of the decryption key, the other is on the server and = both halves of the key are needed to perform decryption. In this = scenario, we now require two separate compromises of two different end = points. >=20 >=20 > On Wed, Jul 10, 2019 at 11:29 AM Bret Jordan > wrote: > Dominique, >=20 > I have read over your draft, and I think it highlights some very key = things we all need to look at and address. Thanks for putting these = ideas down on paper. Hopefully this I-D can help us all start a broader = discussion to improve things. >=20 > SMART / SecDispatch, >=20 > If you have not yet read this I-D, I would encourage you to look at = it. It is a very fast read.=20 >=20 > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can not be unscrambled is an egg." >=20 >> On Jul 8, 2019, at 12:54 PM, Dominique Lazanski = > wrote: >>=20 >> Cross posting to this mailing list. >>=20 >> Dominique=20 >>=20 >> A new version of I-D, draft-lazanski-smart-users-internet-00.txt >> has been successfully submitted by Dominique Lazanski and posted to = the >> IETF repository. >>=20 >> Name: draft-lazanski-smart-users-internet >> Revision: 00 >> Title: An Internet for Users Again >> Document date: 2019-07-08 >> Group: Individual Submission >> Pages: 12 >> URL: = https://www.ietf.org/internet-drafts/draft-lazanski-smart-users-internet-0= 0.txt = >> Status: = https://datatracker.ietf.org/doc/draft-lazanski-smart-users-internet/ = >> Htmlized: = https://tools.ietf.org/html/draft-lazanski-smart-users-internet-00 = >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-lazanski-smart-users-internet = >>=20 >>=20 >> Abstract: >> RFC 3552 introduces a threat model that does not include endpoint >> security. In the fifteen years since RFC 3552 security issues and >> cyber attacks have increased, especially on the endpoint. This >> document proposes a new approach to Internet cyber security = protocol >> development that focuses on the user of the Internet, namely those >> who use the endpoint and are the most vulnerable to attacks.=20 >> --=20 >> Smart mailing list >> Smart@irtf.org >> https://www.irtf.org/mailman/listinfo/smart = >=20 > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch = --Apple-Mail=_3BBA3A5F-9FBC-4AFB-897F-6ACC2E24EF91 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Unfortunately I think you are misunderstanding the attack = surface how attacks can work and wrongfully assume how threat actors and = intrusions sets operate.  It is not always about exfiltrating your = super secret =E2=80=9Crecipe" as you call it.  So database = encryption will not always help you, nor will putting your database on a = block chain. Yes, it can reduce the attack surface or exposure of your = data under legitimate use. But once the server is compromised, the = attacker can simply pull decrypted information from memory. Or can = continue to move laterally through the organization and pull the data of = endpoints that do have access to the data.  Further, the threat = actor may not be interested in exfiltrating the data at all.  But = may simply be interested in using your =E2=80=9C1980s=E2=80=9D crypto as = you call it to encrypt your database with their own key.  This = attack is commonly called Ransomware. 

The key point is that = you can not patch your way into security.  This is a common = misunderstand that many people have outside of operational security. =  End points are always weak and highly vulnerable to attack. =  It does not matter if they are end user devices, servers, IoT = devices, or components soldered in to SCADA systems.

I would encourage you to = look at the MITRE ATT&CK framework to better understand how these = attacks work and how threat actors can disrupt, exfiltrate, and destroy = a company. 

We have to realize that the security model has changed since = some of these documents were written. Yes, pervasive monitoring of users = on the internet is a problem, but it is only 1 piece of a large pie of = problems.  We in the IETF need to communicate better with = operational security, so that we can design solutions that hollistically = help improve security and not make one part better at the huge expense = of everything else. 



Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Jul 11, 2019, at 7:22 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

It is = an interesting read. But I see a very important distinction that needs = to be made between compromise of user end points and compromise of = server end points.

Most breaches that = occur are when an enterprise is penetrated and the firewall is the first = and last line of defense. So Percy the Pinhead clicks on a link in an = email and six hours later the attacker has root privilege on the = corporate server. This is not Percy's fault, the fault is that a single = mistake by a single employee results in compromise of data Percy was = never authorized to access.

So right now we have = systems where one compromise at any one of 10,000 endpoints results in a = breach. 

Now lets consider = using some 1980s style end to end cryptography. So that the ultra = important recipe data is only available to the dozen members of group. = This improves matters because we have reduced the points of compromise = from 10,000 cooks and service staff to 12 trusted employees.

That is a start but we are still vulnerable to = a single end point compromise so lets apply threshold cryptography so = members of group W only have one half of the decryption key, the other = is on the server and both halves of the key are needed to perform = decryption. In this scenario, we now require two separate compromises of = two different end points.


On Wed, Jul = 10, 2019 at 11:29 AM Bret Jordan <jordan.ietf@gmail.com> wrote:
Dominique,

I have read over your draft, and I = think it highlights some very key things we all need to look at and = address. Thanks for putting these ideas down on paper.  Hopefully = this I-D can help us all start a broader discussion to improve = things.

SMART = / SecDispatch,

If you have not yet read this I-D, I would encourage you to = look at it.  It is a very fast read. 

Thanks,=
Bret
PGP = Fingerprint: 63B4 FC53 680A = 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce = xhrnrw, however, the only thing that can not be unscrambled is an = egg."

On Jul 8, 2019, at 12:54 PM, Dominique Lazanski <dml@lastpresslabel.com> wrote:

Cross posting = to this mailing list.

Dominique 

A= new version of I-D, draft-lazanski-smart-users-internet-00.txt
has been successfully submitted by Dominique Lazanski and = posted to the
IETF repository.

Name:       =  draft-lazanski-smart-users-internet
Revision:   =  00
Title:        An Internet for = Users Again
Document date:    2019-07-08
Group:        Individual Submission
Pages:        12
URL: =            https://www.ietf.org/internet-drafts/draft-lazanski-smart-users= -internet-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-lazanski-smart-users-int= ernet/
Htmlized: =       https://tools.ietf.org/html/draft-lazanski-smart-users-internet= -00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-lazanski-smart-user= s-internet


Abstract:
  RFC 3552 introduces a threat model that does not = include endpoint
  security. In the fifteen = years since RFC 3552 security issues and
  cyber = attacks have increased, especially on the endpoint. This
  document proposes a new approach to Internet = cyber security protocol
  development that = focuses on the user of the Internet, namely those
  who use the endpoint and are the most vulnerable = to attacks. 
--
Smart mailing list
Smart@irtf.org
https://www.irtf.org/mailman/listinfo/smart

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch

= --Apple-Mail=_3BBA3A5F-9FBC-4AFB-897F-6ACC2E24EF91-- From nobody Fri Jul 12 11:40:56 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B056212083C for ; Fri, 12 Jul 2019 11:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.106 X-Spam-Level: X-Spam-Status: No, score=-0.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.247, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 apFTP3vZ6FrD for ; Fri, 12 Jul 2019 11:40:52 -0700 (PDT) Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) (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 70A93120499 for ; Fri, 12 Jul 2019 11:40:52 -0700 (PDT) Received: by mail-oi1-f169.google.com with SMTP id a127so8018102oii.2 for ; Fri, 12 Jul 2019 11:40:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=goZ1W/qUS37NwsTXBe/YvFKXHRR+lVSncml/c9V2Nlo=; b=UvQV/c3lS48pAzRDRwQpp35Om9jhrzmI0pfyjTtuolE5T9y1A14wyRjCQF6srvqrCY YPF9MuV7/ryiLGM9P6Bq/F2CHt1/APlsdWgTgOa2kI6G+FohjhsEioIf5QLd27A1ynxY uReG8jhyYVLveRHHwU5WTu5NkEsrNcVHazbhjO0XBDBMk3eyDnOomX4X8OIknzwiUEju 35s6JOaWb0gzfAN2HeXKhlj1SqvH7lOrMKwGYJqinDAfRefF9pRVrRDM56NMr0YQXx4t DaJp3nrHvFHZFmLf4ZHDISDsrVneUakM72guajCqwxTakUm6TXNiJMdaODf8/tuV0T5H oxuw== X-Gm-Message-State: APjAAAX4TDIEyTxJHbp+llBQ9pxlXAfMdXhWBBU3XE0y56E93Liv1JA6 TiHNRYYjz/jcmTpl6fF4h0DdyajlMcvTQ4rrZWg= X-Google-Smtp-Source: APXvYqx7KmhYZP3A03w7CURLbAzcKecxz6smevOmxbomgClUROWJUIgH0d0UoMKZ/nsiSf1QhbTtAwtGHF77QM5xNx4= X-Received: by 2002:aca:4255:: with SMTP id p82mr6983694oia.6.1562956851260; Fri, 12 Jul 2019 11:40:51 -0700 (PDT) MIME-Version: 1.0 References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> In-Reply-To: From: Phillip Hallam-Baker Date: Fri, 12 Jul 2019 14:40:39 -0400 Message-ID: To: Bret Jordan Cc: Dominique Lazanski , smart@irtf.org, IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000eb32a8058d803f84" Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 18:40:56 -0000 --000000000000eb32a8058d803f84 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Applied properly, the cloud service never has anything but encrypted data and a pile of random numbers. Mesh group encryption is genuinely end to end. There is never plaintext on the server. The server never has sufficient information to decrypt. Assuming only that the random numbers used to split keys are unguessable, the system is information theroretic secure with respect to the requirement for two keys to be used to decrypt. There will always be an endpoint vulnerability in that data has to be decrypted to present it to the user, edit it, etc. But reducing the attack surface from every server and every endpoint in the enterprise to the dozen or so endpoints with a need to know the information is powerful. I have not considered the ransomware issue in depth because the solution is pretty obvious - take backups, verify the ability to recover at regular intervals. That said, obvious solutions can be very complex to deploy. This is actually one of the very few applications that Blockchain or at least the Haber-Stornetta hash chain could help us with. A DARE container is an append only log with optional Merkle Tree integrity checking. So we can do a continuous backup to a write only storage array behind a very very simple and limited firewall that only allows the backup requests through. If the online system is compromized, we recover from the firewalled, write-only array. Getting to that point in the mesh is likely to take five years. But Microsoft owns GitHub. And Git could at least in theory be extended to provide some of this functionality. Alternatively, bring down the BitCoin infrastructure by auditing Tether and the payment infrastrastructure that makes ransomware profitable would be gone. On Fri, Jul 12, 2019 at 12:05 PM Bret Jordan wrote: > Unfortunately I think you are misunderstanding the attack surface how > attacks can work and wrongfully assume how threat actors and intrusions > sets operate. It is not always about exfiltrating your super secret > =E2=80=9Crecipe" as you call it. So database encryption will not always = help you, > nor will putting your database on a block chain. Yes, it can reduce the > attack surface or exposure of your data under legitimate use. But once th= e > server is compromised, the attacker can simply pull decrypted information > from memory. Or can continue to move laterally through the organization a= nd > pull the data of endpoints that do have access to the data. Further, the > threat actor may not be interested in exfiltrating the data at all. But > may simply be interested in using your =E2=80=9C1980s=E2=80=9D crypto as = you call it to > encrypt your database with their own key. This attack is commonly called > Ransomware. > > The key point is that you can not patch your way into security. This is = a > common misunderstand that many people have outside of operational > security. End points are always weak and highly vulnerable to attack. I= t > does not matter if they are end user devices, servers, IoT devices, or > components soldered in to SCADA systems. > > I would encourage you to look at the MITRE ATT&CK framework to better > understand how these attacks work and how threat actors can disrupt, > exfiltrate, and destroy a company. > > We have to realize that the security model has changed since some of thes= e > documents were written. Yes, pervasive monitoring of users on the interne= t > is a problem, but it is only 1 piece of a large pie of problems. We in t= he > IETF need to communicate better with operational security, so that we can > design solutions that hollistically help improve security and not make on= e > part better at the huge expense of everything else. > > > > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that > can not be unscrambled is an egg." > > On Jul 11, 2019, at 7:22 PM, Phillip Hallam-Baker > wrote: > > It is an interesting read. But I see a very important distinction that > needs to be made between compromise of user end points and compromise of > server end points. > > Most breaches that occur are when an enterprise is penetrated and the > firewall is the first and last line of defense. So Percy the Pinhead clic= ks > on a link in an email and six hours later the attacker has root privilege > on the corporate server. This is not Percy's fault, the fault is that a > single mistake by a single employee results in compromise of data Percy w= as > never authorized to access. > > So right now we have systems where one compromise at any one of 10,000 > endpoints results in a breach. > > Now lets consider using some 1980s style end to end cryptography. So that > the ultra important recipe data is only available to the dozen members of > group. This improves matters because we have reduced the points of > compromise from 10,000 cooks and service staff to 12 trusted employees. > > That is a start but we are still vulnerable to a single end point > compromise so lets apply threshold cryptography so members of group W onl= y > have one half of the decryption key, the other is on the server and both > halves of the key are needed to perform decryption. In this scenario, we > now require two separate compromises of two different end points. > > > On Wed, Jul 10, 2019 at 11:29 AM Bret Jordan > wrote: > >> Dominique, >> >> I have read over your draft, and I think it highlights some very key >> things we all need to look at and address. Thanks for putting these idea= s >> down on paper. Hopefully this I-D can help us all start a broader >> discussion to improve things. >> >> SMART / SecDispatch, >> >> If you have not yet read this I-D, I would encourage you to look at it. >> It is a very fast read. >> >> Thanks, >> Bret >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that >> can not be unscrambled is an egg." >> >> On Jul 8, 2019, at 12:54 PM, Dominique Lazanski >> wrote: >> >> Cross posting to this mailing list. >> >> Dominique >> >> A new version of I-D, draft-lazanski-smart-users-internet-00.txt >> has been successfully submitted by Dominique Lazanski and posted to the >> IETF repository. >> >> Name: draft-lazanski-smart-users-internet >> Revision: 00 >> Title: An Internet for Users Again >> Document date: 2019-07-08 >> Group: Individual Submission >> Pages: 12 >> URL: >> https://www.ietf.org/internet-drafts/draft-lazanski-smart-users-internet= -00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-lazanski-smart-users-internet/ >> Htmlized: >> https://tools.ietf.org/html/draft-lazanski-smart-users-internet-00 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-lazanski-smart-users-interne= t >> >> >> Abstract: >> RFC 3552 introduces a threat model that does not include endpoint >> security. In the fifteen years since RFC 3552 security issues and >> cyber attacks have increased, especially on the endpoint. This >> document proposes a new approach to Internet cyber security protocol >> development that focuses on the user of the Internet, namely those >> who use the endpoint and are the most vulnerable to attacks. >> -- >> Smart mailing list >> Smart@irtf.org >> https://www.irtf.org/mailman/listinfo/smart >> >> >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch >> > > --000000000000eb32a8058d803f84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Applied properly, the cloud service never has anything but en= crypted data and a pile of random numbers.

Mesh group encryption is genuinely end to end. There is n= ever plaintext on the server. The server never has sufficient information t= o decrypt. Assuming only that the random numbers used to split keys are ung= uessable, the system is information theroretic secure with respect to the r= equirement for two keys to be used to decrypt.

There will always be an endpoint vulnerability in tha= t data has to be decrypted to present it to the user, edit it, etc. But red= ucing the attack surface from every server and every endpoint in the enterp= rise to the dozen or so endpoints with a need to know the information is po= werful.


I have not considered the r= ansomware issue in depth because the solution is pretty obvious - take back= ups, verify the ability to recover at regular intervals. That said, obvious= solutions can be very complex to deploy.

This is actually one of the very few applications that Blo= ckchain or at least the Haber-Stornetta hash chain could help us with. A DA= RE container is an append only log with optional Merkle Tree integrity chec= king. So we can do a continuous backup to a write only storage array behind= a very very simple and limited firewall that only allows the backup reques= ts through. If the online system is compromized, we recover from the firewa= lled, write-only array.=C2=A0

Getting to that point in the mesh is likely to take five years. But Mi= crosoft owns GitHub. And Git could at least in theory be extended to provid= e some of this functionality.=C2=A0

Alternatively, bring down the BitCoin infrastructure by auditing= Tether and the payment infrastrastructure that makes ransomware profitable= would be gone.

On Fri, Jul 12, 2019 at 12:05 PM Bret Jordan <jordan.ietf@gmail.com> wrote:
Unfortunately I think you are misunderstanding the = attack surface how attacks can work and wrongfully assume how threat actors= and intrusions sets operate.=C2=A0 It is not always about exfiltrating you= r super secret =E2=80=9Crecipe" as you call it.=C2=A0 So database encr= yption will not always help you, nor will putting your database on a block = chain. Yes, it can reduce the attack surface or exposure of your data under= legitimate use. But once the server is compromised, the attacker can simpl= y pull decrypted information from memory. Or can continue to move laterally= through the organization and pull the data of endpoints that do have acces= s to the data.=C2=A0 Further, the threat actor may not be interested in exf= iltrating the data at all.=C2=A0 But may simply be interested in using your= =E2=80=9C1980s=E2=80=9D crypto as you call it to encrypt your database wit= h their own key.=C2=A0 This attack is commonly called Ransomware.=C2=A0

The key point is that you can not patch your way into = security.=C2=A0 This is a common misunderstand that many people have outsid= e of operational security.=C2=A0 End points are always weak and highly vuln= erable to attack.=C2=A0 It does not matter if they are end user devices, se= rvers, IoT devices, or components soldered in to SCADA systems.
<= br>
I would encourage you to look at the MITRE ATT&CK framewo= rk to better understand how these attacks work and how threat actors can di= srupt, exfiltrate, and destroy a company.=C2=A0

We= have to realize that the security model has changed since some of these do= cuments were written. Yes, pervasive monitoring of users on the internet is= a problem, but it is only 1 piece of a large pie of problems.=C2=A0 We in = the IETF need to communicate better with operational security, so that we c= an design solutions that hollistically help improve security and not make o= ne part better at the huge expense of everything else.=C2=A0



Thanks,
Bret
PGP Fingerprint:=C2=A063B4 FC53 680A 6B7D 1447 =C2=A0F2C0 74F8 ACAE 7415 0050
"With= out cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an egg."

On Jul 11, 2019, at 7:22 PM, Philli= p Hallam-Baker <phill@hallambaker.com> wrote:

It is an interesting read. But I see a very important distin= ction that needs to be made between compromise of user end points and compr= omise of server end points.

<= div style=3D"font-size:small">Most breaches that occur are when an enterpri= se is penetrated and the firewall is the first and last line of defense. So= Percy the Pinhead clicks on a link in an email and six hours later the att= acker has root privilege on the corporate server. This is not Percy's f= ault, the fault is that a single mistake by a single employee results in co= mpromise of data Percy was never authorized to access.

So right now we ha= ve systems where one compromise at any one of 10,000 endpoints results in a= breach.=C2=A0

Now lets consider using some 1980s style end to end crypto= graphy. So that the ultra important recipe data is only available to the do= zen members of group. This improves matters because we have reduced the poi= nts of compromise from 10,000 cooks and service staff to 12 trusted employe= es.

That is a start but we are still vulnerable to a single end point com= promise so lets apply threshold cryptography so members of group W only hav= e one half of the decryption key, the other is on the server and both halve= s of the key are needed to perform decryption. In this scenario, we now req= uire two separate compromises of two different end points.


On Wed, Jul 10, 2019 at 11:29 AM Bret Jordan= <jordan.ietf= @gmail.com> wrote:
Dominique,

I have read over your draft, = and I think it highlights some very key things we all need to look at and a= ddress. Thanks for putting these ideas down on paper.=C2=A0 Hopefully this = I-D can help us all start a broader discussion to improve things.

SMART / SecDispatch,

If you have n= ot yet read this I-D, I would encourage you to look at it.=C2=A0 It is a ve= ry fast read.=C2=A0

Thanks,
Bret
<= div>
PGP Fingerprint:=C2=A063B4 FC53 680A 6B7D 1447 =C2=A0F2C0 74F8 ACAE 7415 0050
"Without cryptograp= hy vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled= is an egg."

On Jul 8, 2019, at 12:54 PM, Domini= que Lazanski <dml@lastpresslabel.com> wrote:

Cross posting to this mailing lis= t.

Dominique=C2=A0

A new version of I-D, draf= t-lazanski-smart-users-internet-00.txt
has been successfully submitted b= y Dominique Lazanski and posted to the
IETF repository.

Name: =C2= =A0 =C2=A0 =C2=A0 =C2=A0draft-lazanski-smart-users-internet
Revision: = =C2=A0 =C2=A000
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0An Internet for Users = Again
Document date: =C2=A0 =C2=A02019-07-08
Group: =C2=A0 =C2=A0 =C2= =A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A012
= URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-dr= afts/draft-lazanski-smart-users-internet-00.txt
Status: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ht= tps://datatracker.ietf.org/doc/draft-lazanski-smart-users-internet/
= Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-lazanski-smart-users-internet-00=
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/html/draft-lazanski-smart-= users-internet


Abstract:
=C2=A0=C2=A0RFC 3552 introduces = a threat model that does not include endpoint
=C2=A0=C2=A0security. In t= he fifteen years since RFC 3552 security issues and
=C2=A0=C2=A0cyber at= tacks have increased, especially on the endpoint. This
=C2=A0=C2=A0docum= ent proposes a new approach to Internet cyber security protocol
=C2=A0= =C2=A0development that focuses on the user of the Internet, namely those=C2=A0=C2=A0who use the endpoint and are the most vulnerable to attacks.= =C2=A0
--
Smart mailing list
Smart@irtf.org
https:/= /www.irtf.org/mailman/listinfo/smart

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

--000000000000eb32a8058d803f84-- From nobody Fri Jul 12 12:35:27 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5260C1207E2 for ; Fri, 12 Jul 2019 12:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 D_sW9XhjsUDJ for ; Fri, 12 Jul 2019 12:35:19 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 001A3120225 for ; Fri, 12 Jul 2019 12:35:18 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id s7so22776082iob.11 for ; Fri, 12 Jul 2019 12:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rcCf+HKztI7RKsv3xBlzdYYEYg+efvgziHZSRXMnbHI=; b=JWxDnh4SuK1PXW4KNPIISb2tedASI3NXgkqN1XK7g974f0Oa31/KeekhijbIpTrRAQ t4r+GfW3uPy6UA4C998EqnmdeOkua+gbQ8fJbWlsifFo/vBAq5VNeqArOOwb0+wGhdPd 8j7T+mdydefpmGdbpjJiOiZ2AB377FzSi/YvrCCkuEDcOlrkA5LxA3+i7SDzQkIsUkZO Lz6x6c7Qs/K9jV1xKKr8VRt4v+kgEsPLEMMZy/xPRMBZYM3L65J7ThWOrMCqp2QVZ4Hz snuABRNO2r+ju3KEwEP+TJfF9ELB0J8nY8ZYioQmprEVvcjIE4mMUIxhCKRe0+UbmRIu to/A== 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=rcCf+HKztI7RKsv3xBlzdYYEYg+efvgziHZSRXMnbHI=; b=r2Ppncx4fwSEO8elUlrkfzdNl2aS+gZInuv7K+tCs6xx50zJEhz+sIwnr1Lj1pxKgv HfarfuwlYc/3qvE6f3zkhhYGltVS1D+BmnJNJeeIWXYuT5Wmuy6oEkQRV/pliSr+zBTP k/pdiBgCzFDFpQbVS4KVCHGAOjrzwtNjymvl+QZfSmRZZSITmGpQSJpvtL2yvw7g9j63 rLuTPvsdTQiITACDJzdHyQQdgOJ7gImjPSWzWsVnin6J7L7j6Sfj7hfbDmGrh3NBRiuX 7Lln4kOhIWFKtSpoE6gaTwB4bII/uiMaguYSP/sJKHPXlUfWspkHQJaKDGYKrIId/Jts FMPA== X-Gm-Message-State: APjAAAWPDWhf98KUVFN5FGHEVbn9ZsS6evNCldZjqde1+txvfvjOu6gF YR7k8kKlUAdljz/8HMSWUMQ= X-Google-Smtp-Source: APXvYqwY09xhsVf2tXvz5PxFefSjSLcvXXnldQEJr3a3KyfVhhW0wVa2fS4XKP43sV/aSfsegUpMWA== X-Received: by 2002:a5d:8447:: with SMTP id w7mr13042274ior.197.1562960117875; Fri, 12 Jul 2019 12:35:17 -0700 (PDT) Received: from [172.16.255.50] ([216.194.115.4]) by smtp.gmail.com with ESMTPSA id m10sm14192957ioj.75.2019.07.12.12.35.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jul 2019 12:35:17 -0700 (PDT) From: Bret Jordan Message-Id: <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_90501082-AB5D-4DF4-805A-9DEDFBF6DDA9" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 12 Jul 2019 13:35:10 -0600 In-Reply-To: Cc: Dominique Lazanski , smart@irtf.org, IETF SecDispatch To: Phillip Hallam-Baker References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 19:35:24 -0000 --Apple-Mail=_90501082-AB5D-4DF4-805A-9DEDFBF6DDA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As with all things crypto, block-chain, quantum, cloud, and snake-oil, = they are not ubiquitously deployable across the entire eco-system of end = users, applications, enterprises, and governments. You say that this = can all be fixed in 5-years, I think you are off by an order of = magnitude. =20 Some organizations are still running Windows XP, some parts of critical = infrastructure still have very old soldered in equipment. Some critical = applications and resources needed for regulatory compliance can take = months to years to even get patched. What about cost optimized IoT = devices that can never run any security software or have no plans of = ever being updated? What about direct to telco connections with 5G = enabled devices? We still can not even patch end devices reliability = without a risk of bricking them. =20 The problem is not just about protecting data base data. Yes, this is = one piece in the entire security pie. But it is not the only part. = Trying to distill things down to say that it is, gives a false sense of = security. Just like the hyperbole and dogma that if your connection is = perfectly encrypted and free from external tracking, it is secure and = safe. Threat actors including CDNs and services providers can still = compromise the end user, end device, data, and track all of their where = about and everything they do. The attack surface and needs of end users and enterprises are much more = extensive than a single point solution. Yes, I have looked at your = proposed Mesh network. It is very neat, and very cool. I would love to = work with you on it. I see many places it can potentially be used. But = thinking that in 5 years everyone is going to forklift the entire = Internet and go with your solution and single solution is not realistic. This is the problem with the IETF as a whole. Too few understand = day-2-day operational security. This is one thing that SMART really = needs to help with. We need to start a bunch of discussions and get a = bunch of research done to help every aspect of the IETF. We need to = invite people from FIRST and other industry groups to help with this = effort. =20 Some think that SMART is a tiny amount of work. But SMART could be one = of the most important pieces of work that the IETF / IRTF does in the = next 10 years.=20 =20 Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Jul 12, 2019, at 12:40 PM, Phillip Hallam-Baker = wrote: >=20 > Applied properly, the cloud service never has anything but encrypted = data and a pile of random numbers. >=20 > Mesh group encryption is genuinely end to end. There is never = plaintext on the server. The server never has sufficient information to = decrypt. Assuming only that the random numbers used to split keys are = unguessable, the system is information theroretic secure with respect to = the requirement for two keys to be used to decrypt. >=20 > There will always be an endpoint vulnerability in that data has to be = decrypted to present it to the user, edit it, etc. But reducing the = attack surface from every server and every endpoint in the enterprise to = the dozen or so endpoints with a need to know the information is = powerful. >=20 >=20 > I have not considered the ransomware issue in depth because the = solution is pretty obvious - take backups, verify the ability to recover = at regular intervals. That said, obvious solutions can be very complex = to deploy. >=20 > This is actually one of the very few applications that Blockchain or = at least the Haber-Stornetta hash chain could help us with. A DARE = container is an append only log with optional Merkle Tree integrity = checking. So we can do a continuous backup to a write only storage array = behind a very very simple and limited firewall that only allows the = backup requests through. If the online system is compromized, we recover = from the firewalled, write-only array.=20 >=20 > Getting to that point in the mesh is likely to take five years. But = Microsoft owns GitHub. And Git could at least in theory be extended to = provide some of this functionality.=20 >=20 > Alternatively, bring down the BitCoin infrastructure by auditing = Tether and the payment infrastrastructure that makes ransomware = profitable would be gone. >=20 > On Fri, Jul 12, 2019 at 12:05 PM Bret Jordan > wrote: > Unfortunately I think you are misunderstanding the attack surface how = attacks can work and wrongfully assume how threat actors and intrusions = sets operate. It is not always about exfiltrating your super secret = =E2=80=9Crecipe" as you call it. So database encryption will not always = help you, nor will putting your database on a block chain. Yes, it can = reduce the attack surface or exposure of your data under legitimate use. = But once the server is compromised, the attacker can simply pull = decrypted information from memory. Or can continue to move laterally = through the organization and pull the data of endpoints that do have = access to the data. Further, the threat actor may not be interested in = exfiltrating the data at all. But may simply be interested in using = your =E2=80=9C1980s=E2=80=9D crypto as you call it to encrypt your = database with their own key. This attack is commonly called Ransomware.=20= >=20 > The key point is that you can not patch your way into security. This = is a common misunderstand that many people have outside of operational = security. End points are always weak and highly vulnerable to attack. = It does not matter if they are end user devices, servers, IoT devices, = or components soldered in to SCADA systems. >=20 > I would encourage you to look at the MITRE ATT&CK framework to better = understand how these attacks work and how threat actors can disrupt, = exfiltrate, and destroy a company.=20 >=20 > We have to realize that the security model has changed since some of = these documents were written. Yes, pervasive monitoring of users on the = internet is a problem, but it is only 1 piece of a large pie of = problems. We in the IETF need to communicate better with operational = security, so that we can design solutions that hollistically help = improve security and not make one part better at the huge expense of = everything else.=20 >=20 >=20 >=20 > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can not be unscrambled is an egg." >=20 >> On Jul 11, 2019, at 7:22 PM, Phillip Hallam-Baker = > wrote: >>=20 >> It is an interesting read. But I see a very important distinction = that needs to be made between compromise of user end points and = compromise of server end points. >>=20 >> Most breaches that occur are when an enterprise is penetrated and the = firewall is the first and last line of defense. So Percy the Pinhead = clicks on a link in an email and six hours later the attacker has root = privilege on the corporate server. This is not Percy's fault, the fault = is that a single mistake by a single employee results in compromise of = data Percy was never authorized to access. >>=20 >> So right now we have systems where one compromise at any one of = 10,000 endpoints results in a breach.=20 >>=20 >> Now lets consider using some 1980s style end to end cryptography. So = that the ultra important recipe data is only available to the dozen = members of group. This improves matters because we have reduced the = points of compromise from 10,000 cooks and service staff to 12 trusted = employees. >>=20 >> That is a start but we are still vulnerable to a single end point = compromise so lets apply threshold cryptography so members of group W = only have one half of the decryption key, the other is on the server and = both halves of the key are needed to perform decryption. In this = scenario, we now require two separate compromises of two different end = points. >>=20 >>=20 >> On Wed, Jul 10, 2019 at 11:29 AM Bret Jordan > wrote: >> Dominique, >>=20 >> I have read over your draft, and I think it highlights some very key = things we all need to look at and address. Thanks for putting these = ideas down on paper. Hopefully this I-D can help us all start a broader = discussion to improve things. >>=20 >> SMART / SecDispatch, >>=20 >> If you have not yet read this I-D, I would encourage you to look at = it. It is a very fast read.=20 >>=20 >> Thanks, >> Bret >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can not be unscrambled is an egg." >>=20 >>> On Jul 8, 2019, at 12:54 PM, Dominique Lazanski = > wrote: >>>=20 >>> Cross posting to this mailing list. >>>=20 >>> Dominique=20 >>>=20 >>> A new version of I-D, draft-lazanski-smart-users-internet-00.txt >>> has been successfully submitted by Dominique Lazanski and posted to = the >>> IETF repository. >>>=20 >>> Name: draft-lazanski-smart-users-internet >>> Revision: 00 >>> Title: An Internet for Users Again >>> Document date: 2019-07-08 >>> Group: Individual Submission >>> Pages: 12 >>> URL: = https://www.ietf.org/internet-drafts/draft-lazanski-smart-users-internet-0= 0.txt = >>> Status: = https://datatracker.ietf.org/doc/draft-lazanski-smart-users-internet/ = >>> Htmlized: = https://tools.ietf.org/html/draft-lazanski-smart-users-internet-00 = >>> Htmlized: = https://datatracker.ietf.org/doc/html/draft-lazanski-smart-users-internet = >>>=20 >>>=20 >>> Abstract: >>> RFC 3552 introduces a threat model that does not include endpoint >>> security. In the fifteen years since RFC 3552 security issues and >>> cyber attacks have increased, especially on the endpoint. This >>> document proposes a new approach to Internet cyber security = protocol >>> development that focuses on the user of the Internet, namely those >>> who use the endpoint and are the most vulnerable to attacks.=20 >>> --=20 >>> Smart mailing list >>> Smart@irtf.org >>> https://www.irtf.org/mailman/listinfo/smart = >>=20 >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch = >=20 --Apple-Mail=_90501082-AB5D-4DF4-805A-9DEDFBF6DDA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As = with all things crypto, block-chain, quantum, cloud, and snake-oil, they = are not ubiquitously deployable across the entire eco-system of end = users, applications, enterprises, and governments.  You say that = this can all be fixed in 5-years, I think you are off by an order of = magnitude.  

Some= organizations are still running Windows XP, some parts of critical = infrastructure still have very old soldered in equipment.  Some = critical applications and resources needed for regulatory compliance can = take months to years to even get patched. What about cost optimized IoT = devices that can never run any security software or have no plans of = ever being updated?  What about direct to telco connections with 5G = enabled devices? We still can not even patch end devices reliability = without a risk of bricking them.  

The problem is not just about = protecting data base data.  Yes, this is one piece in the entire = security pie.  But it is not the only part.  Trying to distill = things down to say that it is, gives a false sense of security. =  Just like the hyperbole and dogma that if your connection is = perfectly encrypted and free from external tracking, it is secure and = safe. Threat actors including CDNs and services providers can still = compromise the end user, end device, data, and track all of their where = about and everything they do.

The attack surface and needs of end = users and enterprises are much more extensive than a single point = solution.  Yes, I have looked at your proposed Mesh network. It is = very neat, and very cool.  I would love to work with you on it. =  I see many places it can potentially be used.  But thinking = that in 5 years everyone is going to forklift the entire Internet and go = with your solution and single solution is not realistic.

This is = the problem with the IETF as a whole.  Too few understand day-2-day = operational security.  This is one thing that SMART really needs to = help with.  We need to start a bunch of discussions and get a bunch = of research done to help every aspect of the IETF.  We need to = invite people from FIRST and other industry groups to help with this = effort.  

Some think that SMART is a tiny amount of work.  But = SMART could be one of the most important pieces of work that the IETF / = IRTF does in the next 10 years. 


 
Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Jul 12, 2019, at 12:40 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

Applied properly, the cloud service never has = anything but encrypted data and a pile of random numbers.

Mesh group encryption is genuinely end to end. = There is never plaintext on the server. The server never has sufficient = information to decrypt. Assuming only that the random numbers used to = split keys are unguessable, the system is information theroretic secure = with respect to the requirement for two keys to be used to = decrypt.

There will always be an endpoint vulnerability = in that data has to be decrypted to present it to the user, edit it, = etc. But reducing the attack surface from every server and every = endpoint in the enterprise to the dozen or so endpoints with a need to = know the information is powerful.


I = have not considered the ransomware issue in depth because the solution = is pretty obvious - take backups, verify the ability to recover at = regular intervals. That said, obvious solutions can be very complex to = deploy.

This is actually one of the very few = applications that Blockchain or at least the Haber-Stornetta hash chain = could help us with. A DARE container is an append only log with optional = Merkle Tree integrity checking. So we can do a continuous backup to a = write only storage array behind a very very simple and limited firewall = that only allows the backup requests through. If the online system is = compromized, we recover from the firewalled, write-only = array. 

Getting to that point = in the mesh is likely to take five years. But Microsoft owns GitHub. And = Git could at least in theory be extended to provide some of this = functionality. 

Alternatively, bring = down the BitCoin infrastructure by auditing Tether and the payment = infrastrastructure that makes ransomware profitable would be = gone.

On Fri, Jul 12, 2019 at 12:05 PM Bret = Jordan <jordan.ietf@gmail.com> wrote:
Unfortunately I think you are misunderstanding = the attack surface how attacks can work and wrongfully assume how threat = actors and intrusions sets operate.  It is not always about = exfiltrating your super secret =E2=80=9Crecipe" as you call it.  So = database encryption will not always help you, nor will putting your = database on a block chain. Yes, it can reduce the attack surface or = exposure of your data under legitimate use. But once the server is = compromised, the attacker can simply pull decrypted information from = memory. Or can continue to move laterally through the organization and = pull the data of endpoints that do have access to the data.  = Further, the threat actor may not be interested in exfiltrating the data = at all.  But may simply be interested in using your =E2=80=9C1980s=E2= =80=9D crypto as you call it to encrypt your database with their own = key.  This attack is commonly called Ransomware. 

The key = point is that you can not patch your way into security.  This is a = common misunderstand that many people have outside of operational = security.  End points are always weak and highly vulnerable to = attack.  It does not matter if they are end user devices, servers, = IoT devices, or components soldered in to SCADA systems.

I would encourage you to = look at the MITRE ATT&CK framework to better understand how these = attacks work and how threat actors can disrupt, exfiltrate, and destroy = a company. 

We have to realize that the security model has changed since = some of these documents were written. Yes, pervasive monitoring of users = on the internet is a problem, but it is only 1 piece of a large pie of = problems.  We in the IETF need to communicate better with = operational security, so that we can design solutions that hollistically = help improve security and not make one part better at the huge expense = of everything else. 



Thanks,=
Bret
PGP = Fingerprint: 63B4 FC53 680A = 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce = xhrnrw, however, the only thing that can not be unscrambled is an = egg."

On Jul 11, 2019, at 7:22 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

It is an interesting read. But I see a very important = distinction that needs to be made between compromise of user end points = and compromise of server end points.

Most breaches that occur are when an enterprise is penetrated = and the firewall is the first and last line of defense. So Percy the = Pinhead clicks on a link in an email and six hours later the attacker = has root privilege on the corporate server. This is not Percy's fault, = the fault is that a single mistake by a single employee results in = compromise of data Percy was never authorized to access.

So right now we have systems where = one compromise at any one of 10,000 endpoints results in a = breach. 

Now lets = consider using some 1980s style end to end cryptography. So that the = ultra important recipe data is only available to the dozen members of = group. This improves matters because we have reduced the points of = compromise from 10,000 cooks and service staff to 12 trusted = employees.

That is a = start but we are still vulnerable to a single end point compromise so = lets apply threshold cryptography so members of group W only have one = half of the decryption key, the other is on the server and both halves = of the key are needed to perform decryption. In this scenario, we now = require two separate compromises of two different end points.


On Wed, Jul 10, 2019 at 11:29 AM Bret Jordan <jordan.ietf@gmail.com> wrote:
Dominique,

I have read over your = draft, and I think it highlights some very key things we all need to = look at and address. Thanks for putting these ideas down on paper.  = Hopefully this I-D can help us all start a broader discussion to improve = things.

SMART = / SecDispatch,

If you have not yet read this I-D, I would encourage you to = look at it.  It is a very fast read. 

Thanks,=
Bret
PGP = Fingerprint: 63B4 FC53 680A = 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce = xhrnrw, however, the only thing that can not be unscrambled is an = egg."

On Jul 8, 2019, at 12:54 PM, Dominique Lazanski <dml@lastpresslabel.com> wrote:

Cross posting = to this mailing list.

Dominique 

A= new version of I-D, draft-lazanski-smart-users-internet-00.txt
has been successfully submitted by Dominique Lazanski and = posted to the
IETF repository.

Name:       =  draft-lazanski-smart-users-internet
Revision:   =  00
Title:        An Internet for = Users Again
Document date:    2019-07-08
Group:        Individual Submission
Pages:        12
URL: =            https://www.ietf.org/internet-drafts/draft-lazanski-smart-users= -internet-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-lazanski-smart-users-int= ernet/
Htmlized: =       https://tools.ietf.org/html/draft-lazanski-smart-users-internet= -00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-lazanski-smart-user= s-internet


Abstract:
  RFC 3552 introduces a threat model that does not = include endpoint
  security. In the fifteen = years since RFC 3552 security issues and
  cyber = attacks have increased, especially on the endpoint. This
  document proposes a new approach to Internet = cyber security protocol
  development that = focuses on the user of the Internet, namely those
  who use the endpoint and are the most vulnerable = to attacks. 
--
Smart mailing list
Smart@irtf.org
https://www.irtf.org/mailman/listinfo/smart

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch


= --Apple-Mail=_90501082-AB5D-4DF4-805A-9DEDFBF6DDA9-- From nobody Sat Jul 13 19:07:22 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D858120071 for ; Sat, 13 Jul 2019 19:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GVjyN-L3QKY for ; Sat, 13 Jul 2019 19:07:18 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 1FC9312006F for ; Sat, 13 Jul 2019 19:07:18 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id 66so268010oth.7 for ; Sat, 13 Jul 2019 19:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mEZp7X4OuIA0tRChvK/Iq6BBGVxq+m4r/lH7sEp8AXk=; b=lyQsQ7eBDmt8diMHOGqnWgaUzh7GxUgs3S5CBIKaDqUz4jx+xzaQkJC1wIOzEH+nYm Qx4Ndr/mLWCjTehl1DPk4yUJle5eVYDYq+wYjP17xAcVuccJAUyY3XErTBn36bYw3UYA DHCJ+29EK+gOkBW/0z0G6sqkuLykZsvrsYxNf94M22PafPqpmazjQqtNTTOofLNeBUW7 tBopFewvw7tSmh5fjp57jU+Wq5JpCLw2fdCds0zpepPGdMm/xjmLVD8OX1phcj0HiWTd iPdvPlO6MAtX41yOPl3Wah9sCzlHuJDchqQW5Ho/Lor3ysFIsg5hSxkdcMlRgptA9IEl NiMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mEZp7X4OuIA0tRChvK/Iq6BBGVxq+m4r/lH7sEp8AXk=; b=WJLY/Nih3iPNNhk05Tg9bnJqq+TiJlu5GNRrw7NV9Qb4g5VRis0uZE3yLkMJWbIY3+ V7T5FNb0UM8/VIESiL4hdfimp1sHPZHBGvR0lh4f8w8J6krvP8JHKZnyneETgn2KjSJn ps+vnTKdUpG+8dOcK4NtnIyWDnWaJtgupWzOeltZE8VB6kW06YDp1ZzmoxQxAlSf/fzU ryLTC2W9IC7TpwzwBe7QB9BJOeGeQiDC0FmRw90r8R3LEbIl7t9grxWGp4FSfF/CrPX7 9D0f5/nJd7aABlUBXT03R0LsAubf5AZuDg2gRBhHAuMZ3oSU9Xd4QgYWEzFoAG8vFlwQ aJHA== X-Gm-Message-State: APjAAAUec/cBA0fctVNbsw5EIMz7jWpExBIwJPBNJ/YlTWmy2pFm1hWj K5Yhr16FfBIowuAXfKoSRUIZ1WsLcPxUjtLTuRQdelMo X-Google-Smtp-Source: APXvYqyCL9XIQUtZHksCv7melyD/YUezsTw8nl8E4TZ+xmMjoutJNkFZCdUR8cQrF+i99H81Rr92uOzR5pkwFv84VV0= X-Received: by 2002:a9d:76ce:: with SMTP id p14mr4586130otl.342.1563070037366; Sat, 13 Jul 2019 19:07:17 -0700 (PDT) MIME-Version: 1.0 References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> In-Reply-To: <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> From: Kathleen Moriarty Date: Sat, 13 Jul 2019 22:06:58 -0400 Message-ID: To: Dominique Lazanski Cc: smart@irtf.org, IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000561c80058d9a9a54" Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 02:07:20 -0000 --000000000000561c80058d9a9a54 Content-Type: text/plain; charset="UTF-8" Dominique, Thank you for your work on this draft. It's a good start toward broadening the conversation on the Internet threat model and I do agree that is necessary. The other recent threat model drafts don't cover the points raised, but none of the three threat model drafts cover all threats. I'm not sure if there are other threat model drafts I have missed as well. I like the focus, but think as the draft goes on, broadening the scope to look at the full threat model would be very helpful towards something the IETF participants might buy into (I could be wrong here, but this is what I suspect). We can't look solely at the end point as the IETF is concerned mostly with on-the-wire protocols. In some RFCs, there are clear requirements on end point security, but this is not particularly common. It would be good to see the sort of changes proposed added into a revision of 3552 in my opinion. However, we do need to think about surveillance and other threats too. One of DKG's points from a panel at RSA was that boxes that intercept traffic and are capable of decrypting that traffic is a target rich environment. I agree with that point. We are in a tough spot as crypto has become stronger, but the endpoints have not become more secure or even capable of detecting the threats that were blocked in-the-middle previously. I think adding this point into your draft would be helpful as we (as a community) rethink the threat model. I'd be very happy to discuss this further. Also - is this a request to present at SecDispatch? Thank you, Kathleen Sorry for the top-post, but I was not responding the the thread besides Dominique's initial message. >>> On Jul 8, 2019, at 12:54 PM, Dominique Lazanski >>> wrote: >>> >>> Cross posting to this mailing list. >>> >>> Dominique >>> >>> A new version of I-D, draft-lazanski-smart-users-internet-00.txt >>> has been successfully submitted by Dominique Lazanski and posted to the >>> IETF repository. >>> >>> Name: draft-lazanski-smart-users-internet >>> Revision: 00 >>> Title: An Internet for Users Again >>> Document date: 2019-07-08 >>> Group: Individual Submission >>> Pages: 12 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-lazanski-smart-users-internet-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-lazanski-smart-users-internet/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-lazanski-smart-users-internet-00 >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-lazanski-smart-users-internet >>> >>> >>> Abstract: >>> RFC 3552 introduces a threat model that does not include endpoint >>> security. In the fifteen years since RFC 3552 security issues and >>> cyber attacks have increased, especially on the endpoint. This >>> document proposes a new approach to Internet cyber security protocol >>> development that focuses on the user of the Internet, namely those >>> who use the endpoint and are the most vulnerable to attacks. >>> -- >>> Smart mailing list >>> Smart@irtf.org >>> https://www.irtf.org/mailman/listinfo/smart >>> >>> >>> _______________________________________________ >>> Secdispatch mailing list >>> Secdispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdispatch >>> >> >> > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > -- Best regards, Kathleen --000000000000561c80058d9a9a54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dominique,

Thank you f= or your work on this draft.=C2=A0 It's a good start toward broadening t= he conversation on the Internet threat model and I do agree that is necessa= ry.=C2=A0=C2=A0

The other recent threat model draf= ts don't cover the points raised, but none of the three threat model dr= afts cover all threats. I'm not sure if there are other threat model dr= afts I have missed as well.=C2=A0=C2=A0

I like the= focus, but think as the draft goes on, broadening the scope to look at the= full threat model would be very helpful towards something the IETF partici= pants might buy into (I could be wrong here, but this is what I suspect).= =C2=A0 We can't look solely at the end point as the IETF is concerned m= ostly with on-the-wire protocols.=C2=A0 In some RFCs, there are clear requi= rements on end point security, but this is not particularly common.=C2=A0 I= t would be good to see the sort of changes proposed added into a revision o= f 3552 in my opinion.=C2=A0 However, we do need to think about surveillance= and other threats too.=C2=A0 One of DKG's points from a panel at RSA w= as that boxes that intercept traffic and are capable of decrypting that tra= ffic is a target rich environment.=C2=A0 I agree with that point.=C2=A0=C2= =A0

We are in a tough spot as crypto has become st= ronger, but the endpoints have not become more secure or even capable of de= tecting the threats that were blocked in-the-middle previously.=C2=A0 I thi= nk adding this point into your draft would be helpful as we (as a community= ) rethink the threat model.

I'd be very happy = to discuss this further.

Also - is this a request = to present at SecDispatch?

Thank you,
Ka= thleen

Sorry for the top-post, but I was not respo= nding the the thread besides Dominique's initial message.

<= div>On Jul 8, 2019, at 12:54 PM, Dominique Lazanski <dml@lastpresslabel.com> wro= te:

Cross posting to this mailing list.

=
Dominique=C2=A0

A new version of I-D, draft-lazanski-sma= rt-users-internet-00.txt
has been successfully submitted by Dominique La= zanski and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2= =A0 =C2=A0draft-lazanski-smart-users-internet
Revision: =C2=A0 =C2=A000<= br>Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0An Internet for Users Again
Documen= t date: =C2=A0 =C2=A02019-07-08
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0Indivi= dual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A012
URL: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-laz= anski-smart-users-internet-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0https://datatr= acker.ietf.org/doc/draft-lazanski-smart-users-internet/
Htmlized: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https= ://tools.ietf.org/html/draft-lazanski-smart-users-internet-00
Htmliz= ed: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/html/draft-lazanski-smart-users-inte= rnet


Abstract:
=C2=A0=C2=A0RFC 3552 introduces a threat m= odel that does not include endpoint
=C2=A0=C2=A0security. In the fifteen= years since RFC 3552 security issues and
=C2=A0=C2=A0cyber attacks have= increased, especially on the endpoint. This
=C2=A0=C2=A0document propos= es a new approach to Internet cyber security protocol
=C2=A0=C2=A0develo= pment that focuses on the user of the Internet, namely those
=C2=A0=C2= =A0who use the endpoint and are the most vulnerable to attacks.=C2=A0
--
Smart mailing list
Smart@irtf.org
https://www.irtf.or= g/mailman/listinfo/smart

__= _____________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch


________________= _______________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch


--

Best regards,
Kathleen
--000000000000561c80058d9a9a54-- From nobody Sat Jul 13 22:04:10 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7B21201CE for ; Sat, 13 Jul 2019 22:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=nomountain-net.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 kSob97NGW0Vm for ; Sat, 13 Jul 2019 22:04:06 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 61AB61201CD for ; Sat, 13 Jul 2019 22:04:06 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id y15so5987442pfn.5 for ; Sat, 13 Jul 2019 22:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=wHZs1neHPNQgnOi8BF4pU6jsZ5cuFdAKy2X94Gyb2Wg=; b=aIMCxyOpP7GiJKbAl+z5JYtwQfxupYluwOdixrW72KRp0a+Vygvxp4P4diCYxWw40U IA8zaJ25JzwAJNdsCZ+aOukP/1cOfhFu3qksq9qDaLFdX4DblM8ADnAt3Dow1WmWtF/o zrkzSBL4a91cxQNle+TsDGa1P4kypmLwgSis3G48EnbxQkGF7Z+5wQZQkW3LEjaWOOoK Rsfn93zdJccATs2pc052LaPsNrUZ8kjUrGja44lgoHv+aXzFtsZJzlTvEn/D7N/1MyQ4 CT12OExlqDPayZg+qAcdOx9wL0VvM+2j6H1n1IHuaCDkPqOFNWkhA+rXBL7g1+sasqNa r7TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=wHZs1neHPNQgnOi8BF4pU6jsZ5cuFdAKy2X94Gyb2Wg=; b=E3mhf3Ld/ZvLBax2t/HO1WiR40y6upK80zvtK4dkQIUZY8HKmPgySZyucF+Z7Puiyf btdLLGJZW3n9+p/Q9J+Sl0vs7JsWxnsJxom/mj2+sWm1c+hxjhaPvtooamO8pWAErhdu qQpBEFwuutEoh0X9ncaqNUg5ktsuHVurZ4xAH4kYApO/q1FF/DKWKsSauH4BCHxDglaq JyPUG+Wvp+ysX8UyfAouRVBLSS2S00rsoafCHi25tdxfGepVhEESSudfTa3lRL9uF5c5 1cOMLgW80HCKjIgG2fjF9jBL8fkE2dZd8+yH5RQraSlezMTEAMUxq3WmrdQGhe+opwVy Va3g== X-Gm-Message-State: APjAAAWxYmfIJQKcohUwPWWaIsrOxLgIiiX4Qq7gPUDtKYsoE4qKn8WP fqblq1njGriVkV07UaLWRst9aMs= X-Google-Smtp-Source: APXvYqxwEVKLePsGo3fiaPhWkZLiOr9zkcAnMhAtKVRKOJk6fY1VUB7Q+ltfAy1CV2RGTexELBl3Pg== X-Received: by 2002:a17:90a:360c:: with SMTP id s12mr22117298pjb.30.1563080645467; Sat, 13 Jul 2019 22:04:05 -0700 (PDT) Received: from aspen.local (63-140-64-252.dynamic.lte.acsalaska.net. [63.140.64.252]) by smtp.gmail.com with ESMTPSA id x24sm4542807pgl.84.2019.07.13.22.04.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Jul 2019 22:04:04 -0700 (PDT) To: secdispatch@ietf.org References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> From: Melinda Shore Openpgp: preference=signencrypt Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= mQINBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABtCxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PokCVAQTAQoAPgIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaXRaAAoJ EN+4kXKadtuPVioP/3nVzx33yjiEtqLKTEHwofnLT15CV5wAcGa0DTbqgiomVKzSRkkhbF3Z KIHYrnjVpTcYJuW+PmFSIjNizNVr+vvjNP6ptRqx5orWmK4EBe/B9mrpmIshxUwkYr46uwN4 h06xJS3KCzhfhSsnesH5vlGBkUod0+nQhbSLyLRpxmaKaeAl4dxFSBLU0vUJMLH8PXTZVNof 5Yo+ThqCzu1pwOkBQ8gST2J6zdy4PjU9ENQ9RLAamlAG/6rGHEKLFcnUpEg7Tcu1hSzAsqR8 kjX2Prpu4A9DyLCjTOvfOPQa8WjZy18ZdYOxuPxdrTazeCRVJIvYRflhBCZb744jhMyfAiSW eckwRBVSCnBuvWBJl9Ua1wp8SOUXXhgGI8WGvSkvul6kKSkHQKDggd4cojAhxWLfvmjxn5pz 0BNbvrEBGqgWwO1ZMuJpmv3P8YK5Aytsl85NZoMMUJIDxEQhBUgYz5QTQANBKPi8RsfOntho rhzXLqnPPQcE4Xf9O9XIyy077F0JoyiPx74Zsl1dTxmT73pezpfhKUQR7/QlmJ/FAADpb6SO V0tlgBtR6FAZToBYPDiss57AcKM1zzyJ7sHIZkxQelykYSet6hp2WGcwMXQveWqFMQ4fiGQx XNEPO+KZKNj+0sfINzSLP88O5TniM/l/JrjZZNT/lVAQDTdkCBGyuQINBFppZ0gBEACgZuM1 8ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1YZ0O pQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR35FAg SnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fEZHM6 6phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQV0yB gc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4cztv gmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRHRvQs 0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBjLtx1 tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI7qDH FxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnYjMJo dU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABiQI8BBgBCgAmFiEET2gtkyoXlvgg8jTA37iR cpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ75iY5 pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiFPjkr QIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/JYK75 BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApMLL0R /qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV5abZ +iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJRi+cH 7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7Vz9F +6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloSbbMv P9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjxuLzd LY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+31fk1 HKwqd9xRxC8= Message-ID: <45cc67f6-3dd4-9788-29e5-4cc82471e6ee@nomountain.net> Date: Sat, 13 Jul 2019 21:04:02 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1FWFfjFqZb8lyDN6GFQQx79bMexaWV3lX" Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 05:04:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1FWFfjFqZb8lyDN6GFQQx79bMexaWV3lX Content-Type: multipart/mixed; boundary="Y65nLqm4XcffcbE2zQNNIpCGNDWEX2pvc"; protected-headers="v1" From: Melinda Shore To: secdispatch@ietf.org Message-ID: <45cc67f6-3dd4-9788-29e5-4cc82471e6ee@nomountain.net> Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> In-Reply-To: --Y65nLqm4XcffcbE2zQNNIpCGNDWEX2pvc Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 7/13/19 6:06 PM, Kathleen Moriarty wrote: > Thank you for your work on this draft.=C2=A0 It's a good start toward > broadening the conversation on the Internet threat model and I do agree= > that is necessary.=C2=A0=C2=A0 I think this discussion is extremely useful and I generally agree with the bulk of the underlying assumptions, but I'm trying to understand what the IETF can do about some of the endpoint-related problems that are being called out. We typically deal with wireline protocols and their support structures, and I'm hoping that as the discussions progress people can be clear about what they'd like to see from the IETF. I do think that some of this may be appropriate for opsec, as well, or at least should be called to their attention. Melinda --=20 Melinda Shore melinda.shore@nomountain.net Software longa, hardware brevis --Y65nLqm4XcffcbE2zQNNIpCGNDWEX2pvc-- --1FWFfjFqZb8lyDN6GFQQx79bMexaWV3lX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEET2gtkyoXlvgg8jTA37iRcpp2248FAl0qt8IACgkQ37iRcpp2 24+EWA//ZfoPwEkGBbZA7j84rTwfMZn6lUTSQywYKItvwcS/mB3p1QiejTVnoPWs M+I6GqIXKlK2AuoXyMfrKyhr94PAlISbDcVn3q2ra00sebpjtDP3i2YwLncRLjej oW5aUFXc6wPI6o1JK6BH44aTEHRNp672CLJ/5u8TsQVuiSUtlykFgpvMTmfpsmeT einPf2YjAZMH2XOvqp0eK7MckZn0GLom6zcAx/KXsfp6BxgcZiRziV9oHW/w1hvk X+Tb9FBR4vtPRMExl+41SX9DJajfk2Bf//jrgChp8MnGpbU44iTQ7Nut+prDtyN0 2YAKYigiR5r3HIzev8eNhXsfLWsRAwGNQUe9RsfdXQZ4c4hX/fad9+TV5GFvWv8K fq7rXZ3x/7gTJOfCjsv5mkc08q4QzPgQ5MvHzsx986vNqzO63JXjsVi/dJaDegYy FshqnPoU454sq6HRnjg1rMUmTAuUhwwHuKgOydCl4KjfxVZ1UhcMMmtVSfwF8UFw w2387cGFlBEPaaDVFZwTNV1IJp9bG15kd37Ex6Ttks1qGBkg9W32IJ9m4sGoUn0m PyYcy0zo0o//zzcL1z/65VqrWTtkvYqSw5C1h00fELOAUbrahLseMEhZspSBHZeL XLChqbcSmuwByRWUrzniyWiZ21c90BKm3wLSYChSe5alOsv9RN4= =mMmN -----END PGP SIGNATURE----- --1FWFfjFqZb8lyDN6GFQQx79bMexaWV3lX-- From nobody Sun Jul 14 03:26:03 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7439B1200E5 for ; Sun, 14 Jul 2019 03:26:02 -0700 (PDT) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 UG1Vj1YvMuMt for ; Sun, 14 Jul 2019 03:26:00 -0700 (PDT) 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 671E7120077 for ; Sun, 14 Jul 2019 03:26:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1CAAABE8E; Sun, 14 Jul 2019 11:25:57 +0100 (IST) 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 GdlqFun7R9dp; Sun, 14 Jul 2019 11:25:55 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 591A1BE74; Sun, 14 Jul 2019 11:25:55 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1563099955; bh=mOJs+8kyg8UspA1bRCtycCb/UhoEfnh4lYGW+Iw48c0=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=2daMKA2MM69KWB+9XqF7tLhmLlzF/Rlu/n2KLbWIbIl9T/SEhKd+HGlSDKGH60s5F FYa+5RsbGspy24ePlSukf9UHJ+4KJq9S77k75bHeYIq/8Xea/sIFUFzjbtn1WYAcsK 5vyVxnpwLlYSKArgJr53wViAbQ0++s63cneyR8Bo= To: Kathleen Moriarty , Dominique Lazanski Cc: smart@irtf.org, IETF SecDispatch References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> Date: Sun, 14 Jul 2019 11:25:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QgICoCaUp6rwJl2ORSg1TCI8RCufLDZFn" Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 10:26:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QgICoCaUp6rwJl2ORSg1TCI8RCufLDZFn Content-Type: multipart/mixed; boundary="npKAnoI74Yu1zzMebyySxzwz9dNRcTY1Z"; protected-headers="v1" From: Stephen Farrell To: Kathleen Moriarty , Dominique Lazanski Cc: smart@irtf.org, IETF SecDispatch Message-ID: <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> In-Reply-To: --npKAnoI74Yu1zzMebyySxzwz9dNRcTY1Z Content-Type: multipart/mixed; boundary="------------C776B62FCA0CAE431ED621EC" Content-Language: en-GB This is a multi-part message in MIME format. --------------C776B62FCA0CAE431ED621EC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 14/07/2019 03:06, Kathleen Moriarty wrote: > It's a good start toward broadening > the conversation on the Internet threat model and I do agree that is > necessary. FWIW, I don't agree that this is a good start. ISTM that this draft is far too opinionated, for example claiming that "IETF attendees are privacy-focused", (how does the author know?), claiming it "unthinkable" that something isn't done, and that "Internet security research and technical development must accept the reality of all the security issues in the Internet ecosystem" (though I'm not sure I can parse that last quote at all). Towards the end we get: "Endpoints have changed over the last 10 years, but assumptions about endpoints in the IETF hasn't changed in that time" - I don't know how the author knows what assumptions may or may not be made by IETF participants (not "attendees" of course). And perhaps most oddly, this bold assertion: "Further, it is imperative that new conclusions and recommendations from a revisited threat model are backed up by research, case studies and experience - rather than bold assertions." ;-) The list of breaches and botnets is fine, but not much use without any analysis of how those happened. We need a good bit more work to figure out whether any changes to protocols or protocol design are actually warranted or useful in the face of these kinds of incident. (Hence the oddity of the bold assertion above.) Lastly, ISTM important, if any discussion here is to be worthwhile, to recognise from the start that existing IETF consensus positions in this space are not likely to be discarded - those were arrived at after a lot iterations of a lot of debate by well-informed IETF participants. (Despite what some may claim;-) So I reckon the right discussion to have is about how to extend and not discard the 3552 threat model. Any other attempted changes would seem to me to require a shift in deployments from 2-party to multi-party protocols, which is unrealistic, or to require magical trust in middleboxes, which would be plain silly and seems highly unlikely to be something for which IETF consensus would be established. > Also - is this a request to present at SecDispatch? I hope not. This draft is IMO clearly not ready for that. An initial discussion about threat models and how to approach this kind of work at saag may be worthwhile (and I think Jari has asked the sec ADs for such a slot). Cheers, S. --------------C776B62FCA0CAE431ED621EC Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------C776B62FCA0CAE431ED621EC-- --npKAnoI74Yu1zzMebyySxzwz9dNRcTY1Z-- --QgICoCaUp6rwJl2ORSg1TCI8RCufLDZFn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl0rAzIACgkQWrL68XsX K+pAjA//Ypxq3zBBcI+MJLSdJ8f9vyjEP6NoQqnMwaOzrFY7XLPtfGRusoHmMYML W6NjL5Y77QMnXFYKTe5/thqi4fT0tmpDB4NVx1X8UA7Axi7vWfJlDQqTeFWKCM0p z1HfLJSUQvjZbeowkceG5swEX6HKVsmabBp2PHmT0FWFnoK+KFSE39the2bxhHAN BG9OHIe3pfQzs0BlFB5vI44wtUzpmMZGJzmuinZmMJNnqYM9n3BazR6LxRLe3Vma 5IuKBB8QXU+H5d7H3UDkfXMcScVkCQwYZvlunU8oWm/FdPjZZXmiXR2vY9CybD5E g7Tb7FeuQkm60qR6ExC3imTJO/UJZ1KLBYiW2g/gqVtIsp8o26OOWJyouazVHJjv 37FNKUCYaQO9j/ufsYelWCs8Y8vHcntwNQU053gnaPnO4X1UJMgfZbXTIUmN27Gb Zc8MDc30tYoHTRDpgwSTCyJjm+HkHXWw8UnvFIL6nRLz9x3Z8bBzTzo593gh9PB1 QGlk98ZAzxPrqcaxD5wtOZTj/Qqr6mTSMs9XNNNaMz8xx7pklNTb4yp4dFc5wJqo zHnqn2D9j0dsN7MwYPUdcGqMnYOxRzWOsIwd7L1FJk+0KbCwrIU9mxoZQeIaFXfD dNCFYVCx0WsDvwdkCIS2ewsNzN9Jp/ZxZPTgp+ssxt2J46mIlro= =w+0e -----END PGP SIGNATURE----- --QgICoCaUp6rwJl2ORSg1TCI8RCufLDZFn-- From nobody Sun Jul 14 03:56:50 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCB5120112 for ; Sun, 14 Jul 2019 03:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 EwFRcVgu7Ov3 for ; Sun, 14 Jul 2019 03:56:46 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DAC21200F4 for ; Sun, 14 Jul 2019 03:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2181; q=dns/txt; s=iport; t=1563101806; x=1564311406; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Qy1uNuJ0VvrA5kYXKO0E1/I7mAElyaXZI+K4WsehfYU=; b=j3zGCYMN7aWqiFsRMkArsY/a5Gxc0afmOfTGqh8kxajC+jVco6BtgZXn vZeulXzott3XjSH7pmeG/G/kD9m+kGQR0mb+CWfvTzD1tH6s+ONxHMuvC 8dlqMjTiVMY0RIASxfgkFJ4GbikUfjIX3bASKApCs0kCgPre7d5V/I1tt c=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAAC3CStd/xbLJq1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAMBAQEBAQsBgWeBagEgEiiEHIh7i1IlmH2BewIHAQE?= =?us-ascii?q?BCQMBAS8BAYFLgnUCgnk1CA4BAwEBBAEBAgEFbYVIhUsBAgIBI1QCBQsLQgI?= =?us-ascii?q?CVwYTgyIBgXsPqgyBMoVHhGYQgTQBgVCHRYJggX+BOAwTgh4uPodOMoImBIh?= =?us-ascii?q?2i3uVcgmCG4IfgQyMHYREG403ilOheoMLAgQGBQIVgVEBNj6BGjMaCBsVZQG?= =?us-ascii?q?BWWg+gg8XFI4PPQMwkGkBAQ?= X-IronPort-AV: E=Sophos;i="5.63,490,1557187200"; d="asc'?scan'208";a="14227259" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jul 2019 10:56:44 +0000 Received: from [10.61.168.132] ([10.61.168.132]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x6EAuhD6004843 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 14 Jul 2019 10:56:44 GMT From: Eliot Lear Message-Id: <9683DFBC-1816-4C0A-8D8A-4CE36318C72C@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_6D0BD5DA-9587-42B6-9D45-CDA79154C6FD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 14 Jul 2019 12:56:42 +0200 In-Reply-To: <45cc67f6-3dd4-9788-29e5-4cc82471e6ee@nomountain.net> Cc: secdispatch@ietf.org To: Melinda Shore References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <45cc67f6-3dd4-9788-29e5-4cc82471e6ee@nomountain.net> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.168.132, [10.61.168.132] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 10:56:49 -0000 --Apple-Mail=_6D0BD5DA-9587-42B6-9D45-CDA79154C6FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Melinda, > We > typically deal with wireline protocols and their support > structures, and I'm hoping that as the discussions progress > people can be clear about what they'd like to see from the > IETF. I think you=E2=80=99re primarily referring to leaky user databases here. = I agree with you that we cannot fix organizations=E2=80=99 bad internal = code with a wireline protocol. However, to exploit the vulnerability, = the attack had to come from somewhere. We already have one mechanism to = address profiling with IoT that manufacturers can use to keep their = systems from being exploited as BoTs. The next question is whether we = should be promoting or improving other mechanisms to provide people at = home and elsewhere more visibility in terms of what their general = purpose computing devices are doing. I=E2=80=99m thinking of PCP in = particular. And while there may be more we can do, there may also be = some limitations relating not only to privacy but also economics of web = services. What I like about Dominique=E2=80=99s draft is that it gets us thinking = in those directions (or at least it did me). >=20 > I do think that some of this may be appropriate for opsec, > as well, or at least should be called to their attention. Or an RG or a side meeting. It would be fun to continue the discussion. Eliot >=20 > Melinda >=20 > -- > Melinda Shore > melinda.shore@nomountain.net >=20 > Software longa, hardware brevis >=20 >=20 >=20 --Apple-Mail=_6D0BD5DA-9587-42B6-9D45-CDA79154C6FD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXSsKagAKCRBugA9nE248 uBqhAKDZlADNN+Gu/k+SMRChzc30RdFXSQCgpzOv1crJqX6gTnsC0E6u9GQxIrU= =n4M3 -----END PGP SIGNATURE----- --Apple-Mail=_6D0BD5DA-9587-42B6-9D45-CDA79154C6FD-- From nobody Sun Jul 14 04:21:19 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98E61200F4 for ; Sun, 14 Jul 2019 04:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 hoENlIxhb7Lp for ; Sun, 14 Jul 2019 04:21:10 -0700 (PDT) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::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 5F972120105 for ; Sun, 14 Jul 2019 04:21:10 -0700 (PDT) Received: by mail-oi1-x22d.google.com with SMTP id u15so10640439oiv.0 for ; Sun, 14 Jul 2019 04:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cu0LCxwSqB5MKtKMQZp2e+AnAgoQFs5LfP1Nq4jusDI=; b=j32c4+fPZM1HgtUUmO4xhJiM4tZUTfsjjyx6h+vK2Hfcw4GHEXAdQoXGqiFJFXpfK4 i0UE2fD5I8xEohx+4hgWq7HXedRSGGRrYq9mWXh3trJscIEfSGAP8kT43xNYiyoxhTHA 4qFz20HiBIF/9lfObiD9K8Z32DtH+6dOd1q96zZ4nWdYF5mdfKoeAZTMsUQzLdoJ2uLi ioLf7QNnM7ppUActO7AqFWtEKGcKXtkn0/Dg22DfRSpxaZq0rMzt7a4U/82qiHKU64iE c3+1HnKdiF19LHaYPSX5aETvR0KPZSGDPkglvOqFzKRQbtiaTcF4gnOIcxLeP4LPAi9k juvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Cu0LCxwSqB5MKtKMQZp2e+AnAgoQFs5LfP1Nq4jusDI=; b=UiiMQfAiDI6JV9eyqe8fuk/owfTNauVOTYbAKccyV0B+OawlZ5VfZcbq2VMNiQvd7a BaNFrnW6uTG6r7KNLEWUhHHgg9uEOrIleuBJIHN4oNdD5lRUIZ+ODOvhgFy6x/h2rpYi 6NkJGcMpbDUM49URMrw5RIhUvyFNOPLPDwDk4fkpZ1OlFv0xeL/eoUKv/sSx0ubJ+sWF bzPlTinmwVvniH0x4l9JjPOG0jXXK97G5vZi8skbs85IMVcs7cAg69GK8+ntY/Gk9YW6 1blF96FAfkHnlISJZYHky0f42hgm5Xewnq8PSil/iFQKjKXPPM4Ep0JmUhJ1H5F45OQo HiVA== X-Gm-Message-State: APjAAAWcJ1wf4Qc3djD3QEEmv3wvsBlYbR5vnm45lhJUI/3q9PiJDLUh EK9z9vx/9C4gzDATQ6Px3H6Vzn+OvEeY0EWK6HI= X-Google-Smtp-Source: APXvYqx2GiHDWtK8GI/ZmvIHrW7+HGV2Q2M5uw5Aqb6oEEzh74L3wYdI2/NZhayMt6HLPLpglMPoICzuEt6Nhh2W7Lg= X-Received: by 2002:aca:5308:: with SMTP id h8mr9826835oib.164.1563103269644; Sun, 14 Jul 2019 04:21:09 -0700 (PDT) MIME-Version: 1.0 References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> In-Reply-To: <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> From: Kathleen Moriarty Date: Sun, 14 Jul 2019 07:20:33 -0400 Message-ID: To: Stephen Farrell Cc: Dominique Lazanski , smart@irtf.org, IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000226e8a058da25780" Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 11:21:14 -0000 --000000000000226e8a058da25780 Content-Type: text/plain; charset="UTF-8" Hello, On Sun, Jul 14, 2019 at 6:25 AM Stephen Farrell wrote: > > Hiya, > > On 14/07/2019 03:06, Kathleen Moriarty wrote: > > It's a good start toward broadening > > the conversation on the Internet threat model and I do agree that is > > necessary. > > FWIW, I don't agree that this is a good start. > > ISTM that this draft is far too opinionated, for example > claiming that "IETF attendees are privacy-focused", (how > does the author know?), claiming it "unthinkable" that > something isn't done, and that "Internet security research > and technical development must accept the reality of all > the security issues in the Internet ecosystem" (though > I'm not sure I can parse that last quote at all). > Sure, opinionated text gets cut as a draft progresses, but she makes a clear case for adding in the endpoint into the threat model. I had tried to do a bit of that in my AD reviews as I agree, it's one of the places systems are left vulnerable and open to attack. When the defenses in the middle are removed, new ones are needed. Protocol evolution is eliminating these middle boxes, so the end point needs to be shored up. We need first to better prevent attacks, and then to be able to detect them at end points. Some of this could get baked into protocols (I'm not sure how yet, but perhaps something can be done), requiring research and ensuring the protocols maintain the existing set of desired properties. > > Towards the end we get: "Endpoints have changed over the > last 10 years, but assumptions about endpoints in the IETF > hasn't changed in that time" - I don't know how the > author knows what assumptions may or may not be made > by IETF participants (not "attendees" of course). > Sure, there's a bunch of us that care about end points, but I think outside perception doesn't show this and those who work solely on end point security don't feel heard at the moment. Bake this into a bigger threat model and we have a more complete picture. We as a community need to step back and think about the threat model and impacts to users of the Internet. The time to detect an attack has come way down (in most countries) over the last 2 years. This isn't spelled out in the draft, but could be in a comprehensive draft. The reason for this is that organizations have deployed tighter controls and are quicker to detect anomalies on their networks. Detection devices have also aided in this reduction with the exchange of indicators of compromise. We need new ways to deploy prevention and detection mechanisms and can't ignore that as we eliminate the methods of detection and prevention used by large numbers of organizations. I'd be happy to help flesh out this part of the threat model more. > And perhaps most oddly, this bold assertion: "Further, it > is imperative that new conclusions and recommendations > from a revisited threat model are backed up by research, case > studies and experience - rather than bold assertions." ;-) > PM was backed by lots of information, I agree. The problem is that the focus ignored (largely) other security concerns. I tried to ensure system integrity came up when important in drafts and also logging, but maybe there's more that can and should be done. > > The list of breaches and botnets is fine, but not much > use without any analysis of how those happened. We need a > good bit more work to figure out whether any changes to > protocols or protocol design are actually warranted or > useful in the face of these kinds of incident. (Hence > the oddity of the bold assertion above.) > Yes, and these aren't the only types of attacks. Phishing is accountable for about 90% of so called APT attacks (I can find the artcile that says this, just not at the moment). Better authentication will help (FIDO, tokbind, HOBA, etc.) , but some of the attacks don't involve authentication. > > Lastly, ISTM important, if any discussion here is to > be worthwhile, to recognise from the start that existing > IETF consensus positions in this space are not likely to > be discarded - those were arrived at after a lot iterations > of a lot of debate by well-informed IETF participants. > (Despite what some may claim;-) So I reckon the right > discussion to have is about how to extend and not discard > the 3552 threat model. Any other attempted changes would > seem to me to require a shift in deployments from 2-party > to multi-party protocols, which is unrealistic, or to > require magical trust in middleboxes, which would be plain > silly and seems highly unlikely to be something for which > IETF consensus would be established. > Sure, my full message made the same point. We need to look at the broader threat model and have a more comprehensive picture. I do think this helps make the case for the end point and figuring out if we have options within protocols to prevent threat with out-of-the-box thinking, research, security protocol proofing, and testing. > > > Also - is this a request to present at SecDispatch? > > I hope not. This draft is IMO clearly not ready for that. > An initial discussion about threat models and how to > approach this kind of work at saag may be worthwhile (and > I think Jari has asked the sec ADs for such a slot). > She sent it to SecDispatch, so I needed to ask. I do agree it's better for SAAG and a larger discussion on threat model, but that's for our ADs to decide. > > Cheers, > S. > -- Best regards, Kathleen --000000000000226e8a058da25780 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

On Sun, Jul 14, 2019 at 6:25 AM= Stephen Farrell <stephen.f= arrell@cs.tcd.ie> wrote:

Hiya,

On 14/07/2019 03:06, Kathleen Moriarty wrote:
> It's a good start toward broadening
> the conversation on the Internet threat model and I do agree that is > necessary.

FWIW, I don't agree that this is a good start.

ISTM that this draft is far too opinionated, for example
claiming that "IETF attendees are privacy-focused", (how
does the author know?), claiming it "unthinkable" that
something isn't done, and that "Internet security research
and technical development must accept the reality of all
the security issues in the Internet ecosystem" (though
I'm not sure I can parse that last quote at all).
=
Sure, opinionated text gets cut as a draft progresses, but s= he makes a clear case for adding in the endpoint into the threat model.=C2= =A0 I had tried to do a bit of that in my AD reviews as I agree, it's o= ne of the places systems are left vulnerable and open to attack. When the d= efenses in the middle are removed, new ones are needed.=C2=A0 Protocol evol= ution is eliminating these middle boxes, so the end point needs to be shore= d up.=C2=A0 We need first to better prevent attacks, and then to be able to= detect them at end points.=C2=A0 Some of this could get baked into protoco= ls (I'm not sure how yet, but perhaps something can be done), requiring= research and ensuring the protocols maintain the existing set of desired p= roperties.

Towards the end we get: "Endpoints have changed over the
last 10 years, but assumptions about endpoints in the IETF
hasn't changed in that time" - I don't know how the
author knows what assumptions may or may not be made
by IETF participants (not "attendees" of course).

Sure, there's a bunch of us that care about end po= ints, but I think outside perception doesn't show this and those who wo= rk solely on end point security don't feel heard at the moment.=C2=A0 B= ake this into a bigger threat model and we have a more complete picture.=C2= =A0 We as a community need to step back and think about the threat model an= d impacts to users of the Internet.=C2=A0 The time to detect an attack has = come way down (in most countries) over the last 2 years.=C2=A0 This isn'= ;t spelled out in the draft, but could be in a comprehensive draft.=C2=A0 T= he reason for this is that organizations have deployed tighter controls and= are quicker to detect anomalies on their networks.=C2=A0 Detection devices= have also aided in this reduction with the exchange of indicators of compr= omise.=C2=A0 We need new ways to deploy prevention and detection mechanisms= and can't ignore that as we eliminate the methods of detection and pre= vention used by large numbers of organizations.

I&= #39;d be happy to help flesh out this part of the threat model more.
<= div>

And perhaps most oddly, this bold assertion: "Further, it
is imperative that new conclusions and recommendations
from a revisited threat model are backed up by research, case
studies and experience - rather than bold assertions." ;-)

PM was backed by lots of information, I agree.=C2= =A0 The problem is that the focus ignored (largely) other security concerns= .=C2=A0 I tried to ensure system integrity came up when important in drafts= and also logging, but maybe there's more that can and should be done.= =C2=A0

The list of breaches and botnets is fine, but not much
use without any analysis of how those happened. We need a
good bit more work to figure out whether any changes to
protocols or protocol design are actually warranted or
useful in the face of these kinds of incident. (Hence
the oddity of the bold assertion above.)

Yes, and these aren't the only types of attacks.=C2=A0 Phishing is ac= countable for about 90% of so called APT attacks (I can find the artcile th= at says this, just not at the moment).=C2=A0 Better authentication will hel= p (FIDO, tokbind, HOBA, etc.) , but some of the attacks don't involve a= uthentication.=C2=A0

Lastly, ISTM important, if any discussion here is to
be worthwhile, to recognise from the start that existing
IETF consensus positions in this space are not likely to
be discarded - those were arrived at after a lot iterations
of a lot of debate by well-informed IETF participants.
(Despite what some may claim;-) So I reckon the right
discussion to have is about how to extend and not discard
the 3552 threat model. Any other attempted changes would
seem to me to require a shift in deployments from 2-party
to multi-party protocols, which is unrealistic, or to
require magical trust in middleboxes, which would be plain
silly and seems highly unlikely to be something for which
IETF consensus would be established.

Su= re, my full message made the same point. We need to look at the broader thr= eat model and have a more comprehensive picture.=C2=A0 I do think this help= s make the case for the end point and figuring out if we have options withi= n protocols to prevent threat with out-of-the-box thinking, research, secur= ity protocol proofing, and testing.

> Also - is this a request to present at SecDispatch?

I hope not. This draft is IMO clearly not ready for that.
An initial discussion about threat models and how to
approach this kind of work at saag may be worthwhile (and
I think Jari has asked the sec ADs for such a slot).
<= br>
She sent it to SecDispatch, so I needed to ask.=C2=A0 I do ag= ree it's better for SAAG and a larger discussion on threat model, but t= hat's for our ADs to decide.=C2=A0

Cheers,
S.


--

Best regards,
Kathleen
--000000000000226e8a058da25780-- From nobody Sun Jul 14 08:20:54 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A0512024B for ; Sun, 14 Jul 2019 08:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 N_oN9GnqemPc for ; Sun, 14 Jul 2019 08:20:49 -0700 (PDT) Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) (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 9433212003F for ; Sun, 14 Jul 2019 08:20:49 -0700 (PDT) Received: by mail-ot1-f52.google.com with SMTP id z23so14280285ote.13 for ; Sun, 14 Jul 2019 08:20:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nQD/MRjP7UUvLpnoULuqr924TNWdvioDZgC8zKt1254=; b=iu4zkIDIdmJP04b5HD5j6rUWBiDcpsaJCWdxe/ZBkmX07J8YVaS0kyU9HRVFoPLJik DOU9NkEzX2X2FnbXuOuWuYUKj7YuBGzX4mm4SxhtVQ4VUNAlp3lV65uVLZw8CPltpGoZ UvdSopJBM7FEdf1FvtjPt7VFSdH4zFkySG0zpeXEz+Ss6c0FPs17dXTdj7eYdj9ddUww igGuV99tkO0XVwXBy8cITPYufhj2fTGsGUaFm63BJUcj3P2PohU9ratUEbjakvyyXnx5 HaELwVZT6wP2AJvvI4gDosEGqQqCYjHoTYCO/brF0tKBLxVRz5nNDt0i+gYX8py6jn2c LhYA== X-Gm-Message-State: APjAAAXWTxebTGfxjRYaM6zCv3z8ueJWSqWMobkHpFVyV0b6dVQUv4HC VXRCZrvgi0eDek5/uaoCDf/4MGEw4EWWUunQ8jI= X-Google-Smtp-Source: APXvYqyLiA8fLNuxSiE9GCuuSbnLav7nmpROMRxG7JVpoBUmmIr2LvH+TTr+jK/YjXWRk2YuMeVskAp9G9FZpW7XDbU= X-Received: by 2002:a05:6830:1206:: with SMTP id r6mr16785932otp.37.1563117648859; Sun, 14 Jul 2019 08:20:48 -0700 (PDT) MIME-Version: 1.0 References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <45cc67f6-3dd4-9788-29e5-4cc82471e6ee@nomountain.net> <9683DFBC-1816-4C0A-8D8A-4CE36318C72C@cisco.com> In-Reply-To: <9683DFBC-1816-4C0A-8D8A-4CE36318C72C@cisco.com> From: Phillip Hallam-Baker Date: Sun, 14 Jul 2019 11:20:37 -0400 Message-ID: To: Eliot Lear Cc: Melinda Shore , IETF SecDispatch Content-Type: multipart/alternative; boundary="00000000000033d5ca058da5b02e" Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 15:20:52 -0000 --00000000000033d5ca058da5b02e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mostly +1. But this is relevant to the topic I asked for time for... On Sun, Jul 14, 2019 at 6:56 AM Eliot Lear wrote: > Hi Melinda, > > > We > > typically deal with wireline protocols and their support > > structures, and I'm hoping that as the discussions progress > > people can be clear about what they'd like to see from the > > IETF. > > I think you=E2=80=99re primarily referring to leaky user databases here. = I agree > with you that we cannot fix organizations=E2=80=99 bad internal code with= a > wireline protocol. I can. That is exactly what I am working on. This is why I am distinguishing between the server host and the client endpoints. I can't do anything about Alice's laptop or desktop. If that gets malware: not my problem. But I can solve the problem of the data being breached on the server and this is in scope because a server is not an endpoint. Servers are middleboxes, not real endpoints. If you apply end to end cryptography in the right way, you can ensure that all that you have on the server host is AES256 encrypted data and a bunch of random numbers. We are having all these breaches because common business processes require confidential data to be used in ways that existing CRM doesn't solve and can't solve unless there is an open standard. Most of the really important information has to cross organizational boundaries. Almost every important conversation will end up being with a customer, a provider, the auditors or external counsel. Alice at example.com is working on the health care plan. She creates a spreadsheet to assess the cost impact of the different plans and it gets stored on the file server which is then breached when any one of the 10,000 employees with access to files on it clicks on the wrong link in an email. > However, to exploit the vulnerability, the attack had to come from > somewhere. We already have one mechanism to address profiling with IoT > that manufacturers can use to keep their systems from being exploited as > BoTs. The vulnerability has to come from somewhere and it often has to re-propagate after the firewall is breached. The distinction between the network and the Internetwork is a critical one in security terms but one that somehow became unmentionable in the IETF. Which is really odd if you have watched Einer Stefferrud's presentation on the Internet architecture. I have a completely different degree of control and responsibility when it comes to my network. The Internet has to be able to pass any IP packets regardless of port etc. But that is not the case for my network. I so not want my Internet connected blender having the ability to act as a staging post for a botnet. So in the Enterprise or in the home, restricting what a device can do on the network on a default deny, need to know basis is powerful. Sure, personal computers and servers are going to require a lot more network capabilities than food blenders. But there will be orders of magnitude more IoT devices. The next question is whether we should be promoting or improving other > mechanisms to provide people at home and elsewhere more visibility in ter= ms > of what their general purpose computing devices are doing. I=E2=80=99m t= hinking of > PCP in particular. And while there may be more we can do, there may also > be some limitations relating not only to privacy but also economics of we= b > services. > I am waiting for folk to realize that all this data they have been collecting is not the goldmine they think, it is steaming piles of liability. Sure, my personal data was really useful for targeting ads at me. Right up until there were dozens of companies could do the same. Now it is a GDPR liability. > What I like about Dominique=E2=80=99s draft is that it gets us thinking i= n those > directions (or at least it did me). > > > > > I do think that some of this may be appropriate for opsec, > > as well, or at least should be called to their attention. > > Or an RG or a side meeting. It would be fun to continue the discussion. > > Eliot > > > > > Melinda > > > > -- > > Melinda Shore > > melinda.shore@nomountain.net > > > > Software longa, hardware brevis > > > > > > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --00000000000033d5ca058da5b02e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mostly=C2=A0+1. But this is relevant to the topic I asked for= time for...

On Sun, Jul 14, 2019 at 6:56 AM Eliot Lear <lear@cisco.com> wrote:
Hi Melinda,

>=C2=A0 We
> typically deal with wireline protocols and their support
> structures, and I'm hoping that as the discussions progress
> people can be clear about what they'd like to see from the
> IETF.

I think you=E2=80=99re primarily referring to leaky user databases here.=C2= =A0 I agree with you that we cannot fix organizations=E2=80=99 bad internal= code with a wireline protocol.=C2=A0

I can. That is exactly w= hat I am working on.=C2=A0

This is why I am distinguishing between the server host and the client en= dpoints. I can't do anything about Alice's laptop or desktop. If th= at gets malware: not my problem.

But I can solve the problem of the data being breached on the serve= r and this is in scope because a server is not an endpoint. Servers are mid= dleboxes, not real endpoints. If you apply end to end cryptography in the r= ight way, you can ensure that all that you have on the server host is AES25= 6 encrypted data and a bunch of random numbers.

We are having all these bre= aches because common business processes require confidential data to be use= d in ways that existing CRM doesn't solve and can't solve unless th= ere is an open standard. Most of the really important information has to cr= oss organizational boundaries. Almost every important conversation will end= up being with a customer, a provider, the auditors or external counsel.=C2= =A0

<= div class=3D"gmail_default" style=3D"font-size:small">Alice at example.com is working on the health care plan. She = creates a spreadsheet to assess the cost impact of the different plans and = it gets stored on the file server which is then breached when any one of th= e 10,000 employees with access to files on it clicks on the wrong link in a= n email.
=C2=A0
However, to exploit the vulnerability, the attack had to come f= rom somewhere.=C2=A0 We already have one mechanism to address profiling wit= h IoT that manufacturers can use to keep their systems from being exploited= as BoTs.=C2=A0

The vulnerability has to come from somewhere an= d it often has to re-propagate after the firewall is breached.

The distinction between the network a= nd the Internetwork is a critical one in security terms but one that someho= w became unmentionable in the IETF. Which is really odd if you have watched= Einer Stefferrud's presentation on the Internet architecture.

I have a completely different deg= ree of control and responsibility when it comes to my network. The Internet= has to be able to pass any IP packets regardless of port etc. But that is = not the case for my network. I so not want my Internet connected blender ha= ving the ability to act as a staging post for a botnet.

=
So in the Enterprise= or in the home, restricting what a device can do on the network on a defau= lt deny, need to know basis is powerful.

Sure, personal computers and servers are going to require a= lot more network capabilities than food blenders. But there will be orders= of magnitude more IoT devices.

The next question is whether we should be promo= ting or improving other mechanisms to provide people at home and elsewhere = more visibility in terms of what their general purpose computing devices ar= e doing.=C2=A0 I=E2=80=99m thinking of PCP in particular.=C2=A0 And while t= here may be more we can do, there may also be some limitations relating not= only to privacy but also economics of web services.
<= br>
I am w= aiting for folk to realize that all this data they have been collecting is = not the goldmine they think, it is steaming piles of liability.

Sure, my personal data was really us= eful for targeting ads at me. Right up until there were dozens of companies= could do the same. Now it is a GDPR liability.


=C2=A0
What I like about Dominique=E2=80=99s draft is that it gets us thinking in = those directions (or at least it did me).

>
> I do think that some of this may be appropriate for opsec,
> as well, or at least should be called to their attention.

Or an RG or a side meeting.=C2=A0 It would be fun to continue the discussio= n.

Eliot

>
> Melinda
>
> --
> Melinda Shore
> meli= nda.shore@nomountain.net
>
> Software longa, hardware brevis
>
>
>

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--00000000000033d5ca058da5b02e-- From nobody Sun Jul 14 09:31:11 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E93120111 for ; Sun, 14 Jul 2019 09:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 OUlB6YVp-R1h for ; Sun, 14 Jul 2019 09:30:59 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 259D11201A0 for ; Sun, 14 Jul 2019 09:30:59 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id i18so6573171pgl.11 for ; Sun, 14 Jul 2019 09:30:59 -0700 (PDT) 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=A6KaB+0FeELJ+g8S4mzLNBIXqTuFBYrE0A/xi0O1cxQ=; b=pXv5zImpmFU+TOCiBy28NdsDKih7CqeZcsHFMD/6cEGHx6zyj299ttX4Y2qclHMfe4 2x2uR5pftjJSxSZP04cVoAlOUsectRCtNPQWjx9yhTgRDIOJHFjjiCnw1pX+lpkkbMdP 7cjzUQUz7rgiV47c4sCwAIHDfbIBiZyqGBZiHVYjsNRYbI0PVIVomGYT9DVDftpWbPG0 8h5M/BW/IKoqBs0sqXTgbjbm1mxABDUnzTtFUOVjfjtjqmwbvRuRCASka69V4KnqSp4w YJcmRHPpRi56sg6NMFrllIdScfO8TAqLQ8JrT9SeT7rWPJpsJXRuW7z9yfo4Mke0Dpdm lnCQ== 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=A6KaB+0FeELJ+g8S4mzLNBIXqTuFBYrE0A/xi0O1cxQ=; b=VdamQM2HWryu7XaAxWC/ES2f4qyEE7Kl1GbM5gYBVOGfqO/bszSd+XiPdh9Lr4rPCm BNyNhM0fpqvUYXEKVeDpJU3QN79aIJrc36Y2cCklnDGOi/B/N6WqstIHdPA+geTHg3o8 mCdsCycXnYPluXu4I7CjYhOMKpHhuczDXogJtiZFLiazKy6pYrunaVan06/dzIEym98R Vdly94vgO/Rk74OKt+t4rhLMpSxmejCMO0pIMYhdiuhjPf296pBDzUEQpclvZ+h2iBrg sChYX08ZpCCwHYCniHO6kGG68c08lxjiUkXn1KFVsS+TGMU0lkioGFifxp0ifGI4B/AT LxuA== X-Gm-Message-State: APjAAAXVhTx280MSU2CaLHrbq8su5hst+AlEiU1bRN2peRyDuKM5LDRg 4xw2B/Vxg6KEhR8bQx7T6Mo= X-Google-Smtp-Source: APXvYqzdkSd04SuumSvxqe7VCzG6AOSv0yqNmau17lcxYLMe02kbVYEdiBOtH7GbJJn9TqOOB6ouuw== X-Received: by 2002:a17:90a:1b4c:: with SMTP id q70mr23692397pjq.69.1563121858616; Sun, 14 Jul 2019 09:30:58 -0700 (PDT) Received: from ?IPv6:2605:a601:a990:4d00:98b:bcc4:5aa6:8504? ([2605:a601:a990:4d00:98b:bcc4:5aa6:8504]) by smtp.gmail.com with ESMTPSA id j12sm4305511pff.4.2019.07.14.09.30.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Jul 2019 09:30:57 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-40EF9A22-193A-445E-987E-23C7497B9B72 Mime-Version: 1.0 (1.0) From: Bret Jordan X-Mailer: iPhone Mail (16F203) In-Reply-To: <9683DFBC-1816-4C0A-8D8A-4CE36318C72C@cisco.com> Date: Sun, 14 Jul 2019 10:30:56 -0600 Cc: Melinda Shore , secdispatch@ietf.org, smart@irtf.org Content-Transfer-Encoding: 7bit Message-Id: <64343552-264A-4777-B561-54AFF8C9C710@gmail.com> References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <45cc67f6-3dd4-9788-29e5-4cc82471e6ee@nomountain.net> <9683DFBC-1816-4C0A-8D8A-4CE36318C72C@cisco.com> To: Eliot Lear Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 16:31:02 -0000 --Apple-Mail-40EF9A22-193A-445E-987E-23C7497B9B72 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I personally think the biggest value at this stage is awareness and discussi= on. So I would love to see this continue as a regular update item for sec d= ispatch. I would also love to see regular and multiple side meetings. I wo= uld also love to see SMART get officially chartered.=20 I fully understand and get that we in the IETF generally focus on on-the-wir= e protocols. However, I think we can design better and more secure solution= s once we more completely understand the entire security pie. Understanding= operational security requirements and regulatory compliance requirements is= critical for the success of the solutions we create here in the IETF. Bret=20 Sent from my Commodore 128D PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > On Jul 14, 2019, at 4:56 AM, Eliot Lear wrote: >=20 > Hi Melinda, >=20 >> We >> typically deal with wireline protocols and their support >> structures, and I'm hoping that as the discussions progress >> people can be clear about what they'd like to see from the >> IETF. >=20 > I think you=E2=80=99re primarily referring to leaky user databases here. I= agree with you that we cannot fix organizations=E2=80=99 bad internal code w= ith a wireline protocol. However, to exploit the vulnerability, the attack h= ad to come from somewhere. We already have one mechanism to address profili= ng with IoT that manufacturers can use to keep their systems from being expl= oited as BoTs. The next question is whether we should be promoting or impro= ving other mechanisms to provide people at home and elsewhere more visibilit= y in terms of what their general purpose computing devices are doing. I=E2=80= =99m thinking of PCP in particular. And while there may be more we can do, t= here may also be some limitations relating not only to privacy but also econ= omics of web services. >=20 > What I like about Dominique=E2=80=99s draft is that it gets us thinking in= those directions (or at least it did me). >=20 >>=20 >> I do think that some of this may be appropriate for opsec, >> as well, or at least should be called to their attention. >=20 > Or an RG or a side meeting. It would be fun to continue the discussion. >=20 > Eliot >=20 >>=20 >> Melinda >>=20 >> -- >> Melinda Shore >> melinda.shore@nomountain.net >>=20 >> Software longa, hardware brevis >>=20 >>=20 >>=20 >=20 > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch --Apple-Mail-40EF9A22-193A-445E-987E-23C7497B9B72 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I personally think the biggest value at thi= s stage is awareness and discussion.  So I would love to see this conti= nue as a regular update item for sec dispatch.  I would also love to se= e regular and multiple side meetings.  I would also love to see SMART g= et officially chartered. 

I fully understand and get= that we in the IETF generally focus on on-the-wire protocols.  However= , I think we can design better and more secure solutions once we more comple= tely understand the entire security pie.  Understanding operational sec= urity requirements and regulatory compliance requirements is critical for th= e success of the solutions we create here in the IETF.

<= div>
= --Apple-Mail-40EF9A22-193A-445E-987E-23C7497B9B72-- From nobody Sun Jul 14 12:18:35 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374F51200E7 for ; Sun, 14 Jul 2019 12:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=nomountain-net.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 qudruHZT3sgS for ; Sun, 14 Jul 2019 12:18:32 -0700 (PDT) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 B4DB61200C1 for ; Sun, 14 Jul 2019 12:18:32 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id t14so7181528plr.11 for ; Sun, 14 Jul 2019 12:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/yVa90IhF5195+LZXIQF39FqHn1R/7w2KyhtdYADxXg=; b=C9LqG6AzKmFHYZZi6SOT5LIEitseW9VHnZZhFTZTFS2baIdxlK6a+Rci5G1d7/29vE lNCZeE6oCNrSHlvxCxDy4/isBqqPHHYtHps+rPodiIvZKy6/74ifrywF84D6L5HaGPDm PHwEQQVLHomSUoYD9GdLm0Xj6Z2J9boMo4PHRyZpOB44d9jzN4oHaA9UmXDfGWh24Q0U YrEoyvPHZR5AUHyQ50S/zkZBS2D2wB0OxLkGFUGgibca+JecfyzjW3QIdqB2gkU79uO7 YTspxC/cUSPIdpacm8Z35CwjQ+HYRLUbOO9bKvocVUPIerK3Q8Yuu6d4LSeh/TvRI2mp FoYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/yVa90IhF5195+LZXIQF39FqHn1R/7w2KyhtdYADxXg=; b=CemTl9oXbySxxMYB9sxUHsPaTejc5fqeP+MwkqL/CQaQ09nAm5Ijq2z4vFn5NoK+62 rO9qpGhrEcN38a33t2FANjkAqPwpwrDal6Jh5cM6ZbOq1thtTwVWBmbUjqv9z8N8TZhv U5p8+0V5uGXARc2UtI9YfgaqB4wDEt6WA2BK+pZPImRUlgfavzA2amnl5Rn2Uc7MkzD9 qIUEbaqKI88nsQmaipT5fShie1TckYPZVxB/gQu+Pl9AeCuASxyXickYE50XyE1HH2wn MgSjOp5JBKhNeheZge/RXDyNXlxgtmeBNSLbmWoG2iftNI+GqRxokDaLAyZ+wfMaeIep Du8w== X-Gm-Message-State: APjAAAWdG+nwDI/02QKcmSt3v9Prr/+KTm19tk4o5JKxK8K7LGp7M/Xr Q+LScWUZTYBvYoXV4MvSg0D6EgQ= X-Google-Smtp-Source: APXvYqwaWlJ3gNzhJe+EJdg7FPW/MgxjNkih+XrQHttGIFOY1VGyzoTZFv/JftmlYTFH2rkzGdKGYA== X-Received: by 2002:a17:902:42a5:: with SMTP id h34mr25055545pld.16.1563131911965; Sun, 14 Jul 2019 12:18:31 -0700 (PDT) Received: from aspen.local (63-140-64-252.dynamic.lte.acsalaska.net. [63.140.64.252]) by smtp.gmail.com with ESMTPSA id d23sm12413957pjv.18.2019.07.14.12.18.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Jul 2019 12:18:31 -0700 (PDT) To: Eliot Lear Cc: secdispatch@ietf.org References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <45cc67f6-3dd4-9788-29e5-4cc82471e6ee@nomountain.net> <9683DFBC-1816-4C0A-8D8A-4CE36318C72C@cisco.com> From: Melinda Shore Openpgp: preference=signencrypt Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= mQINBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABtCxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PokCVAQTAQoAPgIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaXRaAAoJ EN+4kXKadtuPVioP/3nVzx33yjiEtqLKTEHwofnLT15CV5wAcGa0DTbqgiomVKzSRkkhbF3Z KIHYrnjVpTcYJuW+PmFSIjNizNVr+vvjNP6ptRqx5orWmK4EBe/B9mrpmIshxUwkYr46uwN4 h06xJS3KCzhfhSsnesH5vlGBkUod0+nQhbSLyLRpxmaKaeAl4dxFSBLU0vUJMLH8PXTZVNof 5Yo+ThqCzu1pwOkBQ8gST2J6zdy4PjU9ENQ9RLAamlAG/6rGHEKLFcnUpEg7Tcu1hSzAsqR8 kjX2Prpu4A9DyLCjTOvfOPQa8WjZy18ZdYOxuPxdrTazeCRVJIvYRflhBCZb744jhMyfAiSW eckwRBVSCnBuvWBJl9Ua1wp8SOUXXhgGI8WGvSkvul6kKSkHQKDggd4cojAhxWLfvmjxn5pz 0BNbvrEBGqgWwO1ZMuJpmv3P8YK5Aytsl85NZoMMUJIDxEQhBUgYz5QTQANBKPi8RsfOntho rhzXLqnPPQcE4Xf9O9XIyy077F0JoyiPx74Zsl1dTxmT73pezpfhKUQR7/QlmJ/FAADpb6SO V0tlgBtR6FAZToBYPDiss57AcKM1zzyJ7sHIZkxQelykYSet6hp2WGcwMXQveWqFMQ4fiGQx XNEPO+KZKNj+0sfINzSLP88O5TniM/l/JrjZZNT/lVAQDTdkCBGyuQINBFppZ0gBEACgZuM1 8ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1YZ0O pQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR35FAg SnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fEZHM6 6phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQV0yB gc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4cztv gmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRHRvQs 0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBjLtx1 tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI7qDH FxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnYjMJo dU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABiQI8BBgBCgAmFiEET2gtkyoXlvgg8jTA37iR cpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ75iY5 pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiFPjkr QIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/JYK75 BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApMLL0R /qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV5abZ +iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJRi+cH 7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7Vz9F +6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloSbbMv P9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjxuLzd LY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+31fk1 HKwqd9xRxC8= Message-ID: Date: Sun, 14 Jul 2019 11:18:29 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <9683DFBC-1816-4C0A-8D8A-4CE36318C72C@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 19:18:34 -0000 On 7/14/19 2:56 AM, Eliot Lear wrote:> I think you’re primarily referring to leaky user databases here. No, to the entire draft. > However, to exploit the vulnerability, the > attack had to come from somewhere. I sincerely hope that you're not arguing that anything that happens on an endpoint is within the scope of the IETF if that endpoint is network-attached. > We already have one mechanism to > address profiling with IoT that manufacturers can use to keep their > systems from being exploited as BoTs. We also had the work done in Network Endpoint Assessment. Both of these things are on-the-wire protocols and something that we can do something about. However, the only things I saw in the draft that was something that might be within the IETF's purview is related to software updates, and aside from SUIT there's work on this going on elsewhere. Although if someone wants to make the case for software transparency logging, please do it soon before trans shuts down). > Or an RG or a side meeting. It would be fun to continue the > discussion. I'm not sure that's clear. It's my own opinion that the charter that's been proposed so far for a research group would need a massive rewrite and that the folks advocating this work really don't want to change much to make it more suitable for chartering as an RG. If you want to continue as a side meeting I guess that's your business, but in the meantime opsec does exist. It's currently focused on network devices but I think it may be worth talking with them. Melinda -- Melinda Shore melinda.shore@nomountain.net Software longa, hardware brevis From nobody Sun Jul 14 13:08:25 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1B712016D for ; Sun, 14 Jul 2019 13:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 SUkxzBnhfslt for ; Sun, 14 Jul 2019 13:08:20 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC16120165 for ; Sun, 14 Jul 2019 13:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10927; q=dns/txt; s=iport; t=1563134900; x=1564344500; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=SzeunUv/OkbHxFq/Q+HIGPeqCbS205bQ+c90iX9vsdg=; b=msoXDc5m28KjcZAfX/oUk6eGjDDhvAYbIELHWjxdK8Wm2gNDDU9fNFzE eMuBnXXfpp8jwhkzVAugC5wtJoK9sD5NIa8JNzRVm8F/aGKKzheCVhBEZ p4OeR2UDfjg/za3VXbq0wZwuiOrZEcAkQcYbL3jhexQ6NfoD0Vk/NLf5t o=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAAAIiytd/xbLJq1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVgIBAQEBCwGBZ4FrMiiEHIh7i3iSeod+AgcBAQEJAwEBLwE?= =?us-ascii?q?BgUuCdQKCeTcGDgEDAQEEAQECAQVthUiFSgEBAQECASNQBAIFCwsYKgICVwY?= =?us-ascii?q?TgyIBgXsPqkWBMoVHhGUQgTQBgVCHRXaBaoF/gREnH4IeLj6HTjKCJgSMKYh?= =?us-ascii?q?IlXIJghuCH4EMkGEbgi2HJYNlhkGEEqF6gwsCBAYFAhWBZiI+gRozGggbFWU?= =?us-ascii?q?BgVloPoIPFxSODz0DMJAkAQE?= X-IronPort-AV: E=Sophos;i="5.63,491,1557187200"; d="asc'?scan'208,217";a="14292506" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jul 2019 20:08:17 +0000 Received: from [10.61.168.132] ([10.61.168.132]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x6EK8Gd5011889 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 14 Jul 2019 20:08:16 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_03BA5F2C-51BA-46A7-B956-A3808734AF84"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 14 Jul 2019 22:08:15 +0200 In-Reply-To: Cc: secdispatch@ietf.org To: Melinda Shore References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <45cc67f6-3dd4-9788-29e5-4cc82471e6ee@nomountain.net> <9683DFBC-1816-4C0A-8D8A-4CE36318C72C@cisco.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.168.132, [10.61.168.132] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 20:08:23 -0000 --Apple-Mail=_03BA5F2C-51BA-46A7-B956-A3808734AF84 Content-Type: multipart/alternative; boundary="Apple-Mail=_17CD5EBE-B5FB-42AD-81AE-AD74AF5A931E" --Apple-Mail=_17CD5EBE-B5FB-42AD-81AE-AD74AF5A931E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Melinda, > On 14 Jul 2019, at 21:18, Melinda Shore = wrote: >=20 > On 7/14/19 2:56 AM, Eliot Lear wrote:> I think you=E2=80=99re = primarily > referring to leaky user databases here. >=20 > No, to the entire draft. I leapt to that point erroneously, but in an attempt to think about a = problem that was tractable. (Well, at least not boiling all oceans at = once). It may be too early to do that, but that=E2=80=99s where my head = went. >=20 >> However, to exploit the vulnerability, the >> attack had to come from somewhere. >=20 > I sincerely hope that you're not arguing that anything > that happens on an endpoint is within the scope of the > IETF if that endpoint is network-attached. I made no such statement. In fact, I would hope one could reasonably = infer the opposite from the previous adjoining sentence: >> I agree with you that we cannot fix organizations=E2=80=99 bad = internal code with a wireline protocol. To your point below, there are three questions we can ask: Is the device known to be compromised? Is the device not known to be compromised? Is the device in a known good state? RATS definitely looks at the 2nd, possibly the 3rd. I=E2=80=99m sure = there=E2=80=99s a lot of growing room between those questions alone, = some of which is likely in the IETF=E2=80=99s wheelhouse. That having = been said, see below. >=20 >> We already have one mechanism to >> address profiling with IoT that manufacturers can use to keep their >> systems from being exploited as BoTs. >=20 > We also had the work done in Network Endpoint Assessment. > Both of these things are on-the-wire protocols and something > that we can do something about. However, the only things I > saw in the draft that was something that might be within > the IETF's purview is related to software updates, and aside > from SUIT there's work on this going on elsewhere. Although > if someone wants to make the case for software transparency > logging, please do it soon before trans shuts down). NEA is dead. Long live NEA. But remote attestation is just getting = going. And there may be other approaches to build on RATS, SUIT, EAT, = etc. that are worth exploring. >=20 >> Or an RG or a side meeting. It would be fun to continue the >> discussion. >=20 > I'm not sure that's clear. It's my own opinion that the > charter that's been proposed so far for a research group would > need a massive rewrite and that the folks advocating this work > really don't want to change much to make it more suitable for > chartering as an RG. You apparently have had more conversations with them than I have (that = wouldn=E2=80=99t be hard. In my case I=E2=80=99ve had exactly none). I = thought of a research group because Dominique's draft talks amongst = other things about the need for =E2=80=A6 research. And so you=E2=80=99l= l forgive me if I am experiencing just a bit of cognitive dissidence = between the draft and your perception about advocates of this work. = I=E2=80=99ll accept that as my own lack of context. > If you want to continue as a side > meeting I guess that's your business, but in the meantime opsec > does exist. It's currently focused on network devices but I > think it may be worth talking with them. The issue with opsec is that they are focused on best practices, and = cannot create any protocol. Unless there is a best practice that can = address Dominique=E2=80=99s points, it=E2=80=99s the wrong place. And = worse, I suspect many of those best practices have been written, mostly = elsewhere, and are simply not followed. Eliot --Apple-Mail=_17CD5EBE-B5FB-42AD-81AE-AD74AF5A931E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Melinda,

On 14 Jul 2019, at 21:18, Melinda Shore = <melinda.shore@nomountain.net> wrote:

On = 7/14/19 2:56 AM, Eliot Lear wrote:> I think you=E2=80=99re = primarily
referring to leaky user databases here.

No, to the entire draft.

I leapt to = that point erroneously, but in an attempt to think about a problem that = was tractable.  (Well, at least not boiling all oceans at once). =  It may be too early to do that, but that=E2=80=99s where my head = went.


However, to exploit the vulnerability, the
attack= had to come from somewhere.  

I sincerely hope that you're not arguing that anything
that happens on an endpoint is within the scope of the
IETF if that endpoint is network-attached.

I = made no such statement.  In fact, I would hope one could reasonably = infer the opposite from the previous adjoining = sentence: 

 I agree with = you that we cannot fix organizations=E2=80=99 bad internal code with a = wireline protocol.


To your point below, = there are three questions we can ask:

  • Is the = device known to be compromised?
  • Is the device not = known to be compromised?
  • Is the device in a known = good state?

RATS definitely looks at the 2nd, possibly the 3rd. =  I=E2=80=99m sure there=E2=80=99s a lot of growing room between = those questions alone, some of which is likely in the IETF=E2=80=99s = wheelhouse.  That having been said, see = below. 


We already have one = mechanism to
address profiling with IoT that manufacturers = can use to keep their
systems from being exploited as = BoTs.  

We also had the = work done in Network Endpoint Assessment.
Both of these = things are on-the-wire protocols and something
that we can = do something about.  However, the only things I
saw = in the draft that was something that might be within
the = IETF's purview is related to software updates, and aside
from SUIT there's work on this going on elsewhere. =  Although
if someone wants to make the case for = software transparency
logging, please do it soon before = trans shuts down).

NEA is dead.  Long live NEA. But remote = attestation is just getting going.  And there may be other = approaches to build on RATS, SUIT, EAT, etc. that are worth = exploring.


Or an RG or a side meeting.  It would be = fun to continue the
discussion.

I'm not sure that's clear. =  It's my own opinion that the
charter that's been = proposed so far for a research group would
need a massive = rewrite and that the folks advocating this work
really = don't want to change much to make it more suitable for
chartering as an RG.  

You apparently have had more conversations with = them than I have (that wouldn=E2=80=99t be hard.  In my case I=E2=80=99= ve had exactly none).  I thought of a research group because = Dominique's draft talks amongst other things about the need for =E2=80=A6 =  research.  And so you=E2=80=99ll forgive me = if I am experiencing just a bit of cognitive dissidence between the = draft and your perception about advocates of this work.  I=E2=80=99ll= accept that as my own lack of context.

If you want to continue as a side
meeting I = guess that's your business, but in the meantime opsec
does = exist.  It's currently focused on network devices but I
think it may be worth talking with them.

The = issue with opsec is that they are focused on best practices, and cannot = create any protocol.  Unless there is a best practice that can = address Dominique=E2=80=99s points, it=E2=80=99s the wrong place. =  And worse, I suspect many of those best practices have been = written, mostly elsewhere, and are simply not followed.

Eliot
 

= --Apple-Mail=_17CD5EBE-B5FB-42AD-81AE-AD74AF5A931E-- --Apple-Mail=_03BA5F2C-51BA-46A7-B956-A3808734AF84 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXSuLrwAKCRBugA9nE248 uCOmAKD4VWx+x/A1MX0dPCViEqOhceKRyACg62R4B5lTRt1Su27Tzoav5s5vV8M= =5Cha -----END PGP SIGNATURE----- --Apple-Mail=_03BA5F2C-51BA-46A7-B956-A3808734AF84-- From nobody Sun Jul 14 14:25:14 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163C512019D for ; Sun, 14 Jul 2019 14:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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_HELO_NONE=0.001, SPF_NONE=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=rtfm-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 hjhTGuUjBRbT for ; Sun, 14 Jul 2019 14:25:09 -0700 (PDT) Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (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 0ED5512018A for ; Sun, 14 Jul 2019 14:25:09 -0700 (PDT) Received: by mail-lf1-x144.google.com with SMTP id r15so4740658lfm.11 for ; Sun, 14 Jul 2019 14:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kZKmDuhetClDFpNQG1TQYzFW2Cz/CZi/lJriCMh2NoU=; b=1aDAsNAikSmKmAlx5kX8NNkbXOcsWf50pkiQ0YGUqyaj18Vfc6loJ+ZRR5hOE0z4n1 KxpXGMeyJwh9Gd5ImgjcqitE25rs1LIMUcmiOOorbkkMfBIAombcmPpwxK6GHLtNfT5u wkyyi9V0sumJuxCEi2+lT+6EaE411oQFadnPvG7Pl7nlWRfjSWqaZvwfQCoLwoLBBTRD glq0TvroBdVmSPivWN1pdVbeJM7uoQ1YcKMhXUmf1Yk6bBc2aC2ZTVv6if2f2XaiN/jd bRtSEoY5tyinlDVBYMgx+tPHawTVNAsLN69kVl9SS6Q2aZRKrsVKhGnOBHuHYM3p3t3U 3esA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kZKmDuhetClDFpNQG1TQYzFW2Cz/CZi/lJriCMh2NoU=; b=ijqGWCszBR0wI7GTaA22l1bqNJTqlocRs0DxTD5p8Lh/6V2Wgv2/dc+jQ4BFwLp4Iz GlK7ih4/6qPRxCQJHXLoli2r6NkzVhbl9L1kY6uJKBq72YFRpsTPyvkzpqFvFOMVjpqw 0w6JeCJclz1DekV6eDUKotQymyZN0dEj+gm3DEAQVDhIARkNcPP3ELnZXvvtcQpw4k5C 3391bO8gu8gzq9i5MGaqKPCXokmk18HVGKAiGjnvUACGPohhzDk5xAMsRm59Q2J22DYS oRIIvXaWC2frTb6/AK5xSU/LqHqCb0i5EivpxFa7fUew071bBvj0r19py3G0IyzbeiyQ sNiw== X-Gm-Message-State: APjAAAXGok+8CsmPkId+gsB1LbMA8bnqAb+SN8F7qBzO3kNI8xQYznSW dF18vtUZTAHJTqXEiVtA6dFb98KiMG/FkXwLndE= X-Google-Smtp-Source: APXvYqxhMm2nAtb4Sce5QV4h6+rlnnMgOP06fQGPEUcojm/Xy/RqYYEW1OArLuCF/Bi5SMYIOsBmlc5MoOHEFoZaN9s= X-Received: by 2002:a19:4a50:: with SMTP id x77mr9600237lfa.91.1563139507175; Sun, 14 Jul 2019 14:25:07 -0700 (PDT) MIME-Version: 1.0 References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> In-Reply-To: <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> From: Eric Rescorla Date: Sun, 14 Jul 2019 14:24:29 -0700 Message-ID: To: Stephen Farrell Cc: Kathleen Moriarty , Dominique Lazanski , smart@irtf.org, IETF SecDispatch Content-Type: multipart/alternative; boundary="0000000000000f55e1058daac7b7" Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 21:25:13 -0000 --0000000000000f55e1058daac7b7 Content-Type: text/plain; charset="UTF-8" I more or less agree with Stephen's position. First, I recognize that this focus on secure endpoints talking to each other is probably the part of 3552 that people are most unhappy about. As I was almost certainly the person who wrote that text, it might be helpful if I laid out some background. First, RFC 3552 isn't intended to say that endpoint threats aren't real, but merely that they are out of scope because they are hard to address. Here's the text in context: The Internet environment has a fairly well understood threat model. In general, we assume that the end-systems engaging in a protocol exchange have not themselves been compromised. Protecting against an attack when one of the end-systems has been compromised is extraordinarily difficult. It is, however, possible to design protocols which minimize the extent of the damage done under these circumstances. For a more narrow statement with a similar theme (but extended to the Web platform, see https://www.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model- and https://www.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-compromised-infected-machines-in-Chrome-s-threat-model- ): This is essentially the same situation as with physically-local attacks. The attacker's code, when it runs as your user account on your machine, can do anything you can do. (See also Microsoft's Ten Immutable Laws Of Security.) However, RFC 3552 is primarily oriented towards what can be standardized and in particular towards protocols, and generally secure protocols require some sort of TCB to be effective. Obviously, as alluded to in 3552, to the extent to which protocols can be designed to minimize damage, and we routinely attempt to do so. Examples of this include the use of Forward Secure algorithms and trying to avoid or mitigate designs with single points of failure (as with Certificate Transparency). I know that PHB has some ideas along these lines; I haven't studied them enough to know what I think, but that sort of thing is generally in scope as well. This to some extent goes to Section 2 of draft-lazanski. I certainly agree that to the extent to which it is possible to design cryptographic solutions to prevent data breaches, it is useful to do so, and protocols for doing that would potentially be in scope for IETF. I say "potentially" because I'm not sure that (a) standards are necessary in this space beyond the kind of work we are already doing or (b) that we would have the community to define them, but I don't see an in principle barrier [0] I certainly would not expect 3552 to be deployed to preclude that kind of work. Similarly, I don't think that the kinds of botnet attacks described in Section 3 are out of scope for 3552, though I see how it could be read this way. However I think that the idea of a malicious counterparty is clearly in scope if we assume that the attacker controls the network. Here too, I wouldn't expect 3552 to be deployed to preclude that kind of work; we have done plenty of anti-DoS work in IETF (whether it is good enough is a different story). Turning now to the document itself, its language seems to be trying to stake out a very strong position, but I'm not quite sure what that position is. For instance: themselves. These assumptions have led to a focus on communications security and the development of protocols that place this kind of security above all else. Ironically - or coincidentally - as the development of these protocols have taken place over the last several decades, there has been and continues to be a sharp rise in cyber attacks. The Internet threat model in RFC 3552 does not even mention that the greatest threat to the Internet is the growing scale and variety of cyber attacks against all types of endpoints that is resulting in significant data breaches. This now needs to change. First, I'm not sure that I agree that cyber attacks on endpoints are the greatest threat to the Internet, but even assuming that's so, what are the implications of that for work in the IETF? It's one thing to change the words of 3552, but what work specifically would we do if those words were different. Second, I think it's quite likely true that the IETF has focused on communications security, and this document seems to be trying to argue that that's to the detriment of other kinds of security, both here and in other places: Internet security research and technical development must accept the reality of all the security issues in the Internet ecosystem. Decisions being made in the name of privacy are sometimes leading to larger inadvertent security and privacy losses. I'd like to try to explore this argument a bit. Specifically, it might be the case that the IETF has just ignored non-comsec and that if we had spent more time on it, that would be better. Alternatively, it could be true that the IETF's focus on comsec has actively harmed other kinds of security. One gets the sense that this document wants to argue the latter point, but it doesn't really come out and say it, let alone substantiate it. That, rather than arguing about the completeness or appropriateness of RFC 3552, might be a better place to start. -Ekr [0] Indeed, work like token binding is arguably a stab at some of this stuff. On Sun, Jul 14, 2019 at 3:26 AM Stephen Farrell wrote: > > Hiya, > > On 14/07/2019 03:06, Kathleen Moriarty wrote: > > It's a good start toward broadening > > the conversation on the Internet threat model and I do agree that is > > necessary. > > FWIW, I don't agree that this is a good start. > > ISTM that this draft is far too opinionated, for example > claiming that "IETF attendees are privacy-focused", (how > does the author know?), claiming it "unthinkable" that > something isn't done, and that "Internet security research > and technical development must accept the reality of all > the security issues in the Internet ecosystem" (though > I'm not sure I can parse that last quote at all). > > Towards the end we get: "Endpoints have changed over the > last 10 years, but assumptions about endpoints in the IETF > hasn't changed in that time" - I don't know how the > author knows what assumptions may or may not be made > by IETF participants (not "attendees" of course). > > And perhaps most oddly, this bold assertion: "Further, it > is imperative that new conclusions and recommendations > from a revisited threat model are backed up by research, case > studies and experience - rather than bold assertions." ;-) > > The list of breaches and botnets is fine, but not much > use without any analysis of how those happened. We need a > good bit more work to figure out whether any changes to > protocols or protocol design are actually warranted or > useful in the face of these kinds of incident. (Hence > the oddity of the bold assertion above.) > > Lastly, ISTM important, if any discussion here is to > be worthwhile, to recognise from the start that existing > IETF consensus positions in this space are not likely to > be discarded - those were arrived at after a lot iterations > of a lot of debate by well-informed IETF participants. > (Despite what some may claim;-) So I reckon the right > discussion to have is about how to extend and not discard > the 3552 threat model. Any other attempted changes would > seem to me to require a shift in deployments from 2-party > to multi-party protocols, which is unrealistic, or to > require magical trust in middleboxes, which would be plain > silly and seems highly unlikely to be something for which > IETF consensus would be established. > > > Also - is this a request to present at SecDispatch? > > I hope not. This draft is IMO clearly not ready for that. > An initial discussion about threat models and how to > approach this kind of work at saag may be worthwhile (and > I think Jari has asked the sec ADs for such a slot). > > Cheers, > S. > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --0000000000000f55e1058daac7b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I more or less agree with Stephen's position.

F= irst, I recognize that this focus on secure endpoints talking to each
ot= her is probably the part of 3552 that people are most unhappy
about. As = I was almost certainly the person who wrote that text, it might
be helpf= ul if I laid out some background.

First, RFC 3552 isn't intended= to say that endpoint threats aren't
real, but merely that they are = out of scope because they are hard
to address. Here's the text in co= ntext:

=C2=A0 =C2=A0The Internet environment has a fairly well under= stood threat model.
=C2=A0 =C2=A0In general, we assume that the end-syst= ems engaging in a protocol
=C2=A0 =C2=A0exchange have not themselves bee= n compromised.=C2=A0 Protecting against an
=C2=A0 =C2=A0attack when one = of the end-systems has been compromised is
=C2=A0 =C2=A0extraordinarily = difficult.=C2=A0 It is, however, possible to design
=C2=A0 =C2=A0protoco= ls which minimize the extent of the damage done under these
=C2=A0 =C2= =A0circumstances.

For a more narrow statement with a similar theme (= but extended to
the Web platform, see https://www.chromium.org/Home/chromium-securi= ty/security-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-= model- and
https://www.chromium.org/Home/chromium-security/security-faq#TO= C-Why-aren-t-compromised-infected-machines-in-Chrome-s-threat-model-):<= br>
=C2=A0 =C2=A0This is essentially the same situation as with physical= ly-local
=C2=A0 =C2=A0attacks. The attacker's code, when it runs as = your user account on
=C2=A0 =C2=A0your machine, can do anything you can = do. (See also Microsoft's Ten
=C2=A0 =C2=A0Immutable Laws Of Securit= y.)

However, RFC 3552 is primarily oriented towards what can be
s= tandardized and in particular towards protocols, and generally secure
pr= otocols require some sort of TCB to be effective. Obviously, as
alluded = to in 3552, to the extent to which protocols can be designed
to minimize= damage, and we routinely attempt to do so. Examples of
this include the= use of Forward Secure algorithms and trying to avoid
or mitigate design= s with single points of failure (as with Certificate
Transparency).=C2= =A0 I know that PHB has some ideas along these lines; I
haven't stud= ied them enough to know what I think, but that sort of
thing is generall= y in scope as well.

This to some extent goes to Section 2 of draft-l= azanski. I certainly
agree that to the extent to which it is possible to= design
cryptographic solutions to prevent data breaches, it is useful t= o do
so, and protocols for doing that would potentially be in scope for<= br>IETF. I say "potentially" because I'm not sure that (a) st= andards are
necessary in this space beyond the kind of work we are alrea= dy doing
or (b) that we would have the community to define them, but I d= on't
see an in principle barrier [0] I certainly would not expect 35= 52 to
be deployed to preclude that kind of work.

Similarly, I don= 't think that the kinds of botnet attacks described
in Section 3 are= out of scope for 3552, though I see how it could
be read this way. Howe= ver I think that the idea of a malicious
counterparty is clearly in scop= e if we assume that the attacker
controls the network. Here too, I would= n't expect 3552 to be deployed
to preclude that kind of work; we hav= e done plenty of anti-DoS work
in IETF (whether it is good enough is a d= ifferent story).


Turning now to the document itself, its languag= e seems to be trying
to stake out a very strong position, but I'm no= t quite sure what that
position is. For instance:

=C2=A0 =C2=A0th= emselves. These assumptions have led to a focus on communications
=C2=A0= =C2=A0security and the development of protocols that place this kind of=C2=A0 =C2=A0security above all else. Ironically - or coincidentally - as = the
=C2=A0 =C2=A0development of these protocols have taken place over th= e last
=C2=A0 =C2=A0several decades, there has been and continues to be = a sharp rise in
=C2=A0 =C2=A0cyber attacks. The Internet threat model in= RFC 3552 does not even
=C2=A0 =C2=A0mention that the greatest threat to= the Internet is the growing
=C2=A0 =C2=A0scale and variety of cyber att= acks against all types of endpoints
=C2=A0 =C2=A0that is resulting in si= gnificant data breaches. This now needs to
=C2=A0 =C2=A0change.

F= irst, I'm not sure that I agree that cyber attacks on endpoints are
= the greatest threat to the Internet, but even assuming that's so,
wh= at are the implications of that for work in the IETF? It's one thingto change the words of 3552, but what work specifically would we
do if = those words were different.

Second, I think it's quite likely tr= ue that the IETF has focused
on communications security, and this docume= nt seems to be trying
to argue that that's to the detriment of other= kinds of security,
both here and in other places:

=C2=A0 =C2=A0I= nternet security research and technical development must accept the
=C2= =A0 =C2=A0reality of all the security issues in the Internet ecosystem.
= =C2=A0 =C2=A0Decisions being made in the name of privacy are sometimes lead= ing to
=C2=A0 =C2=A0larger inadvertent security and privacy losses.
<= br>I'd like to try to explore this argument a bit. Specifically, it mig= ht
be the case that the IETF has just ignored non-comsec and that if we<= br>had spent more time on it, that would be better. Alternatively, it
co= uld be true that the IETF's focus on comsec has actively harmed
othe= r kinds of security. One gets the sense that this document wants
to argu= e the latter point, but it doesn't really come out and say it,
let a= lone substantiate it. That, rather than arguing about the completeness
o= r appropriateness of RFC 3552, might be a better place to start.

-Ek= r


[0] Indeed, work like token binding is arguably a stab at some= of this
stuff.

On Sun, Jul 14, 2019 at 3:26 AM Stephen Farrell <<= a href=3D"mailto:stephen.farrell@cs.tcd.ie">stephen.farrell@cs.tcd.ie&g= t; wrote:

Hiya,

On 14/07/2019 03:06, Kathleen Moriarty wrote:
> It's a good start toward broadening
> the conversation on the Internet threat model and I do agree that is > necessary.

FWIW, I don't agree that this is a good start.

ISTM that this draft is far too opinionated, for example
claiming that "IETF attendees are privacy-focused", (how
does the author know?), claiming it "unthinkable" that
something isn't done, and that "Internet security research
and technical development must accept the reality of all
the security issues in the Internet ecosystem" (though
I'm not sure I can parse that last quote at all).

Towards the end we get: "Endpoints have changed over the
last 10 years, but assumptions about endpoints in the IETF
hasn't changed in that time" - I don't know how the
author knows what assumptions may or may not be made
by IETF participants (not "attendees" of course).

And perhaps most oddly, this bold assertion: "Further, it
is imperative that new conclusions and recommendations
from a revisited threat model are backed up by research, case
studies and experience - rather than bold assertions." ;-)

The list of breaches and botnets is fine, but not much
use without any analysis of how those happened. We need a
good bit more work to figure out whether any changes to
protocols or protocol design are actually warranted or
useful in the face of these kinds of incident. (Hence
the oddity of the bold assertion above.)

Lastly, ISTM important, if any discussion here is to
be worthwhile, to recognise from the start that existing
IETF consensus positions in this space are not likely to
be discarded - those were arrived at after a lot iterations
of a lot of debate by well-informed IETF participants.
(Despite what some may claim;-) So I reckon the right
discussion to have is about how to extend and not discard
the 3552 threat model. Any other attempted changes would
seem to me to require a shift in deployments from 2-party
to multi-party protocols, which is unrealistic, or to
require magical trust in middleboxes, which would be plain
silly and seems highly unlikely to be something for which
IETF consensus would be established.

> Also - is this a request to present at SecDispatch?

I hope not. This draft is IMO clearly not ready for that.
An initial discussion about threat models and how to
approach this kind of work at saag may be worthwhile (and
I think Jari has asked the sec ADs for such a slot).

Cheers,
S.
_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--0000000000000f55e1058daac7b7-- From nobody Sun Jul 14 17:24:11 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0D11200B7 for ; Sun, 14 Jul 2019 17:24:03 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 YQ4NDzhw1B2D for ; Sun, 14 Jul 2019 17:24:01 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 E55E21202A1 for ; Sun, 14 Jul 2019 17:24:00 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id q4so6843685pgj.8 for ; Sun, 14 Jul 2019 17:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=y0jbE+k4jT0+OCGVre0LSQAGSM2NOmFLpgf5T5P6RrE=; b=H3UYeEGAPUZSgoRS3oOUR/hwIdMgsYngRNHNMew51WoVLAdiXbQ6RqAmsh55cZCHo7 edR1lpDhZI0CIYzCJYH86Dnn9cLLnObxdwMhlVViVssgkC+BWoM4auGnSUiJ2w614PZ3 WT1QYNfBsb8BAnuFK33PA3lAHDXvVtkgZQbGKLxKg0+bkA+k8gpbPZ0DgecMw8XCTgii 4ZYzhPkmC6twHfYA6Sjq4OlHiIxyXlMmy3OdqUr79uU3tV8XCgjpHB3Y2uUnFvys120B ySw2GBrp87d8x1YzYtfRjKeF6QOVbNcOgyYu3KpeAx5znlWz+E5JFIxJya4CWZx5KMFC kslg== 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=y0jbE+k4jT0+OCGVre0LSQAGSM2NOmFLpgf5T5P6RrE=; b=YAIRkfRU3LMl/MnzSzFlP6EnemEffVtC87YBuRBO9iR9MGzmSnbF00sFSWTECRJr1k BIZZXWPEuzn277ezamZ1dP7gJpZcRs6AuXIU6LwZ8DKPBKZRhRzQYdSiQGZxdKKSzkMk aQqbJhpbLCUH8VGopq2wv9XZIG10ztRWebPqWNtZvSqSNkp/2DdQteCrfE3jReT+2RpM ryTEgQtL95Qayt2Nm20QoUoJzssPACNUTrLY7LOWKsZVlluR8jRCCMW6EhN59F/ZWUrn MEFAN8qJ44yKbhK3CNQZuYfkq5YRUu5NQklCDYav5Os/F4fCaslb1BkDGt/DXmm350GQ y9qA== X-Gm-Message-State: APjAAAVNdiTAsoAF6eGAPpRpE8COMYHm0HqcqE1/aouEwiJR9Dz7D8p+ SDOojHSOCIuiWZ8WaLpaYpI= X-Google-Smtp-Source: APXvYqwThSgYsUu6pZI08G6w4I6GSLF8mM1qPo2glAEMh5R0uUOjg6hsDs8AqSQfDYXkiSZLBvpwuA== X-Received: by 2002:a63:6110:: with SMTP id v16mr20665239pgb.60.1563150240260; Sun, 14 Jul 2019 17:24:00 -0700 (PDT) Received: from ?IPv6:2605:a601:a990:4d00:6893:ce36:fd8f:62a0? ([2605:a601:a990:4d00:6893:ce36:fd8f:62a0]) by smtp.gmail.com with ESMTPSA id 143sm23368747pgc.6.2019.07.14.17.23.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Jul 2019 17:23:59 -0700 (PDT) From: Bret Jordan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C12D523E-97BA-4FAA-BAB8-C954A0D4E07C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 14 Jul 2019 18:23:56 -0600 In-Reply-To: Cc: Melinda Shore , secdispatch@ietf.org, smart@irtf.org To: Eliot Lear References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <45cc67f6-3dd4-9788-29e5-4cc82471e6ee@nomountain.net> <9683DFBC-1816-4C0A-8D8A-4CE36318C72C@cisco.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 00:24:03 -0000 --Apple-Mail=_C12D523E-97BA-4FAA-BAB8-C954A0D4E07C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Elliot. =20 There are a few additional questions to consider, that are more = relevant, IMO: > To your point below, there are three questions we can ask: >=20 > Is the device known to be compromised? > Is the device not known to be compromised? > Is the device in a known good state? >=20 1) Is the content or content provider that the user is going to = compromised and trying to attack the endpoint? 2) Is the content provider that the user is going to a stage 2 delivery = site? 3) Is the content provider that the user is going to the location for = outbound malicious content (data exfiltration, CnC traffic) 4) Is the content provider that the user is going to adversely tracking = and monitoring everything the end client does, aka active surveillance = versus passive surveillance? 5) Is the remote site that the user did not go to attack the end point.=20= All of this in network based / Internet based. Protocol designs can = help make it much more difficult for threat actors, crime syndicates, = and intrusion sets from being as effective.=20 Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." --Apple-Mail=_C12D523E-97BA-4FAA-BAB8-C954A0D4E07C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Elliot.  

There = are a few additional questions to consider, that are more relevant, = IMO:


To your point below, there are three questions we can = ask:

  • Is the device known to be = compromised?
  • Is the device not known to be = compromised?
  • Is the device in a known good = state?


1) Is the content or content provider that the = user is going to compromised and trying to attack the = endpoint?
2) Is the content provider that the user is going to = a stage 2 delivery site?
3) Is the content provider that the = user is going to the location for outbound malicious content (data = exfiltration, CnC traffic)
4) Is the content provider that the = user is going to adversely tracking and monitoring everything the end = client does, aka active surveillance versus passive = surveillance?
5) Is the remote site that the user did not go = to attack the end point. 

All = of this in network based / Internet based.  Protocol designs can = help make it much more difficult for threat actors, crime syndicates, = and intrusion sets from being as effective. 


Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an egg."


= --Apple-Mail=_C12D523E-97BA-4FAA-BAB8-C954A0D4E07C-- From nobody Sun Jul 14 17:27:45 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60C01202A1 for ; Sun, 14 Jul 2019 17:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 hHRI8AW7qtP7 for ; Sun, 14 Jul 2019 17:27:41 -0700 (PDT) Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) (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 6DFE41200B7 for ; Sun, 14 Jul 2019 17:27:41 -0700 (PDT) Received: by mail-oi1-f170.google.com with SMTP id l12so11394286oil.1 for ; Sun, 14 Jul 2019 17:27:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FTUIeqZ88mr1G0vLDXqzKSBvmb7ykHZBdLT8a+IxpVM=; b=UFUkys1jXbxcxXVExM0MEX9iOrOq2j1f/VWjbiABHZpNt3jUQU5UbWLmESkSzbvymF eI8Sa97K6cGMo/fn1J8Nbogy4v5TqdWqusEMapSUiY12otHT1722KeUBAaApOsDytDL2 SNYAs+j781TCaxficHtdIluE1ImxXRCq0F8u5BxNujqXA9ScR9ovXDcaXo3xRESSQWXT pR4CfUcI1lHQZjgeZXDUFCEYQliwXIGbiYi++Z6kiww0DAgikre57n0VhYR/9oK8H9Gt l3zrWDXH6cI4qMLZ2LXuEGCZ25A6eWMkdf4fNfYD2D4qh1dRv9YQSfKKD1Bly0DeTcZO SYVg== X-Gm-Message-State: APjAAAVC65gCsrk7Sx9ACd/Q/yZWjKas62Mux111lfu82Zs3eVfFmhY7 mpRYX5yWrE9sKx0qcamv6BekD0J/dfUAkawRKmM= X-Google-Smtp-Source: APXvYqwNyH0XBLsIhVbtQEIdFiKiy7uePunZ/RaFdqEwOa5kwI/A7B+JgC2x9biIHK0E/eO+K88Umh0+2t7qXUd1T8I= X-Received: by 2002:aca:5883:: with SMTP id m125mr12276617oib.58.1563150460652; Sun, 14 Jul 2019 17:27:40 -0700 (PDT) MIME-Version: 1.0 References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> In-Reply-To: From: Phillip Hallam-Baker Date: Sun, 14 Jul 2019 20:27:29 -0400 Message-ID: To: Eric Rescorla Cc: Stephen Farrell , smart@irtf.org, Kathleen Moriarty , Dominique Lazanski , IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000f01188058dad533f" Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 00:27:43 -0000 --000000000000f01188058dad533f Content-Type: text/plain; charset="UTF-8" On Sun, Jul 14, 2019 at 5:25 PM Eric Rescorla wrote: > I more or less agree with Stephen's position. > > First, I recognize that this focus on secure endpoints talking to each > other is probably the part of 3552 that people are most unhappy > about. As I was almost certainly the person who wrote that text, it might > be helpful if I laid out some background. > > First, RFC 3552 isn't intended to say that endpoint threats aren't > real, but merely that they are out of scope because they are hard > to address. Here's the text in context: > > The Internet environment has a fairly well understood threat model. > In general, we assume that the end-systems engaging in a protocol > exchange have not themselves been compromised. Protecting against an > attack when one of the end-systems has been compromised is > extraordinarily difficult. It is, however, possible to design > protocols which minimize the extent of the damage done under these > circumstances. > Hmm... restricting the requirements according to what problems we think we know how to solve seems to be a bit of a systematic problem in the industry. I remember when the malware issue hit and the anti-Virus vendors refused to consider it as their problem because they didn't replicate as viruses. First, I'm not sure that I agree that cyber attacks on endpoints are > the greatest threat to the Internet, but even assuming that's so, > what are the implications of that for work in the IETF? It's one thing > to change the words of 3552, but what work specifically would we > do if those words were different. > I'm not keen on the focus on the end point. It seems like it is brought up as a trump card to 'prove' that all security efforts are futile and the criminals must always win. And I don't think it is true its just defeatism. The reason we need the IETF is that communications protocols are most useful when everyone uses the same thing so we can talk to each other. So communications protocols need standards and hence standards for security. Endpoints don't require standards in quite the same degree. But that doesn't mean that nothing we do is relevant to endpoints. For example, forget 95% of trustworthy computing, the main residual vulnerability of crypto protocols is the risk of private keys being leaked off the machine. That is an endpoint security control that provides real leverage for relatively little cost. But it is a mechanism that can only be used in communication protocols if they are designed with that constraint in mind. --000000000000f01188058dad533f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 14, 2019 at 5:25 PM Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com">ekr@rtfm.com> wrote:
I more or less = agree with Stephen's position.

First, I recognize that this focu= s on secure endpoints talking to each
other is probably the part of 3552= that people are most unhappy
about. As I was almost certainly the perso= n who wrote that text, it might
be helpful if I laid out some background= .

First, RFC 3552 isn't intended to say that endpoint threats ar= en't
real, but merely that they are out of scope because they are ha= rd
to address. Here's the text in context:

=C2=A0 =C2=A0The I= nternet environment has a fairly well understood threat model.
=C2=A0 = =C2=A0In general, we assume that the end-systems engaging in a protocol
= =C2=A0 =C2=A0exchange have not themselves been compromised.=C2=A0 Protectin= g against an
=C2=A0 =C2=A0attack when one of the end-systems has been co= mpromised is
=C2=A0 =C2=A0extraordinarily difficult.=C2=A0 It is, howeve= r, possible to design
=C2=A0 =C2=A0protocols which minimize the extent o= f the damage done under these
=C2=A0 =C2=A0circumstances.

Hmm... restricting the requirements according to what problems we t= hink we know how to solve seems to be a bit of a systematic problem in the = industry. I remember when the malware issue hit and the anti-Virus vendors = refused to consider it as their problem because they didn't replicate a= s viruses.

First, I'm not sure that I agree that cybe= r attacks on endpoints are
the greatest threat to the Internet, but even= assuming that's so,
what are the implications of that for work in t= he IETF? It's one thing
to change the words of 3552, but what work s= pecifically would we
do if those words were different.

I'm not keen on the focus on the end point. It seems like it is br= ought up as a trump card to 'prove' that all security efforts are f= utile and the criminals must always win. And I don't think it is true i= ts just defeatism.=C2=A0

= The reason we need the IETF is that communications protocols are most usefu= l when everyone uses the same thing so we can talk to each other. So commun= ications protocols need standards and hence standards for security.

Endpoints don't require st= andards in quite the same degree. But that doesn't mean that nothing we= do is relevant to endpoints.

For example, forget 95% of trustworthy computing, the main residual vu= lnerability of crypto protocols is the risk of private keys being leaked of= f the machine. That is an endpoint security control that provides real leve= rage for relatively little cost. But it is a mechanism that can only be use= d in communication protocols if they are designed with that constraint in m= ind.


=C2=A0
--000000000000f01188058dad533f-- From nobody Sun Jul 14 17:34:21 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428D912001A for ; Sun, 14 Jul 2019 17:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 KP37vQMV8kHN for ; Sun, 14 Jul 2019 17:34:12 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 7D97B12009E for ; Sun, 14 Jul 2019 17:34:10 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id i21so14373508ljj.3 for ; Sun, 14 Jul 2019 17:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z9rkWk9v2WlIyeEZ2QDYLGT2TpQRFMvMfs7x/hZ0kq0=; b=MZ6AwemFNuPGc4/7mNmG48NZamSAkzIvkU+dmS+iZWfjfUa+BKwRh/B99ROH5CICE6 3+xxluCsM5YirH1dVQX0ky65tdmwxWbWD4cQ6he9MgSXHaLOjm83TWgr5G6NxSgm6krr yC6eQTyWc4qO9YrR8o9qbI7h5aBF0FM49SpLxwFKM6GtlaQFgRGbtXWncUEsuAO/ryov RUVHzDHNXaDGpjyIJFow1pf1Rqq1sGd4himBA24ym4Z0R9NYbhoAhil9Y7/pNtJ7GIRO 5pG+udBGJPASZMfhuAfKMHWazn8+1784cP/XqCKMyXCNGKpB4lRo3P7CSFkCC7K3VmBB eapQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z9rkWk9v2WlIyeEZ2QDYLGT2TpQRFMvMfs7x/hZ0kq0=; b=IWhNc+bkxGpFF+FuRLSeZnWEf/fq8LohqyMcKarqR9Y3ktleB+WW8xucX7iR6L/lmx w1GJhnPk2/Tpa/V3gLpQwWJ46KszS5BUsrmLvJ8vCFbivnlYkmFWmEQI44gIjQrjMG4q KFRQOZnwoL+1RvJIX8hq8tCpQXiXS/2Hu31hpLX8gHNEP8MUQiCsrCmQsRUxu0ed41sk BXWLjywtU86pktZsyM0/XLwTiBndwYzTheZOu4Pkwg2wFRAfxPU6DHV5RMoBjPWppqSG DGJ/WXEs6InMSv2Us9nCJlN/UaHPvYf3Ay/o40vyiC5YqfBJSRwTfSKam8Soajqhxnbf fBvQ== X-Gm-Message-State: APjAAAWQnqc9uasSy8pmhKQPNxEjUqFd+pNW1evN7+yjmvfp4XbbTYdF MdTujifqq/J5A3YM7VuP/jr7PburIUe3keetPN4= X-Google-Smtp-Source: APXvYqw6heQzDgmHxVWJ0RWnCBG6y+YpZUGREfUEwSNBl4QGQ1Xg5zmdCwXQjqWuLAPB7wKLGZn4/N24BNzot2nGabg= X-Received: by 2002:a2e:8892:: with SMTP id k18mr12524142lji.239.1563150848732; Sun, 14 Jul 2019 17:34:08 -0700 (PDT) MIME-Version: 1.0 References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> In-Reply-To: From: Eric Rescorla Date: Sun, 14 Jul 2019 17:33:32 -0700 Message-ID: To: Phillip Hallam-Baker Cc: Stephen Farrell , smart@irtf.org, Kathleen Moriarty , Dominique Lazanski , IETF SecDispatch Content-Type: multipart/alternative; boundary="00000000000011c2d1058dad6be9" Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 00:34:14 -0000 --00000000000011c2d1058dad6be9 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 14, 2019 at 5:27 PM Phillip Hallam-Baker wrote: > > > On Sun, Jul 14, 2019 at 5:25 PM Eric Rescorla wrote: > >> I more or less agree with Stephen's position. >> >> First, I recognize that this focus on secure endpoints talking to each >> other is probably the part of 3552 that people are most unhappy >> about. As I was almost certainly the person who wrote that text, it might >> be helpful if I laid out some background. >> >> First, RFC 3552 isn't intended to say that endpoint threats aren't >> real, but merely that they are out of scope because they are hard >> to address. Here's the text in context: >> >> The Internet environment has a fairly well understood threat model. >> In general, we assume that the end-systems engaging in a protocol >> exchange have not themselves been compromised. Protecting against an >> attack when one of the end-systems has been compromised is >> extraordinarily difficult. It is, however, possible to design >> protocols which minimize the extent of the damage done under these >> circumstances. >> > > Hmm... restricting the requirements according to what problems we think we > know how to solve seems to be a bit of a systematic problem in the > industry. > Without taking the position on the industry as a whole, the E in IETF stands for "engineering", so I think trying to solve problems we know how to solve is prudent. As the list of things we know how to solve increases, then we ought to attempt to solve those as well. First, I'm not sure that I agree that cyber attacks on endpoints are >> the greatest threat to the Internet, but even assuming that's so, >> what are the implications of that for work in the IETF? It's one thing >> to change the words of 3552, but what work specifically would we >> do if those words were different. >> > > I'm not keen on the focus on the end point. It seems like it is brought up > as a trump card to 'prove' that all security efforts are futile and the > criminals must always win. > Well, that's certainly not my position. Endpoints don't require standards in quite the same degree. But that > doesn't mean that nothing we do is relevant to endpoints. > Nor is this. -Ekr For example, forget 95% of trustworthy computing, the main residual > vulnerability of crypto protocols is the risk of private keys being leaked > off the machine. That is an endpoint security control that provides real > leverage for relatively little cost. But it is a mechanism that can only be > used in communication protocols if they are designed with that constraint > in mind. > > > > --00000000000011c2d1058dad6be9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jul 14, 2019 at 5:27 PM Phill= ip Hallam-Baker <phill@hallambaker.com> wrote:


On Sun, Jul 14, 2019 at 5:25 PM Eric Rescorla <= ekr@rtfm.com> wrot= e:
I more or less agree with Stephen's position.

First, I recog= nize that this focus on secure endpoints talking to each
other is probab= ly the part of 3552 that people are most unhappy
about. As I was almost = certainly the person who wrote that text, it might
be helpful if I laid = out some background.

First, RFC 3552 isn't intended to say that = endpoint threats aren't
real, but merely that they are out of scope = because they are hard
to address. Here's the text in context:
=C2=A0 =C2=A0The Internet environment has a fairly well understood threat = model.
=C2=A0 =C2=A0In general, we assume that the end-systems engaging = in a protocol
=C2=A0 =C2=A0exchange have not themselves been compromised= .=C2=A0 Protecting against an
=C2=A0 =C2=A0attack when one of the end-sy= stems has been compromised is
=C2=A0 =C2=A0extraordinarily difficult.=C2= =A0 It is, however, possible to design
=C2=A0 =C2=A0protocols which mini= mize the extent of the damage done under these
=C2=A0 =C2=A0circumstance= s.

Hmm... restricting the requirements according to what problems we think we= know how to solve seems to be a bit of a systematic problem in the industr= y.

Without tak= ing the position on the industry as a whole, the E in IETF stands for "= ;engineering", so I think trying to solve problems we know how to solv= e is prudent. As the list of things we know how to solve increases, then we= ought to attempt to solve those as well.

<= div class=3D"gmail_quote">
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
First, I&= #39;m not sure that I agree that cyber attacks on endpoints are
the grea= test threat to the Internet, but even assuming that's so,
what are t= he implications of that for work in the IETF? It's one thing
to chan= ge the words of 3552, but what work specifically would we
do if those wo= rds were different.

I'm not keen on the focus on the end point. It seems = like it is brought up as a trump card to 'prove' that all security = efforts are futile and the criminals must always win.

Well, that's certainly not my positi= on.


Endpoints don't require standards in quite the same degree. But= that doesn't mean that nothing we do is relevant to endpoints.

Nor is this.
-Ekr

For example, forget 95% of trustworthy computing, the mai= n residual vulnerability of crypto protocols is the risk of private keys be= ing leaked off the machine. That is an endpoint security control that provi= des real leverage for relatively little cost. But it is a mechanism that ca= n only be used in communication protocols if they are designed with that co= nstraint in mind.


=C2=A0
--00000000000011c2d1058dad6be9-- From nobody Sun Jul 14 17:45:35 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CA112018E for ; Sun, 14 Jul 2019 17:45:28 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 64T3UMyQWlTJ for ; Sun, 14 Jul 2019 17:45:25 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 146EB1200DB for ; Sun, 14 Jul 2019 17:45:25 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id n9so642424pgc.1 for ; Sun, 14 Jul 2019 17:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gyoGR8Vw+tWFHlSz5+QiQ4kpvJ/bOGeNbks2BNstQSU=; b=oXm42KdhX7CY96ozikbQ2Z5KzAN2JSFN8A2qAzvat+UXxoFGbq7ZVkB3i62nLAHfaQ h0e/QX9Sn9hWLaQXPftmH5VVSsou7UiTwgB/8EhA0pOjBSiKnSjfMwo2ZLo/CuOYtlLn 1RTBLhQINyJdrzmUliCZcpdmwordA3H9ykX5fd3d1EJ//e6Cr/EnOvHNjYkTdZ1X3/Nj BYixkbb3YXn+b1dIyuYlI9gFoOotzGTkcngNmL2WgA/od0FaI81b+X4Ol9KOr7Hz408+ cnXROZ1L0sNAW37gNBEisf190KH/WcVzYjkcCqC2752qB8I7NFUyq/g/vKMzHAVtLLbW sKsw== 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=gyoGR8Vw+tWFHlSz5+QiQ4kpvJ/bOGeNbks2BNstQSU=; b=A+yoDmuY9P5V8/2CM53VX74ax1ctP4lt8gHAR+jyrn4ytvDpQanD/dzoNoSl6RlZKh vG7Ov431MWbZeL+hQKYPXqqxGdldzkUYwBNmI8AF1BTtfS8RuYrWscXo6t2drJLthXIL +uEdo8otUMBHtdauWjfenEawpUyLXE+/O2xti/rOhX5zedWPuLXgP/kzwNCAq4WGsJQk onbzpiQdvNf+NJD/m45Dtk7Z1hThTAgKjxDhz/onI2cHnGEcdfFlBn8ZH19Kbcw1nPRz xxtchjj93ZHu2cbXOiDY+O+fcJB8k/oyOshzdyHWepHW6zkzgbGZBhQZryLmIouBRsz2 2uJA== X-Gm-Message-State: APjAAAUznPSNi4YQEZJo7ja9N5R+rhwg5glY9HQASUx7VuVP326KcNrJ 3Oqf+ht9wrOY7yuJWi8CtPo= X-Google-Smtp-Source: APXvYqymkA/GonY23/ji9lkTi1ZmoPlR4IV5VGQ6oPEm62OUKbGXn5H+e4TeQFTUo+JBflfRV7rIOQ== X-Received: by 2002:a17:90a:5806:: with SMTP id h6mr25488907pji.126.1563151524648; Sun, 14 Jul 2019 17:45:24 -0700 (PDT) Received: from ?IPv6:2605:a601:a990:4d00:6893:ce36:fd8f:62a0? ([2605:a601:a990:4d00:6893:ce36:fd8f:62a0]) by smtp.gmail.com with ESMTPSA id k36sm16589396pgl.42.2019.07.14.17.45.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Jul 2019 17:45:23 -0700 (PDT) From: Bret Jordan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_89C7521D-F535-4D79-BC7F-913F8135617D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 14 Jul 2019 18:45:21 -0600 In-Reply-To: Cc: Phillip Hallam-Baker , smart@irtf.org, Kathleen Moriarty , Dominique Lazanski , IETF SecDispatch , Stephen Farrell To: Eric Rescorla References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 00:45:29 -0000 --Apple-Mail=_89C7521D-F535-4D79-BC7F-913F8135617D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, > Hmm... restricting the requirements according to what problems we = think we know how to solve seems to be a bit of a systematic problem in = the industry.=20 >=20 > Without taking the position on the industry as a whole, the E in IETF = stands for "engineering", so I think trying to solve problems we know = how to solve is prudent. As the list of things we know how to solve = increases, then we ought to attempt to solve those as well. >=20 Yes, but first we need to make sure we have the open discussions in a = congenial manner. We also need to full understand what is needed by = operational security to prevent threat actors and intrusion sets from = destroying their networks, users, systems, and data. =20 There are many good eco-systems that have very advanced security = engineers in them, we should work with them and communicate with them. = It would be good for some of us from the IETF to go to these groups and = explain what we are working on, why we are working on it, and then ask = for feedback from their perspective. =20 I believe a document written by the IETF that talks more plainly about = the whole security pie, and what parts the IETF is going to try and work = on, would be helpful. We can not boil the ocean. Further, some parts = are better solved outside of the IETF. We just need to make sure the = things we do, do not make other elements of operational security = impossible.=20 Bret --Apple-Mail=_89C7521D-F535-4D79-BC7F-913F8135617D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello,


Hmm... restricting the requirements according to what = problems we think we know how to solve seems to be a bit of a systematic = problem in the industry.

Without taking the position on the = industry as a whole, the E in IETF stands for "engineering", so I think = trying to solve problems we know how to solve is prudent. As the list of = things we know how to solve increases, then we ought to attempt to solve = those as well.


Yes, but first we need to make sure we have the = open discussions in a congenial manner.  We also need to full = understand what is needed by operational security to prevent threat = actors and intrusion sets from destroying their networks, users, = systems, and data.  

There are = many good eco-systems that have very advanced security engineers in = them, we should work with them and communicate with them. It would be = good for some of us from the IETF to go to these groups and explain what = we are working on, why we are working on it, and then ask for feedback = from their perspective.  

I = believe a document written by the IETF that talks more plainly about the = whole security pie, and what parts the IETF is going to try and work on, = would be helpful.  We can not boil the ocean.  Further, some = parts are better solved outside of the IETF.  We just need to make = sure the things we do, do not make other elements of operational = security impossible. 

Bret

= --Apple-Mail=_89C7521D-F535-4D79-BC7F-913F8135617D-- From nobody Sun Jul 14 17:48:50 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D3412018D for ; Sun, 14 Jul 2019 17:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 oDZqHP2iHVEJ for ; Sun, 14 Jul 2019 17:48:47 -0700 (PDT) Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (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 E73621202A4 for ; Sun, 14 Jul 2019 17:48:45 -0700 (PDT) Received: by mail-ot1-f53.google.com with SMTP id r6so15191770oti.3 for ; Sun, 14 Jul 2019 17:48:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Okvd/cugBl0cOhRAaxCj9Rul/laZKddU6PVLk/2ULXY=; b=sQdB4nIrtL0ZUgw27LR3lLM6xjPHdKCKj3fG4KAtus3m2afF4XI3Hd8Lkv900p4xdt XYW3Zahnyl3zvsOAKdmVyFmxkVXwDaEl4ufl4ZjDvfrjsTLaF0esKFVR2dYrvdn03Xu4 aloBHi5NpCwxL3Z4xVgc9cBIvNXvTG7a0yJz59ej49QxotglCTlNHF63o1vR4sqOw8W5 034chAWf6Qr4GrIkdgMHguzztlMB8tHfROUhcVT3SSlrUUnFL0l86TNLbAjwCx/0MTy1 rDllSxQED5tj+DahBiXdctpp2hRHD5jPhkFYDWdYLr6k5fPKkMdH8fVmDDsx83AZHQQE 9vAg== X-Gm-Message-State: APjAAAUw1/H7vx0lgvpsGw/C4GJSoBhPIxnKy0r40hC7wHMZPiQV+T1v ddmnpPf+waLlWQ0LEnsPeuQmR1njnoa0dA4HLwc= X-Google-Smtp-Source: APXvYqwUD+g2VmcXTgEu8Ww0oH3asHkDxcqW57dCPDk1nOtWQRyiFDU26IeWmo4gmrchyNTJNZ9hgN1KM5ly6jlQskg= X-Received: by 2002:a9d:7d02:: with SMTP id v2mr10033295otn.112.1563151725282; Sun, 14 Jul 2019 17:48:45 -0700 (PDT) MIME-Version: 1.0 References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> In-Reply-To: From: Phillip Hallam-Baker Date: Sun, 14 Jul 2019 20:48:34 -0400 Message-ID: To: Eric Rescorla Cc: Stephen Farrell , smart@irtf.org, Kathleen Moriarty , Dominique Lazanski , IETF SecDispatch Content-Type: multipart/alternative; boundary="00000000000050cb1c058dad9fbc" Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 00:48:48 -0000 --00000000000050cb1c058dad9fbc Content-Type: text/plain; charset="UTF-8" On Sun, Jul 14, 2019 at 8:34 PM Eric Rescorla wrote: > > > On Sun, Jul 14, 2019 at 5:27 PM Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> >> > First, I'm not sure that I agree that cyber attacks on endpoints are >>> the greatest threat to the Internet, but even assuming that's so, >>> what are the implications of that for work in the IETF? It's one thing >>> to change the words of 3552, but what work specifically would we >>> do if those words were different. >>> >> >> I'm not keen on the focus on the end point. It seems like it is brought >> up as a trump card to 'prove' that all security efforts are futile and the >> criminals must always win. >> > > Well, that's certainly not my position. > I wasn't suggesting it was. It is just my experience that whenever I discuss some security protocol development in the wider context there is always some smart ass who wants to talk about end-point security rather than the thing the presentation is actually about. It is like the idea that the hackers have to be smarter than the security specialists because they can always find a Ford Cortina with its doors unlocked and the keys in the ignition. --00000000000050cb1c058dad9fbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 14, 2019 at 8:34 PM Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com">ekr@rtfm.com> wrote:


On Sun, Jul 14, 2019 at 5:27 PM Phillip Hallam-Baker <phill@hallambaker.com>= ; wrote:

<= /div>

First, I'm not sure that I agree that cyber attacks= on endpoints are
the greatest threat to the Internet, but even assuming= that's so,
what are the implications of that for work in the IETF? = It's one thing
to change the words of 3552, but what work specifical= ly would we
do if those words were different.

I'm not keen on the focu= s on the end point. It seems like it is brought up as a trump card to '= prove' that all security efforts are futile and the criminals must alwa= ys win.

Well, that&= #39;s certainly not my position.

I wasn't sugg= esting it was. It is just my experience that whenever I discuss some securi= ty protocol development in the wider context there is always some smart ass= who wants to talk about end-point security rather than the thing the prese= ntation is actually about.

It is like the idea that the hackers have to be smarter than the security= specialists because they can always find a Ford Cortina with its doors unl= ocked and the keys in the ignition.

--00000000000050cb1c058dad9fbc-- From nobody Sun Jul 14 17:50:52 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCD21202A4 for ; Sun, 14 Jul 2019 17:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 hAqwK1LgeKsc for ; Sun, 14 Jul 2019 17:50:49 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::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 A1F5712018D for ; Sun, 14 Jul 2019 17:50:48 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id d24so14389465ljg.8 for ; Sun, 14 Jul 2019 17:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QGIhVYSmjmh4nM8xi+E7SRPNK+JFUYv3oepC2kpSQrk=; b=GmvL+FmlovmYvzzSsYVeMDEvImaNcDRTcKhVF+FvNN/4SnJ0r/AJYnO3TS1EfEuhRw lV7UI3i5sQO8mfCeNZ9lGQaEf2mJ4FGTv2fJIMqkskD46NHQrnrSrIv1f9UC7389jppI agC6sYoSuAVtRplxvvleBla8YqsGhHl9sImZWzDhvJIDH5OJAPvXOx9IrmMYNNBzBaFr Mb/VsERNQOJqIPyB1j3BBVZfC57qfepeeohFM3neznyw3+h/Q4StVGDtdcvPg+nnoD8H xV0fNS5/7hizi90A15o1ULuhVzNqi19AdAI7Rc2zpDQ7r+lXC44hQEUe6F5mUnc20Ft1 09LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QGIhVYSmjmh4nM8xi+E7SRPNK+JFUYv3oepC2kpSQrk=; b=Yd3cGRmVFOks7lFBY10nxKJukdHpFlvb8V3IUwsbvZuAVLy4MwKX4SbBgIOxVJk8+v BJhpKDYquGdvKhb9dkay2QNcREPaXC5w0C7trToYg3eUe88JQwywDF8kNDlDec2Q4q8W IV0wTWrFEPE1KTpSIrDwzmLtC6NrbUpJQez1JrAs467GamZfP+LqpoFjC9cnttLO8GLV zSIyB2uN9LWoGeVJEQJ0AndCBtBMj7zB9RgmP5wGl8kDHvW01JDmATXEZXvZ+a1+7zAl PCH1rUqiyLWyEaEIqUpJ/MoBdk1MbCK85mt+aCPjeN37kZayQs0nEk2bGa8TPYp1UtWk fXVA== X-Gm-Message-State: APjAAAWmcmUes+6bB/cu7w7aDyd2KTMc03D99QsoMj92Ew6psN+i7Cfy N8VOV4l8JheUmhrGP2PhV+7FmzO6H4WzLxQalQo= X-Google-Smtp-Source: APXvYqw4pFzWCeswJXUt+4jfBV59obDS7Ymbp7uU5iMzw8QFj3b40bSNIUwsom+WvwNrP8/g/Jp+JqObaBmGt0QVKzM= X-Received: by 2002:a2e:9b84:: with SMTP id z4mr12418814lji.75.1563151846983; Sun, 14 Jul 2019 17:50:46 -0700 (PDT) MIME-Version: 1.0 References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> In-Reply-To: From: Eric Rescorla Date: Sun, 14 Jul 2019 17:50:10 -0700 Message-ID: To: Bret Jordan Cc: Phillip Hallam-Baker , smart@irtf.org, Kathleen Moriarty , Dominique Lazanski , IETF SecDispatch , Stephen Farrell Content-Type: multipart/alternative; boundary="00000000000091d942058dada688" Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 00:50:51 -0000 --00000000000091d942058dada688 Content-Type: text/plain; charset="UTF-8" Bret, Thanks for your note. On Sun, Jul 14, 2019 at 5:45 PM Bret Jordan wrote: > > I believe a document written by the IETF that talks more plainly about the > whole security pie, and what parts the IETF is going to try and work on, > would be helpful. We can not boil the ocean. Further, some parts are > better solved outside of the IETF. We just need to make sure the things we > do, do not make other elements of operational security impossible. > Much like the original draft, this seems to be implying, but not really stating something. If your position is that some protocol engineering that the IETF is doing is making operational security impossible, it would be useful for you to argue that directly. As is, it's not really clear how to respond. -Ekr > Bret > > --00000000000091d942058dada688 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bret,

Thanks for your note.<= br>

On Sun, Jul 14, 2019 at 5:45 PM Bret Jordan <jordan.ietf@gmail.com> wrote:
=

=
I believe a document written by the IETF that talks more plainly about= the whole security pie, and what parts the IETF is going to try and work o= n, would be helpful.=C2=A0 We can not boil the ocean.=C2=A0 Further, some p= arts are better solved outside of the IETF.=C2=A0 We just need to make sure= the things we do, do not make other elements of operational security impos= sible.=C2=A0

Much like t= he original draft, this seems to be implying, but not really stating someth= ing.

I= f your position is that some protocol engineering that the IETF is doing is= making operational security impossible, it would be useful for you to argu= e that directly. As is, it's not really clear how to respond.
=

-Ekr

<= div>

Bret

<= /div>
--00000000000091d942058dada688-- From nobody Sun Jul 14 18:52:12 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B83120147 for ; Sun, 14 Jul 2019 18:52:10 -0700 (PDT) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 fsfkwNHi9M4A for ; Sun, 14 Jul 2019 18:52:07 -0700 (PDT) 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 6F7D612001B for ; Sun, 14 Jul 2019 18:52:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F22BCBE51; Mon, 15 Jul 2019 02:52:03 +0100 (IST) 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 KM5mNt3eVy_Q; Mon, 15 Jul 2019 02:52:02 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5EC56BE50; Mon, 15 Jul 2019 02:51:58 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1563155522; bh=wuoKWRJJq/FbkNAT2Bv5/4BmhW808a0naV7cYxrAwB4=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=xW8a0tbR5nFu3FF3ucrV/Xm7+PBSP7NY7RtXYtPZOv0BCOdibZdv1qMIf5rThmjQ7 TdTZFYjf777PAFudGwdNtnN9UGcZFQJf8lNR9fEYDWVN3RZAH1OQ8c45PPBv1kpg7m iZsQJ2Nf55zL2aKexaogWviNIil2SWNdR657R0BM= To: Bret Jordan , Eric Rescorla Cc: smart@irtf.org, Dominique Lazanski , IETF SecDispatch , Kathleen Moriarty , Phillip Hallam-Baker References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <26db543e-268e-7511-d97c-731d668a7dc3@cs.tcd.ie> Date: Mon, 15 Jul 2019 02:51:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YJn8C4YlS97Z44e7Uoq48WaW616u3L2xd" Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 01:52:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --YJn8C4YlS97Z44e7Uoq48WaW616u3L2xd Content-Type: multipart/mixed; boundary="o3X70RtpkiFpLHR6AlcTNq6ZJtHaK9eXz"; protected-headers="v1" From: Stephen Farrell To: Bret Jordan , Eric Rescorla Cc: smart@irtf.org, Dominique Lazanski , IETF SecDispatch , Kathleen Moriarty , Phillip Hallam-Baker Message-ID: <26db543e-268e-7511-d97c-731d668a7dc3@cs.tcd.ie> Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> In-Reply-To: --o3X70RtpkiFpLHR6AlcTNq6ZJtHaK9eXz Content-Type: multipart/mixed; boundary="------------8768D883644FD43792D3CC21" Content-Language: en-GB This is a multi-part message in MIME format. --------------8768D883644FD43792D3CC21 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In addition to Ekr's query (to which I'd also like to see an answer)... On 15/07/2019 01:45, Bret Jordan wrote: > Yes, but first we need to make sure we have the open discussions in a > congenial manner. We also need to full understand what is needed by > operational security to prevent threat actors and intrusion sets from > destroying their networks, users, systems, and data. Congeniality is great. Clarity is required. Your statement is so unclear as to be unwelcome, and the term unwelcome, as it turns out, seems to be an antonym for congenial. [1] I'm sorry for being a bit of a smartass there, (and I accept considering me a smartass would be a fair reaction to the quip above:-) but ISTM that such absences of clarity too-often accompany claims that the IETF needs to change rough consensus positions on comsec and privacy, and I don't think that's acceptable in what ought be a serious and considered discussion. (And IMO that criticism applies to the draft mentioned in the subject line as well.) A couple of examples of how your statement is unclear: - "Operational security" could be some unqualified set of people or it could be a category of for-profit vendors. The relevant "needs" of those are vastly different IMO. In either case the term seems pretty badly chosen. - "Their networks..." could refer to networks (etc.) owned and operated by some entities or by the customers of some entities. Again, very different interests are involved. - Few to zero n/w attacks would be usefully described via the phrase "destroying...users" - in fact destroy isn't really a useful verb here generally (as it implies a lack of e.g. backup and restore functionality). For the few attacks that one might consider as destroying users (e.g. drones/bombs that kill humans), I'd argue those ought not be considered in the same way as attacks that muck about with network settings. - It makes no sense to to me to talk about "intrusion sets" "destroying" things. Cheers, S. [1] https://www.merriam-webster.com/dictionary/congenial --------------8768D883644FD43792D3CC21 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------8768D883644FD43792D3CC21-- --o3X70RtpkiFpLHR6AlcTNq6ZJtHaK9eXz-- --YJn8C4YlS97Z44e7Uoq48WaW616u3L2xd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl0r3DwACgkQWrL68XsX K+pjFw//WreZ/5QwN0A6v/PaaLw0sv3qMUbR0n+GLUW2hLUYO5jFvpIkIYcMJUx/ SiVPhSv8xxNNH3qTQHakbFslA9Mlfmc7sDPmWb85QMKuO5c0BgavnUwVh1iP4ND5 axy6vPUmBlIWaDq0ugfxiASa3VILbky+/I5W2ww5p/iKXtX/fqt/Ki36QdH2pOB+ imee+x7kmsuYx2Gyo1gzjVFq5RFXn51EOYV7z0/rCVQMsTzQ0KPpc9PO6kGhnjt1 MPoC7X13aXTe7kwIU4Re96TG0rfa5/Xtwgw56nTETmh7I21bs9OQ1wKVP7J68opi bkxfWqD2uBXWRI/BesdF+1cpr8JM1S5pz6DwX0PQRjc2iu22yoN6c/jynY+liZm5 JOStqbpbzR+R4vUriOOBFQ70/bZ9GDSco0G5YC4TyLU15Oq9Oc5U42X/ymL55agg buPl8Em3EiEaPSwjbWaQ2oxvYrF/37JwXmKe9P8mOewQsU6J9KJUvErx+MmfcDbP Fq2K02EoHyljfFnTLzmcXYTYsA0vE3Bw3TfWRPq6Hm5ouYFXYAzdIVvfL5J3DTRn vyWPyVcJb3flcSiW0PXvve04va2e9ikqR4v/646AEu+pio9TjWAU2pucK1wZRIZw Kj4EdW+zP52BVszmHtVXT7YjJTlmXKbUl991VrPtWK5FUVmtrVs= =LJfp -----END PGP SIGNATURE----- --YJn8C4YlS97Z44e7Uoq48WaW616u3L2xd-- From nobody Sun Jul 14 19:13:44 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D18E120163 for ; Sun, 14 Jul 2019 19:13:42 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 h7X9SDVzSYf2 for ; Sun, 14 Jul 2019 19:13:40 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 7841C12001B for ; Sun, 14 Jul 2019 19:13:40 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id y26so14089910qto.4 for ; Sun, 14 Jul 2019 19:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=88GWItezuEwPLvXUd9BOce/p5qvnAX75rX0qBvK+vq8=; b=jAKJSSnf3Kuh/GN4q6svyE4R0M/oSwAAdWk9p3Ufd5hDbkxPMBCP2PGATvE+etKRdz ONE37HGwFsJ11oQ4+LKl5rlZqK4eeJI5oGh2UOPJNtPjaNJaw+n5DUOSMZjqwWytpbWP VxOrId7Nr/ueLK9dIAXyapA+NRYtd9Hy08GlcTZXlvPIYPXveVezwjxm7Nmazd36R9H6 q3uR3qLsfca/vpT7D9I277NG/2KUVJ+mi90s4QN8W1msJorE9Pl/WbVgmwJQEKu99ESV 2zJggX8bXQgeCeOzTxemGZ5Q4sQMo8mV7d1lj5hocLx12/0APyhbD1KqOJpnnQwYLwcD oigg== 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:date :subject:message-id:to; bh=88GWItezuEwPLvXUd9BOce/p5qvnAX75rX0qBvK+vq8=; b=a4uCoH1IiOx1spWxNke+DJkrm40efJO8WqYI4y9RcgisA9qLy9WyYsFRccyVN3HDZZ s6M93DBguncA4qecU2drc1tfRe9JzFIfNXlpgGc7IdbSSyapmrsq36UKXiFwAVss5+R4 FtKNYIAtdfq3hq6uBn4lR8UOgFW32U6xaFSxWpVV8GLRQOdPIdYOwtZLelxNVDGAUmML 4dwD0rybyx7658pq93GQYiFzlNDHCz6iNC6NJsYFqYWZGbHCyNUO6GlUBabMyi/TyXp5 I6J3uUqyBLN9AY7kSK60ss/aeeJKCkT+/gExZgVnBic/CiTZaE7D6UMDAYtdHwIM5hl7 ojkg== X-Gm-Message-State: APjAAAX6hoR1DfWWriRxlh98xcuC80ZGlzdQe7UKhBQkirWv+79zKecT g9wUocv1DB04/ijQNS6YT8j6OyZczIo= X-Google-Smtp-Source: APXvYqwK66mSPHYHvWqtq81+/PZMeENDxa/iPjYg+qRXfvIV/KKf87U1skoHl/Td0/vBZhOzG5tNmw== X-Received: by 2002:a0c:d09c:: with SMTP id z28mr16701135qvg.149.1563156819453; Sun, 14 Jul 2019 19:13:39 -0700 (PDT) Received: from [192.168.1.3] (146-115-73-78.s5196.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [146.115.73.78]) by smtp.gmail.com with ESMTPSA id x46sm10338347qtx.96.2019.07.14.19.13.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Jul 2019 19:13:38 -0700 (PDT) From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Sun, 14 Jul 2019 22:13:38 -0400 Message-Id: <86B4FA2F-664C-4DE2-804D-07149D907595@gmail.com> To: secdispatch@ietf.org X-Mailer: iPhone Mail (16F203) Archived-At: Subject: [Secdispatch] Agenda X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 02:13:42 -0000 Hello, Sorry for not posting and agenda sooner. In the call for agenda items, we h= ad one request, Phil=E2=80=99s work. =20 I=E2=80=99d like to see if the ADs will cover a threat model discussion in S= AAG or if the new drafts should be discussed in SecDispatch. My personal vi= ew is that it would be s good discussion for SAAG, but this is up to the ADs= and we have time on the agenda. I=E2=80=99ll post the agenda tomorrow and update as needed. Best regards, Kathleen=20 Sent from my mobile device= From nobody Mon Jul 15 01:01:48 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E676512007A for ; Mon, 15 Jul 2019 01:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 2_Rb0hoFlncW for ; Mon, 15 Jul 2019 01:01:44 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C65512001E for ; Mon, 15 Jul 2019 01:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1659; q=dns/txt; s=iport; t=1563177704; x=1564387304; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=DT44yFxss/vyM1I3fKBf5AKRUL7m9TiYbAZ0OLUMe0k=; b=LjXaN0b8DJz8t7Z6AQYzHwfW/ZvEZfwxwqAJ3Zaysh9EjcvF3wgToTDR j9wta+OyJh9jpreR2VNrvkCv6DY8UAyK40URhWfy+S0nwJXUMjhyg862N 4hK2oML21SwaAduT6KKrHoIcw/EszBKR6IodEYktT2r5ACsPLLDFhkAbj 8=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAABMixd/xbLJq1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAQBAQEBCwGDUQEgEoREiHuLd5h9gXsCBwEBAQkDAQEvAQG?= =?us-ascii?q?EQAKDATUIDgEDAQEEAQECAQVthUiFSwECAgEjUQMCEAtCAgJXBoM1AYF7D6o?= =?us-ascii?q?sgTKFR4RjEIE0AYFQh0V2gWqBf4E4H4IeLj6HTjKCJgSUcZVyCYIbgh+BDJB?= =?us-ascii?q?hG5gKoXqDCwIEBgUCFYFSAzM+gRozGggbFWUBgVlpPYIPFxSODz0DkFsBAQ?= X-IronPort-AV: E=Sophos;i="5.63,493,1557187200"; d="asc'?scan'208";a="14312101" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jul 2019 08:01:42 +0000 Received: from ams3-vpn-dhcp3718.cisco.com (ams3-vpn-dhcp3718.cisco.com [10.61.78.134]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x6F81fLb027082 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Jul 2019 08:01:41 GMT From: Eliot Lear Message-Id: <469416D4-F549-4CAD-9C81-3D4A5A271B6A@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7A3F131B-C9C8-4863-9760-29E96A502C13"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 15 Jul 2019 10:01:40 +0200 In-Reply-To: Cc: Melinda Shore , secdispatch@ietf.org, smart@irtf.org To: Bret Jordan References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <45cc67f6-3dd4-9788-29e5-4cc82471e6ee@nomountain.net> <9683DFBC-1816-4C0A-8D8A-4CE36318C72C@cisco.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.78.134, ams3-vpn-dhcp3718.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 08:01:46 -0000 --Apple-Mail=_7A3F131B-C9C8-4863-9760-29E96A502C13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Bret, >=20 > 1) Is the content or content provider that the user is going to = compromised and trying to attack the endpoint? > 2) Is the content provider that the user is going to a stage 2 = delivery site? > 3) Is the content provider that the user is going to the location for = outbound malicious content (data exfiltration, CnC traffic) > 4) Is the content provider that the user is going to adversely = tracking and monitoring everything the end client does, aka active = surveillance versus passive surveillance? > 5) Is the remote site that the user did not go to attack the end = point. While we tend to think of endpoints as being equivalent in class, in = which case your use of the term "content provider=E2=80=9D would be = somewhat redundant, from a scaling perspective I am far more concerned = about unwatched unmanaged endpoints than I am about content services. = And again, to me it is a matter of what problems I think might be = tractable. Eliot --Apple-Mail=_7A3F131B-C9C8-4863-9760-29E96A502C13 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXSwy5AAKCRBugA9nE248 uJZGAJ49p34KQ2bqZS8lBekpODO90vFrDQCcD/KC66GSSl035alCkKOd3wWtDaM= =VVX4 -----END PGP SIGNATURE----- --Apple-Mail=_7A3F131B-C9C8-4863-9760-29E96A502C13-- From nobody Mon Jul 15 01:11:39 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674D412001E for ; Mon, 15 Jul 2019 01:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 5x7csB7OuF5D for ; Mon, 15 Jul 2019 01:11:35 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90EC12007A for ; Mon, 15 Jul 2019 01:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9825; q=dns/txt; s=iport; t=1563178294; x=1564387894; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=i+2SHSKPSv+QfCMIt13BeZ0drGNb0wLhXfzBkt/EccA=; b=k/FRo8OCx2MzUzODXKjffw1DHTorv4Kn0BQoEi7Yyj7Dl5B5RzS8bh80 Lj7dBXBZtnBBx0jxN66/WerjNXUfjbNptFHjU68nKeNFS6/ev7soSFtdP pYSPpNp+hDH86bi9vCv1w/JzxG+cVAEb3ZsVIPrF7kpoHkXj9P8DxXKmW 8=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAAzNCxd/xbLJq1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwQBAQEBAQsBgRSCPQEgEiiEHIgcX4tTJYczi0eGA4F?= =?us-ascii?q?7AgcBAQEJAwEBLwEBhEACgwM0CQ4BAwEBBAEBAgEFbYVIhUoBAQEBAgEjRBA?= =?us-ascii?q?CBQsLDgoqAgJXBhODIgGBew+qLoEyhUeEZBCBNAGBUIdFgmCBf4E4DBOCHi4?= =?us-ascii?q?+h04ygiYElHGVcgmCG4IfgQyQYRuCLYsxiiyheoMLAgQGBQIVgVA4PoEaMxo?= =?us-ascii?q?IGxVlAYFZaD6COo4PPQMwkCsBAQ?= X-IronPort-AV: E=Sophos;i="5.63,493,1557187200"; d="asc'?scan'208,217";a="14250137" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jul 2019 08:11:32 +0000 Received: from ams3-vpn-dhcp3718.cisco.com (ams3-vpn-dhcp3718.cisco.com [10.61.78.134]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x6F8BVof017424 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Jul 2019 08:11:32 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_EA31B6AB-BD70-49D7-B596-EB987AA88125"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 15 Jul 2019 10:11:30 +0200 In-Reply-To: Cc: Stephen Farrell , smart@irtf.org, Kathleen Moriarty , Dominique Lazanski , IETF SecDispatch To: Eric Rescorla References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.78.134, ams3-vpn-dhcp3718.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 08:11:37 -0000 --Apple-Mail=_EA31B6AB-BD70-49D7-B596-EB987AA88125 Content-Type: multipart/alternative; boundary="Apple-Mail=_E1560EBF-EAD9-40FF-B9EB-523295548262" --Apple-Mail=_E1560EBF-EAD9-40FF-B9EB-523295548262 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, > On 14 Jul 2019, at 23:24, Eric Rescorla wrote: >=20 > Similarly, I don't think that the kinds of botnet attacks described > in Section 3 are out of scope for 3552, though I see how it could > be read this way. However I think that the idea of a malicious > counterparty is clearly in scope if we assume that the attacker > controls the network. When you say =E2=80=9Cnetwork=E2=80=9D do you mean the botnet or the = wired network connecting devices? The former is where I and most people = would argument most of the trouble stems from: since a great many = attacks are coming from batted devices. I seem to recall that we shut = down a botnet some time ago that had more devices than all of the = Internet infrastructure at all major carriers combined (it was in the = millions). > Here too, I wouldn't expect 3552 to be deployed > to preclude that kind of work; we have done plenty of anti-DoS work > in IETF (whether it is good enough is a different story). And I would expand that to cover not just DoS, but other forms of = attack. To your point on the E in IETF, I agree that there needs to be clarity = on what E is needed. As I wrote elsewhere, I would be happy with quite a = bit more R from the sister organization. Eliot --Apple-Mail=_E1560EBF-EAD9-40FF-B9EB-523295548262 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eric,

On 14 Jul 2019, at 23:24, Eric Rescorla = <ekr@rtfm.com> = wrote:

Similarly, I don't think that = the kinds of botnet attacks described
in Section 3 are out of scope for 3552, though I see how it = could
be read this = way. However I think that the idea of a malicious
counterparty is clearly in scope = if we assume that the attacker
controls the network.


When you say = =E2=80=9Cnetwork=E2=80=9D do you mean the botnet or the wired network = connecting devices?  The former is where I and most people would = argument most of the trouble stems from: since a great many attacks are = coming from batted devices.  I seem to recall that we shut down a = botnet some time ago that had more devices than all of the Internet = infrastructure at all major carriers combined (it was in the = millions). 

Here too, I wouldn't expect 3552 to be deployed
to preclude that kind of work; = we have done plenty of anti-DoS work
in IETF (whether it is good enough is a different = story).


And I would expand that to cover not = just DoS, but other forms of attack.

To your point on the E in IETF, I agree = that there needs to be clarity on what E is needed. As I wrote = elsewhere, I would be happy with quite a bit more R from the sister = organization.

Eliot

= --Apple-Mail=_E1560EBF-EAD9-40FF-B9EB-523295548262-- --Apple-Mail=_EA31B6AB-BD70-49D7-B596-EB987AA88125 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXSw1MgAKCRBugA9nE248 uKjfAJ0azW+lj1jQTvClU8IpYhU84/0yhwCffXlOSLbMyAJ+53MNAAadnwv8ipw= =Vo2g -----END PGP SIGNATURE----- --Apple-Mail=_EA31B6AB-BD70-49D7-B596-EB987AA88125-- From nobody Mon Jul 15 04:32:41 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14CA120098 for ; Mon, 15 Jul 2019 04:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 3ClmXnImG1CR for ; Mon, 15 Jul 2019 04:32:38 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 EA778120077 for ; Mon, 15 Jul 2019 04:32:37 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id t28so15795734lje.9 for ; Mon, 15 Jul 2019 04:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U8ozZZyh4ljfD75AvyK62E63F88X745s9RGGlFyDHsc=; b=Ff5x4rhv8in9Rvih9hoFFJSCoQquvMDCK9IvN4pWrddBssVSOB+8DbTbV/ZdBDxmeY rnXGiA183aDbj+WOuCMAjTS3TJRo9paSOET7eqprldCPksMvPj5/ebOtPy5DgLwH05Eo ciUvmZ0JWG7OfmUGK3kP07tvU0MnI60lpxjQ827gsoS2Z9sVgDqiY5MbfidUmkvihtZw StwBSz/U/jPkgVfLmkaWlHMbmG4ANOv6UUTvSF9RHpiBEr5uXTvLXTYhPgsvS7Bx5vR0 qJFvF9S/fBcgNJEb6FoSg5U8TqbI0UBYMMATd4x3zUSSKjI3CkeywEGz1UXAZZFtS5aq zKIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U8ozZZyh4ljfD75AvyK62E63F88X745s9RGGlFyDHsc=; b=hv/nYShtsc150a8MR+YvVTsE78aWJgGU7Y7+OuYOYrFEm6717Xy0Bte4EMZ0e9ViIv ffxPiwUuphziNI0eCvaWCVXXOd+P3PXDLbmAjcVhCdAojo/1XHry/+W9r3q8SNH7i7WE LHMNztBj3hZ92M/PxT490wsmuM9xqaOqyGjjqRsRbWT8dA5AxreHcZ8nxJX4gbUZNgpw lNRWAjHmhSKoi80xeyH3P9pkx7+Bt/FjbdzI5C9WMCGba5HyncczpYLqwvhmGHmgj3OI Kg1mOqCa3VyBYHJ+y+CqRjpHgrhIoIx7B4uaDSVZyTMUgJ4JSFjiC2G3+StPuSUYrOYR WGLg== X-Gm-Message-State: APjAAAULGZSuqBv4SigAykGxs0iTpbKEwn6Lgaj4+cNfvN6WzTMYg2G/ cINEf4N2FKEvl+KpM3z/UeB925NS63fZRg0gSOg= X-Google-Smtp-Source: APXvYqx7Y+YwVvkVrC0bZbS7FvcR+lEFi2yqWoNatPF0h+R+JmS3o6Syh0P4af3167Qqf3QGFI6hF8ZckXniMneD7Lk= X-Received: by 2002:a2e:9cd4:: with SMTP id g20mr13068538ljj.205.1563190356173; Mon, 15 Jul 2019 04:32:36 -0700 (PDT) MIME-Version: 1.0 References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> In-Reply-To: From: Eric Rescorla Date: Mon, 15 Jul 2019 04:31:58 -0700 Message-ID: To: Eliot Lear Cc: Stephen Farrell , smart@irtf.org, Kathleen Moriarty , Dominique Lazanski , IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000e58d53058db69dc7" Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 11:32:40 -0000 --000000000000e58d53058db69dc7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 15, 2019 at 1:11 AM Eliot Lear wrote: > Hi Eric, > > On 14 Jul 2019, at 23:24, Eric Rescorla wrote: > > Similarly, I don't think that the kinds of botnet attacks described > in Section 3 are out of scope for 3552, though I see how it could > be read this way. However I think that the idea of a malicious > counterparty is clearly in scope if we assume that the attacker > controls the network. > > > > When you say =E2=80=9Cnetwork=E2=80=9D do you mean the botnet or the wire= d network > connecting devices? > Well, from the perspective of the receiver of traffic, these are kind of the same thing, because you're just receiving packets. I agree it's a bit of an awkward fit, and I wish 3552 talked more about compromised counterparties -- this is mostly due to my comsec orientation, I agree -- but I'm not sure that it would change what work we do... -Ekr The former is where I and most people would argument most of the trouble > stems from: since a great many attacks are coming from batted devices. I > seem to recall that we shut down a botnet some time ago that had more > devices than all of the Internet infrastructure at all major carriers > combined (it was in the millions). > > > Here too, I wouldn't expect 3552 to be deployed > to preclude that kind of work; we have done plenty of anti-DoS work > in IETF (whether it is good enough is a different story). > > > > And I would expand that to cover not just DoS, but other forms of attack. > > To your point on the E in IETF, I agree that there needs to be clarity on > what E is needed. As I wrote elsewhere, I would be happy with quite a bit > more R from the sister organization. > > Eliot > > --000000000000e58d53058db69dc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 15, 2019 at 1:11 AM Eliot= Lear <lear@cisco.com> wrote:
Hi Eric,

On 14 Jul 2019, at 23:24, Eric Rescorla <ekr@rtfm.com> wrote:

Similarly, I don't think that the kinds of botn= et attacks described
in Section 3 are out of scope for 3552, though I see ho= w it could
be read this way. However I think that the idea of a malicious
cou= nterparty is clearly in scope if we assume that the attacker
controls the ne= twork.


When yo= u say =E2=80=9Cnetwork=E2=80=9D do you mean the botnet or the wired network= connecting devices?

Wel= l, from the perspective of the receiver of traffic, these are kind of the s= ame thing, because you're just receiving packets.

<= div>I agree it's a bit of an awkward fit, and I wish 3552 talked more a= bout compromised counterparties -- this is mostly due to my comsec orientat= ion, I agree -- but I'm not sure that it would change what work we do..= .

-Ekr

=
=C2=A0The former is where I and most people would argument most o= f the trouble stems from: since a great many attacks are coming from batted= devices.=C2=A0 I seem to recall that we shut down a botnet some time ago t= hat had more devices than all of the Internet infrastructure at all major c= arriers combined (it was in the millions).=C2=A0

=C2=A0

Here too,= I wouldn't expect 3552 to be deployed
to preclude that kind of work; we= have done plenty of anti-DoS work
in IETF (whether it is good enough is a d= ifferent story).


And= I would expand that to cover not just DoS, but other forms of attack.

To your point on the E in IETF, I agree that there nee= ds to be clarity on what E is needed. As I wrote elsewhere, I would be happ= y with quite a bit more R from the sister organization.

Eliot

--000000000000e58d53058db69dc7-- From nobody Mon Jul 15 05:20:58 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908061200F4 for ; Mon, 15 Jul 2019 05:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 S03S2TnYjd-v for ; Mon, 15 Jul 2019 05:20:54 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10841120112 for ; Mon, 15 Jul 2019 05:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5617; q=dns/txt; s=iport; t=1563193254; x=1564402854; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=8EEQFK1vDpWmqyeMf6E2Q6FR2oye2HmULv8hg9ozJIs=; b=SqzCRANDMWb/7bL/YfkGkisRDjVaqPQNNKJEjV6k+eJaYtZNKrA819Wh doHPTzuenF9YMfqsILxI33IZifk2fzu6G5lVk8/1Jy0iWmeehYALM1Bs7 o9IphBKfJrViqQ/Lk5aTjhwnyPfhKBd+KDYUUm+gfCqR0R/Jk+e7/o/H6 4=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAAAmbyxd/xbLJq1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVgEBAQEBAQsBg1EBIBIohByIe4tUJZJ6h34CBwEBAQk?= =?us-ascii?q?DAQEvAQGEQAKDBjcGDgEDAQEEAQECAQVthUiFSgEBAQECASNUAgULCwQKCio?= =?us-ascii?q?CAlcGExSDDgGBew+rM4EyhUeEZhCBNAGBUIg7gWqBf4ERJwwTgh4uPodOMoI?= =?us-ascii?q?mBJRxlXIJghuCH4EMhG+LchuCLZVdoXqDCwIEBgUCFYFmIj6BGjMaCBsVZQG?= =?us-ascii?q?BWWg+gg8XFI4PPQMwkCsBAQ?= X-IronPort-AV: E=Sophos;i="5.63,493,1557187200"; d="asc'?scan'208,217";a="14319685" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jul 2019 12:20:51 +0000 Received: from ams3-vpn-dhcp3718.cisco.com (ams3-vpn-dhcp3718.cisco.com [10.61.78.134]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x6FCKoJc026171 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Jul 2019 12:20:51 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_03E7ABDC-DD4F-4485-B749-C998451B2639"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 15 Jul 2019 14:20:50 +0200 In-Reply-To: Cc: Stephen Farrell , smart@irtf.org, Kathleen Moriarty , Dominique Lazanski , IETF SecDispatch To: Eric Rescorla References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.78.134, ams3-vpn-dhcp3718.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 12:20:57 -0000 --Apple-Mail=_03E7ABDC-DD4F-4485-B749-C998451B2639 Content-Type: multipart/alternative; boundary="Apple-Mail=_CE9E273F-1917-4978-B147-4582263111A4" --Apple-Mail=_CE9E273F-1917-4978-B147-4582263111A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, > On 15 Jul 2019, at 13:31, Eric Rescorla wrote: >=20 > When you say =E2=80=9Cnetwork=E2=80=9D do you mean the botnet or the = wired network connecting devices? >=20 > Well, from the perspective of the receiver of traffic, these are kind = of the same thing, because you're just receiving packets. >=20 > I agree it's a bit of an awkward fit, and I wish 3552 talked more = about compromised counterparties -- this is mostly due to my comsec = orientation, I agree -- but I'm not sure that it would change what work = we do=E2=80=A6 Right. =46rom the perspective of 3352 I would have to agree as well, = because it is about security considerations relating to a specific = protocol mechanism that we are defining and not a broad device threat = model.(*) That having been said, I still think the iRtf should be looking more at = the latter with an eye toward finding new mechanisms that might improve = the overarching Internet security posture. Sorry for beating this drum, = and I realize that there are often better publication venues for = academics, but the IRTF can inform the IETF and broader community about = what the threats are, and maybe even how to plug them in an economical = fashion. Eliot (*) Parenthetically while it=E2=80=99s amazing how long that doc has = withstood the test of time (congratulations!), 3552 probably could use = at least a review for other reasons. The IETF has delivered some really = good capabilities in the last 16 years, and some of those, like TLS 1.3 = and QUIC probably deserve honorable mention. I also wonder whether we = should be pushing common coding approaches in terms of REST, etc, rather = than people reinventing approaches. --Apple-Mail=_CE9E273F-1917-4978-B147-4582263111A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eric,

On 15 Jul 2019, at 13:31, Eric Rescorla = <ekr@rtfm.com> = wrote:

When you say =E2=80=9Cnetwork=E2=80=9D = do you mean the botnet or the wired network connecting devices? =

Well, from the perspective of the receiver of traffic, these = are kind of the same thing, because you're just receiving = packets.

I = agree it's a bit of an awkward fit, and I wish 3552 talked more about = compromised counterparties -- this is mostly due to my comsec = orientation, I agree -- but I'm not sure that it would change what work = we do=E2=80=A6


Right.  =46rom the = perspective of 3352 I would have to agree as well, because it is about = security considerations relating to a specific protocol mechanism that = we are defining and not a broad device threat = model.(*)

That having been said, I = still think the iRtf should be looking more at the latter with an eye = toward finding new mechanisms that might improve the overarching = Internet security posture.  Sorry for beating this drum, and I = realize that there are often better publication venues for academics, = but the IRTF can inform the IETF and broader community about what the = threats are, and maybe even how to plug them in an economical = fashion.

Eliot

(*) Parenthetically while it=E2=80=99s amazing how = long that doc has withstood the test of time (congratulations!), 3552 = probably could use at least a review for other = reasons.  The IETF has delivered some really good capabilities in = the last 16 years, and some of those, like TLS 1.3 and QUIC probably = deserve honorable mention.  I also wonder whether we should be = pushing common coding approaches in terms of REST, etc, rather than = people reinventing approaches.
= --Apple-Mail=_CE9E273F-1917-4978-B147-4582263111A4-- --Apple-Mail=_03E7ABDC-DD4F-4485-B749-C998451B2639 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXSxvogAKCRBugA9nE248 uFNwAKDDE6C8mYSdqSIeywNoO53Q4CnXNwCgssCajZjJ/JnSKySbPO9So+yjSmw= =cta6 -----END PGP SIGNATURE----- --Apple-Mail=_03E7ABDC-DD4F-4485-B749-C998451B2639-- From nobody Mon Jul 15 05:58:06 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E2812011B for ; Mon, 15 Jul 2019 05:58:03 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 8UpHr7RSI8bz for ; Mon, 15 Jul 2019 05:58:02 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 279FD12008B for ; Mon, 15 Jul 2019 05:58:02 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id z23so16789929ote.13 for ; Mon, 15 Jul 2019 05:58:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=X68SOrp5zwJ+BM5evTPLl7A8AK/+ZuP51DVHzoGAziA=; b=jBMpivu17UM8LbKW0WeUGXGIWqG/fka9O0sVsXep0e4uRbLpwLtTiMAb+VA8tK0poc MM0hgMl266rP8lqfRmcWMKx2kSPaky5eSZb6blaoCE5YVOf3ykhbQEX5p4JRCy/OJ6m4 mzbkZ2sUAW4ZASlu/sV+teL6IrJGcW0i9+QNc9WZ1Cy7OgU29DYW+b9hSVEKC3PCZ0vu 0iKlbJsGxqieI7q01lH5GzJns5FNkycmbVuC2owbSXCX4KsP73OYdP56fDxkcZ2cSyDm 33d+EjulastdeOoIACi1c2FtaXDqQTtjvIN/p/r+mWRgs3DJk0pr1C/+5kguWF5QpwcZ 7a9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=X68SOrp5zwJ+BM5evTPLl7A8AK/+ZuP51DVHzoGAziA=; b=YX7AQA8Yhl6OoPxoT7f+f5cnk9/dfDwNtjsCZk5rq+/zW82xOEgL8e2Pwb7m6wGi6O a+27lxmGo1YvPYK5br87W3dkuJ5Gg5qaGzxL6Qs8sDTfiWKj3eOSG6YnUnjLc5x3v+96 AzeoA1pQTntWU2752ANBcs+nsn83LIflBXeIyqiRkh1x/dqCSOYs1YamGDfIsAqAcWyv 90+6KouUxVNVcUuHYjFMsZHQBc4/R+VW5LQ089Bl+pB5qnF/w2k09seRhxMvnFGJjJrN LSQsfA5D26HpBHbJQQ91qB8KVaWeOvfDRF3Brs39zQXBbx4bzittlHycwPUme9l+wJrY LSdQ== X-Gm-Message-State: APjAAAWZxEAGr8u2FNLM9txtYbr6oQaG5AsRkPDxpB8cAtuNIH0ufBq2 a4BNGTcDze5e5y1r+dB1LO3fcRGZSfnv4TmuwcHme5+94sg= X-Google-Smtp-Source: APXvYqx5p67FkwQ/hq+MKXrC9ow8h73V9TauS5J4Z9YJZeuTBQgwdcBTlrAaUoly3nLoor7RHXLoksb2Ll2YZC4T5zc= X-Received: by 2002:a05:6830:1319:: with SMTP id p25mr20487204otq.224.1563195481335; Mon, 15 Jul 2019 05:58:01 -0700 (PDT) MIME-Version: 1.0 References: <86B4FA2F-664C-4DE2-804D-07149D907595@gmail.com> In-Reply-To: <86B4FA2F-664C-4DE2-804D-07149D907595@gmail.com> From: Kathleen Moriarty Date: Mon, 15 Jul 2019 08:57:25 -0400 Message-ID: To: IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000612ab4058db7cf26" Archived-At: Subject: Re: [Secdispatch] Agenda X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 12:58:04 -0000 --000000000000612ab4058db7cf26 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The agenda has been posted: https://datatracker.ietf.org/doc/agenda-105-secdispatch/ Best regards, Kathleen On Sun, Jul 14, 2019 at 10:13 PM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hello, > > Sorry for not posting and agenda sooner. In the call for agenda items, w= e > had one request, Phil=E2=80=99s work. > > I=E2=80=99d like to see if the ADs will cover a threat model discussion i= n SAAG or > if the new drafts should be discussed in SecDispatch. My personal view i= s > that it would be s good discussion for SAAG, but this is up to the ADs an= d > we have time on the agenda. > > I=E2=80=99ll post the agenda tomorrow and update as needed. > > Best regards, > Kathleen > > Sent from my mobile device --=20 Best regards, Kathleen --000000000000612ab4058db7cf26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The agenda has been posted:


Best regards,
Kathleen

On Sun, Jul 14, 2019 at 10:13 PM Ka= thleen Moriarty <kat= hleen.moriarty.ietf@gmail.com> wrote:
Hello,

Sorry for not posting and agenda sooner.=C2=A0 In the call for agenda items= , we had one request, Phil=E2=80=99s work.=C2=A0

I=E2=80=99d like to see if the ADs will cover a threat model discussion in = SAAG or if the new drafts should be discussed in SecDispatch.=C2=A0 My pers= onal view is that it would be s good discussion for SAAG, but this is up to= the ADs and we have time on the agenda.

I=E2=80=99ll post the agenda tomorrow and update as needed.

Best regards,
Kathleen

Sent from my mobile device


--

<= div>Best regards,
Kathleen
--000000000000612ab4058db7cf26-- From nobody Mon Jul 15 06:08:29 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618CA12004C for ; Mon, 15 Jul 2019 06:08:27 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 PWWrlSFLgeKr for ; Mon, 15 Jul 2019 06:08:25 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 09F5C12008B for ; Mon, 15 Jul 2019 06:08:25 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id o101so16856158ota.8 for ; Mon, 15 Jul 2019 06:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NiH7quLBgk+PF83LxOGVwFuKuQXFIuYoyp7V6hpdEe4=; b=W0xlhsoVnlbC5wCrGliKoXX0X/uIhSWJ7Jm3BNfvSkuV1mb7D920BJOQn2SSjnfbj8 HaV6mFewp8ZjDiHe5t0Nh5uOEyXXFLa4E/Kc31nUTz3PFqIun3KCsfgt67vMftj2hFj6 xFQv7SJqLXxzvvIR9LqUzfo9V1Ji6Wxi2bH8PUsIwQw0UruX8aJumhVBh58kWOjZ+tL3 dX+PT6lFvKoWjnpqb7PZlB2PwJB8VZIzgzNcB3leua9tUHOk9vvBYkXfnIKxrbocFExS GzThySm3/sgaZsccCqW8w9tZ9w4ARiMK+HbPTa5mMu7sWJurSqDo8Z3tFIK4S/SBe2Ap Ddcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NiH7quLBgk+PF83LxOGVwFuKuQXFIuYoyp7V6hpdEe4=; b=CpTMpv/L38AP6Tzi6jSIiqpOPzzsDUB59texdhobh6+s5y13RQmbGZvQtKWy6VZX10 k4Ng1MTIt2i4jkJkPcxr/MakXEdJ1oHfaj6vBNoEQQg+zAeN44vU0V9Ot4MopdP0loaL fFxE6hYUE3tHUEUYTHhxETRqIS3BPUOZmeKSBTqTMOeb0cEbd3cUfRq7F8FtPaAcBGLQ wC4FT1hDoIov9XQWgrj3NFQpkttXYX0Ivnw7wcg12FG0Xw7eIrK568sBu3XUN2GVm2Xr x+QBKCFqGX0qGeLc9vllVn/V8/uFvqKqWF7vkt9GOnxQFgw2OTEQ9wMDrhJfAzyYo7ZT vi6A== X-Gm-Message-State: APjAAAUQAf/oDcNaMZHxDrcCX847ZZHfoEMHM2mRf/A6cVRqQND+ch0t LuCFCH5enEVKSj5FnYTIuTsZPwP55shEWDQxCW8= X-Google-Smtp-Source: APXvYqwdyJHagCX8F9MdQisJMyQVhR5Imju16OGYBdFfvV//32J6ZZ1EN4M0s/IH0Wk+BQMHaiyDbQ9hMIhDSRt44LY= X-Received: by 2002:a05:6830:210f:: with SMTP id i15mr19853194otc.250.1563196104379; Mon, 15 Jul 2019 06:08:24 -0700 (PDT) MIME-Version: 1.0 References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> In-Reply-To: From: Kathleen Moriarty Date: Mon, 15 Jul 2019 09:07:48 -0400 Message-ID: To: Eliot Lear Cc: Eric Rescorla , Stephen Farrell , smart@irtf.org, Dominique Lazanski , IETF SecDispatch Content-Type: multipart/alternative; boundary="0000000000008413a2058db7f43f" Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 13:08:28 -0000 --0000000000008413a2058db7f43f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 15, 2019 at 8:20 AM Eliot Lear wrote: > Hi Eric, > > On 15 Jul 2019, at 13:31, Eric Rescorla wrote: > >> >> When you say =E2=80=9Cnetwork=E2=80=9D do you mean the botnet or the wir= ed network >> connecting devices? >> > > Well, from the perspective of the receiver of traffic, these are kind of > the same thing, because you're just receiving packets. > > I agree it's a bit of an awkward fit, and I wish 3552 talked more about > compromised counterparties -- this is mostly due to my comsec orientation= , > I agree -- but I'm not sure that it would change what work we do=E2=80=A6 > > > > Right. From the perspective of 3352 I would have to agree as well, > because it is about security considerations relating to a specific protoc= ol > mechanism that *we *are defining and not a broad device threat model.(*) > The work areas for security have expanded out since 3552 was written and the security area largely has 2 focus groups now. The SACM, RATS, and incident response work such as MILE and DOTS cover some of these points that could better fill out a revision of 3552 along the lines of what this draft is getting at. My hope is that this will help with traction for work to improve control management and attestation adoption as SACM and RATS progress (MUD too). Eliot pointed out NEA, there have been efforts previously that have had limited adoption that help in these scenarios. The time to detect attacks in well managed networks with tight monitoring of security controls is significantly less than those that are not monitored. These are IETF and not IRTF efforts, but a change in the threat model and more focus in 3552 could be beneficial. There are thousands of YANG modules that went through to publication where it was possible to add monitoring capabilities for security related configurations, but this didn't happen. If the IETF expressed this as a concern and area of focus, we get get more people interested to do the work. Since controls will shift to the endpoint with strong encryption, the shift in control management to the endpoint and us ensuring it's baked in where possible will aid in the adoption of strong transport encryption. > > That having been said, I still think the iRtf should be looking more at > the latter with an eye toward finding new mechanisms that might improve t= he > overarching Internet security posture. Sorry for beating this drum, and = I > realize that there are often better publication venues for academics, but > the IRTF can inform the IETF and broader community about what the threats > are, and maybe even how to plug them in an economical fashion. > I do think there is work for the IRTF as well and would like to see that encouraged. The shift to strong encryption is good, but upends the current security management models for many. Best regards, Kathleen > > Eliot > > (*) Parenthetically while it=E2=80=99s amazing how long that doc has with= stood the > test of time (congratulations!), 3552 probably *could *use at least a > review for other reasons. The IETF has delivered some really good > capabilities in the last 16 years, and some of those, like TLS 1.3 and QU= IC > probably deserve honorable mention. I also wonder whether we should be > pushing common coding approaches in terms of REST, etc, rather than peopl= e > reinventing approaches. > --=20 Best regards, Kathleen --0000000000008413a2058db7f43f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 15, 2019 at 8:20 AM Eliot= Lear <lear@cisco.com> wrote:
Hi Eric,

On 15 Jul 2019, at 13:31, Eric Rescorla <ekr@rtfm.com> wrote:

When you say =E2=80=9Cnetwork=E2=80=9D do = you mean the botnet or the wired network connecting devices?

Well, from the perspective of the rece= iver of traffic, these are kind of the same thing, because you're just = receiving packets.

I agree it's a bit of an aw= kward fit, and I wish 3552 talked more about compromised counterparties -- = this is mostly due to my comsec orientation, I agree -- but I'm not sur= e that it would change what work we do=E2=80=A6


Right.=C2=A0 From the perspective of= 3352 I would have to agree as well, because it is about security considera= tions relating to a specific protocol mechanism that we are defining= and not a broad device threat model.(*)

<= /div>
The work areas for security have expanded out since 3552 was writ= ten and the security area largely has 2 focus groups now.=C2=A0 The SACM, R= ATS, and incident response work such as MILE and DOTS cover some of these p= oints that could better fill out a revision of 3552 along the lines of what= this draft is getting at.=C2=A0 My hope is that this will help with tracti= on for work to improve control management and attestation adoption as SACM = and RATS progress (MUD too).=C2=A0 Eliot pointed out NEA, there have been e= fforts previously that have had limited adoption that help in these scenari= os.=C2=A0 The time to detect attacks in well managed networks with tight mo= nitoring of security controls is significantly less than those that are not= monitored.=C2=A0=C2=A0

These are IETF and not IRT= F efforts, but a change in the threat model and more focus in 3552 could be= beneficial.=C2=A0 There are thousands of YANG modules that went through to= publication where it was possible to add monitoring capabilities for secur= ity related configurations, but this didn't happen.=C2=A0 If the IETF e= xpressed this as a concern and area of focus, we get get more people intere= sted to do the work.=C2=A0 Since controls will shift to the endpoint with s= trong encryption, the shift in control management to the endpoint and us en= suring it's baked in where possible will aid in the adoption of strong = transport encryption.

=C2=A0

That having been said, I still think the iRtf should b= e looking more at the latter with an eye toward finding new mechanisms that= might improve the overarching Internet security posture.=C2=A0 Sorry for b= eating this drum, and I realize that there are often better publication ven= ues for academics, but the IRTF can inform the IETF and broader community a= bout what the threats are, and maybe even how to plug them in an economical= fashion.

I do think there is w= ork for the IRTF as well and would like to see that encouraged.=C2=A0 The s= hift to strong encryption is good, but upends the current security manageme= nt models for many.

Best regards,
Kathle= en
=C2=A0
=

Eliot

(*) Parenthetically while it=E2=80=99s amazing how long t= hat doc has withstood the test of time (congratulations!), 3552 probably=C2= =A0could use at least a review for other reasons.=C2=A0 The IETF has= delivered some really good capabilities in the last 16 years, and some of = those, like TLS 1.3 and QUIC probably deserve honorable mention.=C2=A0 I al= so wonder whether we should be pushing common coding approaches in terms of= REST, etc, rather than people reinventing approaches.


--

Best regards,
Kathlee= n
--0000000000008413a2058db7f43f-- From nobody Mon Jul 15 07:50:25 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6014B12016B for ; Mon, 15 Jul 2019 07:50:24 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 eC_WuVP-HThw for ; Mon, 15 Jul 2019 07:50:22 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 E095B120116 for ; Mon, 15 Jul 2019 07:50:22 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id u17so7828412pgi.6 for ; Mon, 15 Jul 2019 07:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JLPuo2OVxed6SkGZsCOFYnhf0veQ4fefMur2lkQpciM=; b=ldmdXjXcf2DPsKcE2hmNoJDIg5VwpAhyiUlSUI7bMfU6RKa8D5szTCnEfCSjFSULKQ 6dV/RuMHHSyJP/9T8JCWGiclm3jcv3nE7cWgpm4s9E71BBgmj2SHuZ5R+HgrjJc2DLfl 9TmA4GSWlq4D2Opse8jiksQON4UXnXneg/8s9vwc8JB2bLK4bvgHQoO1+h9vjvXiosmW 0J+6PAk7o2anpW4kafad59PwREx4nsJ+FKqFVzHji9ePcbaRHf7X+QFqKV/qb2KnjZKw DzNOTsPllKh7C9PmDnQxZQv+la6cgm0fVzLAPAjCU3DDJuDvIZkLTSDk0iflbkqUI4LK BSdQ== 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=JLPuo2OVxed6SkGZsCOFYnhf0veQ4fefMur2lkQpciM=; b=clnoFFlQC/GYrILBjlZaSusl8dFRTFQGwW+6LcwXMRKuK4Lg7ZkP5ROXTr/wyQQkjJ lddJgZdbUF3pCnQh11UsKT5+E7b2TAWv/fOQs8qqT5Wz8n6jGc17YZ4NYHc1C+t2XaTV WyU+i18uztm3NPvMbpH3HrXiUZ4vIWYwvMcl+xLd6FfdkwAScS04ixJzsIhb/b+9nNYO hRkNDskvBDNG0IEMX9iFEBIOkgsvfkhrWOjvcxe8acTlpYmL3Vd+Xe/rcYsp8LJkjIjx K7eB6pK4ww6Qb0MmUxo3J52CJJcBZceGLWjUeN7SbuzBWuWtiMLpXM0eHdz6q8dPSV6m db7Q== X-Gm-Message-State: APjAAAVNDfCDS4ZgXTFQ8Mv+gTk+10wcrnl2EA3tHXwHvjZpyqz5kk/Y lKVcEw8z1u84+OFL3bZU9yI= X-Google-Smtp-Source: APXvYqw1erdgq9mZ0LM3FxbCjrIMTtsCaBjfm+74+b0MWItfoJJcdhdbvDlL3ZEczBQdHorBKviZ7g== X-Received: by 2002:a63:7358:: with SMTP id d24mr27355311pgn.224.1563202222445; Mon, 15 Jul 2019 07:50:22 -0700 (PDT) Received: from ?IPv6:2605:a601:a990:4d00:c449:d519:8ae0:afe7? ([2605:a601:a990:4d00:c449:d519:8ae0:afe7]) by smtp.gmail.com with ESMTPSA id p19sm21872629pfn.99.2019.07.15.07.50.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jul 2019 07:50:21 -0700 (PDT) From: Bret Jordan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8E2B2E27-5B60-40A3-9A94-FAF44A31223A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 15 Jul 2019 08:50:18 -0600 In-Reply-To: Cc: Eliot Lear , smart@irtf.org, Eric Rescorla , Dominique Lazanski , IETF SecDispatch , Stephen Farrell To: Kathleen Moriarty References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 14:50:25 -0000 --Apple-Mail=_8E2B2E27-5B60-40A3-9A94-FAF44A31223A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Kathleen, > I do think there is work for the IRTF as well and would like to see = that encouraged. The shift to strong encryption is good, but upends the = current security management models for many. This is one of the points I made during my talk at RSA. These = technologies by themselves, are all really great. The problem comes is = when you start using all of them together. To the naive comment earlier = that this is about vendors trying to sell product, no, this is about = network and cyber defenders and SoC analysts trying to do their job. = There are things like regulatory compliance that organizations and = enterprises are required to follow. Some times I feel like we are so = worried about one piece of the security pie, that we completely neglect = the others.=20 Here in the IETF everyone needs to better understand how SoC analysts = and network/cyber defenders do their jobs, what they are asked to do, = and what tools are available to them.=20 Bret= --Apple-Mail=_8E2B2E27-5B60-40A3-9A94-FAF44A31223A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Kathleen,


I do think there is work for the IRTF as well and would like = to see that encouraged.  The shift to strong encryption is good, = but upends the current security management models for = many.

This is = one of the points I made during my talk at RSA.  These technologies = by themselves, are all really great.  The problem comes is when you = start using all of them together.  To the naive comment earlier = that this is about vendors trying to sell product, no, this is about = network and cyber defenders and SoC analysts trying to do their job. = There are things like regulatory compliance that organizations and = enterprises are required to follow. Some times I feel like we are so = worried about one piece of the security pie, that we completely neglect = the others. 

Here in the IETF = everyone needs to better understand how SoC analysts and network/cyber = defenders do their jobs, what they are asked to do, and what tools are = available to them. 

Bret
= --Apple-Mail=_8E2B2E27-5B60-40A3-9A94-FAF44A31223A-- From nobody Mon Jul 15 08:07:34 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971F712015C for ; Mon, 15 Jul 2019 08:07:27 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 ixF1w-rWw6qt for ; Mon, 15 Jul 2019 08:07:24 -0700 (PDT) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 28B4F120167 for ; Mon, 15 Jul 2019 08:07:24 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id az7so8432709plb.5 for ; Mon, 15 Jul 2019 08:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9An9YjiEvFHUQTK28Q5c1nYoLy5wPreotca4uLsJF6E=; b=XIVKhzCHmW32nTSlc6mhG1ZKcG2RDN6PIa9AcRcmxyeZSw/VWm1dyRRVxnitOBYfVs RLvyrpHUpbmvZ5gFjYedz+gr3ieW+6SItC0QalqUGRmRvbGXoatwmdWS3bfOnBqNaJEH J9u7v/4wmqzTj+iT4kju7K2EsIyeVIwW8yYQAewKFfchmY/knOXjO3VvKo+B2NSI1E1W eGuBaA/vWo/TW2BzO9bOys/lO67xb7wDWh5aXiibdLRpATBFg+1w97DEgjY0Vzs0H/94 oRANApc9BOuyY3JMHnIsF7CEY5fgnlcTFFveAXFWS20sER77/9JYaZKyZOfvprE+hTCd ywpg== 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=9An9YjiEvFHUQTK28Q5c1nYoLy5wPreotca4uLsJF6E=; b=ZFAthBcpkvAHPCnvNgR9LNkQ5FFB2/WGCbJVNAlIUjaxcUv5dp/DDqjDhH4rb3XjKy 8DZp2eb7MxuIFQjpdaMKmSaOB5Jx6X7xvA9//vgxRS9eFgI8L+UiWyFRe7Bns3WyVtbW M8DNK+vnT8+4YD5W+2k9Fu+McxNGPDVXSTdErNe+2Ev6zQaMv8J1zDwc4mv8602jzEbd i2QOKM1MCEf+1F1RBLHUEaVAgvIgjSjxzx3KCNJihHJtkiUaUZ4bGKxtq9eebUAsVf+R Ul9vUQHa/aKxIfx41Jp6gFfqrL5T8L2N9Su/1r+hRTCOBgfks3y2Y2ljfeyBnrkYLUTl xJBg== X-Gm-Message-State: APjAAAVDRgClM2mQgj1YOBGwq63YX/qB3sZ6gARZuwE+4dwzogqcH/aL fDVeA54dF9F47tVBmK4WOnA= X-Google-Smtp-Source: APXvYqxGhwyHJJBn/hxtblcp/yUV+EtvlSt8CvCwGpjlclMa/I6HZkabNdtg85YyqOYtTQm0Ly9Frg== X-Received: by 2002:a17:902:e287:: with SMTP id cf7mr28613368plb.32.1563203243740; Mon, 15 Jul 2019 08:07:23 -0700 (PDT) Received: from ?IPv6:2605:a601:a990:4d00:c449:d519:8ae0:afe7? ([2605:a601:a990:4d00:c449:d519:8ae0:afe7]) by smtp.gmail.com with ESMTPSA id p15sm16802880pjf.27.2019.07.15.08.07.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jul 2019 08:07:22 -0700 (PDT) From: Bret Jordan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D8AD0D2F-7809-4D28-807C-1CE9250CE918" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 15 Jul 2019 09:07:19 -0600 In-Reply-To: <469416D4-F549-4CAD-9C81-3D4A5A271B6A@cisco.com> Cc: Melinda Shore , secdispatch@ietf.org, smart@irtf.org To: Eliot Lear References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <45cc67f6-3dd4-9788-29e5-4cc82471e6ee@nomountain.net> <9683DFBC-1816-4C0A-8D8A-4CE36318C72C@cisco.com> <469416D4-F549-4CAD-9C81-3D4A5A271B6A@cisco.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 15:07:28 -0000 --Apple-Mail=_D8AD0D2F-7809-4D28-807C-1CE9250CE918 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Eliot, However, many here assume that the endpoint can run security software, = that security software is available for all endpoints, or that security = software can be updated all at once across an organization/enterprise. = Other also assume that if you just patched your software, you would be = safe. These assumptions are horribly wrong and goes to show the = fundamental lack of understanding. The reason I called them out the way I did was I was trying to be = explicitly clear on where the attack was coming from and what role the = endpoint had in that attack. I did not want to assume that everyone = understood the attack surface and threat model.=20 So a client may initiate the connection to a compromised site or = content. This is a very common case for initial infection. However, = once the threat actor is in the network, they often move laterally = through the network and compromise machines where the attack is not = initiated from the victim endpoint, but rather initiated from a = compromised endpoint. So what you can see and do to protect your network = changes.=20 All of this is pretty basic network/cyber security 101 stuff. What the = IETF needs to know is how SoC analysts need and require sensors on the = network, network log data, and DNS data to help identify these attacks = and find them. We always had a saying when I was on the other side of = the fence, =E2=80=9Coperating systems and software can always be made to = lie, but the network never does..=E2=80=9D Network analysis and network = forensics is a critical part of the day-to-day analysis in a SoC. This = is often how intrusion sets are detected and threat actors behavior in = the network is tracked. This is not about selling product as some = believe. This is about organizations and enterprises protecting their = systems, networks, and data. =20 Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Jul 15, 2019, at 2:01 AM, Eliot Lear wrote: >=20 > Hi Bret, >=20 >>=20 >> 1) Is the content or content provider that the user is going to = compromised and trying to attack the endpoint? >> 2) Is the content provider that the user is going to a stage 2 = delivery site? >> 3) Is the content provider that the user is going to the location for = outbound malicious content (data exfiltration, CnC traffic) >> 4) Is the content provider that the user is going to adversely = tracking and monitoring everything the end client does, aka active = surveillance versus passive surveillance? >> 5) Is the remote site that the user did not go to attack the end = point. >=20 > While we tend to think of endpoints as being equivalent in class, in = which case your use of the term "content provider=E2=80=9D would be = somewhat redundant, from a scaling perspective I am far more concerned = about unwatched unmanaged endpoints than I am about content services. = And again, to me it is a matter of what problems I think might be = tractable. >=20 > Eliot --Apple-Mail=_D8AD0D2F-7809-4D28-807C-1CE9250CE918 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Eliot,

However, many here assume that the endpoint can run security = software, that security software is available for all endpoints, or that = security software can be updated all at once across an = organization/enterprise. Other also assume that if you just patched your = software, you would be safe.  These assumptions are horribly wrong = and goes to show the fundamental lack of understanding.

The reason I called them = out the way I did was I was trying to be explicitly clear on where the = attack was coming from and what role the endpoint had in that attack. I = did not want to assume that everyone understood the attack surface and = threat model. 

So a client may initiate the connection to a compromised site = or content. This is a very common case for initial infection. =  However, once the threat actor is in the network, they often move = laterally through the network and compromise machines where the attack = is not initiated from the victim endpoint, but rather initiated from a = compromised endpoint. So what you can see and do to protect your network = changes. 

All of this is pretty basic network/cyber security 101 stuff. =  What the IETF needs to know is how SoC analysts need and require = sensors on the network, network log data, and DNS data to help identify = these attacks and find them. We always had a saying when I was on the = other side of the fence, =E2=80=9Coperating systems and software can = always be made to lie, but the network never does..=E2=80=9D Network = analysis and network forensics is a critical part of the day-to-day = analysis in a SoC.  This is often how intrusion sets are detected = and threat actors behavior in the network is tracked.  This is not = about selling product as some believe. This is about organizations and = enterprises protecting their systems, networks, and data. =  

Bret 

Sent from my C= ommodore 128D

PGP Finger= print: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050<= /span>

On Jul 14, 2019, at 4:56 AM, E= liot Lear <lear@cisco.com> wrote= :

Hi Melinda,<= /span>

We
typically deal with wireline proto= cols and their support
structures, and I'm hoping that as the discussions progress
people can be clear about what they= 'd like to see from the
IETF.

I think you=E2=80=99r= e primarily referring to leaky user databases here.  I agree with you t= hat we cannot fix organizations=E2=80=99 bad internal code with a wireline p= rotocol.  However, to exploit the vulnerability, the attack had to come= from somewhere.  We already have one mechanism to address profiling wi= th IoT that manufacturers can use to keep their systems from being exploited= as BoTs.  The next question is whether we should be promoting or impro= ving other mechanisms to provide people at home and elsewhere more visibilit= y in terms of what their general purpose computing devices are doing.  = I=E2=80=99m thinking of PCP in particular.  And while there may be more= we can do, there may also be some limitations relating not only to privacy b= ut also economics of web services.

What I l= ike about Dominique=E2=80=99s draft is that it gets us thinking in those dir= ections (or at least it did me).


I do= think that some of this may be appropriate for opsec,
as well, or at least should be called to t= heir attention.

Or an RG or a s= ide meeting.  It would be fun to continue the discussion.

Eliot


Melinda

=
--
Melinda Shore
= melinda.shore@nomounta= in.net
Software longa, hardware brevi= s




__________________________= _____________________
Secdispatch mailing list
Secdispatch@ietf.orghttps:= //www.ietf.org/mailman/listinfo/secdispatch
Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Jul 15, 2019, at 2:01 AM, Eliot Lear <lear@CISCO.COM> = wrote:

Hi Bret,


1) Is the content or content provider that = the user is going to compromised and trying to attack the endpoint?
2) Is the content provider that the user is going to a stage = 2 delivery site?
3) Is the content provider that the user = is going to the location for outbound malicious content (data = exfiltration, CnC traffic)
4) Is the content provider that = the user is going to adversely tracking and monitoring everything the = end client does, aka active surveillance versus passive surveillance?
5) Is the remote site that the user did not go to attack the = end point.

While we tend to = think of endpoints as being equivalent in class, in which case your use = of the term "content provider=E2=80=9D would be somewhat redundant, from = a scaling perspective I am far more concerned about unwatched unmanaged = endpoints than I am about content services.  And again, to me it is = a matter of what problems I think might be tractable.

Eliot

= --Apple-Mail=_D8AD0D2F-7809-4D28-807C-1CE9250CE918-- From nobody Mon Jul 15 08:26:36 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32B312017C for ; Mon, 15 Jul 2019 08:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 qmoS2deUhWid for ; Mon, 15 Jul 2019 08:26:27 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C4B120193 for ; Mon, 15 Jul 2019 08:26:27 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id z28so16715796ljn.4 for ; Mon, 15 Jul 2019 08:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OWDyWD33hzbv9s0lcBRqtrRbzGS1jUX+gGSbwjHKLXc=; b=cDAXH+iKAJcPHMe8JQ/q3gDcURoEddX/yM3ci4+VOHZ5hYlVzWa7v96k1IplBXU8TD iuFeNC6bhF12frJc+m0rsYYeG5a3B0gmR+pIgnKiMElQDbtz0rFsn4RKo6lkb7/oyfKx gBDXkF8R/P5SLSqArlG20DyYn8CRIx3sgkSCjHQ0vLQRS9Y78LwRbe8HtsI9zOaqTmlx YXDuA2JmGv2rugkfTKa+QKDq7d2jRwUhi7PvqywbG8/qW2i9Nl12J6vK8/BqqYOs1vA4 9gnSeZWfk3vlnAQqRaav5uk0YOjlHXCVqeKL8FV6chlh9T7kOEgo8dwjfozKMbgCHdvC jbTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OWDyWD33hzbv9s0lcBRqtrRbzGS1jUX+gGSbwjHKLXc=; b=bk2GyllF4ZSGwPtJNCyEpkvczCh0XtKRPS8rlr2uptXhgEmzPNceSuOZqELkvLcVg3 kU2kfNCkkLMSk6uyqsRFujVMYoNOhJp85mZfZndbNJpeNV4J/U81RouExX5B42ghr92h IQCD1ai9dFfp9DYyErWeValhHm3iv6pMEJqi3G89mQjr5sG/vcRItEqZz9cV8NN2xNW9 eeJrXfSkuEzK7bfTBypGlO4JgOFcoEiqB/6VrLmaV8Zv1q+1WHa4jTueq+oonoQNrKjL GSIGFKs1bU3uoc0axk04nGDKbqAW7JDSoiYfK3xFyNp2M9qam23kiC4TxnlLpWDIJHgw IPQQ== X-Gm-Message-State: APjAAAX2Hwn5vAeTQMYPIAxJiahtmBAnOXmlMK3G11/QXncwSDINRf4l 3UQkHwfc+ZWvCTfq5fPqFnexygALfEP98kJ9Ar8= X-Google-Smtp-Source: APXvYqzbwgvNI1gH8/uEuYdCkB+zE3OQmp3i3fDb6n7kTwu1QzHCHRI7vpDobbW1nEEP4TwdGl1ZDllMGdSEZRqyAFo= X-Received: by 2002:a2e:8892:: with SMTP id k18mr14680637lji.239.1563204385337; Mon, 15 Jul 2019 08:26:25 -0700 (PDT) MIME-Version: 1.0 References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> In-Reply-To: From: Eric Rescorla Date: Mon, 15 Jul 2019 08:25:48 -0700 Message-ID: To: Bret Jordan Cc: Kathleen Moriarty , Eliot Lear , smart@irtf.org, Dominique Lazanski , IETF SecDispatch , Stephen Farrell Content-Type: multipart/alternative; boundary="0000000000001982b2058db9e2e1" Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 15:26:30 -0000 --0000000000001982b2058db9e2e1 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 15, 2019 at 7:50 AM Bret Jordan wrote: > Kathleen, > > > I do think there is work for the IRTF as well and would like to see that > encouraged. The shift to strong encryption is good, but upends the current > security management models for many. > > > This is one of the points I made during my talk at RSA. These > technologies by themselves, are all really great. The problem comes is > when you start using all of them together. To the naive comment earlier > that this is about vendors trying to sell product, no, this is about > network and cyber defenders and SoC analysts trying to do their job. There > are things like regulatory compliance that organizations and enterprises > are required to follow. Some times I feel like we are so worried about one > piece of the security pie, that we completely neglect the others. > Bret, As I said before, this is extremely general and hard to act on. What would be most helpful at this point would be for you to describe a few ways in which you think the IETF should have designed protocols differently, so that we can discuss them. -Ekr > Here in the IETF everyone needs to better understand how SoC analysts and > network/cyber defenders do their jobs, what they are asked to do, and what > tools are available to them. > > Bret > --0000000000001982b2058db9e2e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Mon, Jul 15, 2019 at 7:50 AM Bret Jordan <jordan.ietf@gmail.com> wrote:=
Kathleen,<= div>

<= /div>
I do think there is work for the IRTF as well and would like to s= ee that encouraged.=C2=A0 The shift to strong encryption is good, but upend= s the current security management models for many.

This is one of the points I made during my talk at RSA= .=C2=A0 These technologies by themselves, are all really great.=C2=A0 The p= roblem comes is when you start using all of them together.=C2=A0 To the nai= ve comment earlier that this is about vendors trying to sell product, no, t= his is about network and cyber defenders and SoC analysts trying to do thei= r job. There are things like regulatory compliance that organizations and e= nterprises are required to follow. Some times I feel like we are so worried= about one piece of the security pie, that we completely neglect the others= .=C2=A0

Bret,
<= br>
As I said before, this is extremely general and hard to act o= n.

What would be most helpful at this point would = be for you to describe a few ways in which you think the IETF should have d= esigned protocols differently, so that we can discuss them.

<= /div>
-Ekr


Here in the IETF everyone needs to= better understand how SoC analysts and network/cyber defenders do their jo= bs, what they are asked to do, and what tools are available to them.=C2=A0<= /div>

Bret
--0000000000001982b2058db9e2e1-- From nobody Mon Jul 15 09:03:18 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12F2120045 for ; Mon, 15 Jul 2019 09:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 8U1CNXe9H3OS for ; Mon, 15 Jul 2019 09:03:15 -0700 (PDT) Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) (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 DFB23120088 for ; Mon, 15 Jul 2019 09:03:14 -0700 (PDT) Received: by mail-oi1-f175.google.com with SMTP id v186so13055497oie.5 for ; Mon, 15 Jul 2019 09:03:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A3NMHzTbFmd8amKtpXobfQ09YZpe852mIYIiZ8N/Afk=; b=iqBryusgwSHCAJ5fX2l+40Qj5pQ2v4bHUYFnpBtFc/BSLyFb99NjAPASb8YqXUZxA4 GABi0395UPcRmQBVm9oUYgSSKMelrcjx3jELimZ3xD4TWHrwL7mcYwFSHT4U+OKE1cUV jZX6aCIATMHc+1bgpCkS+/x9rRr7966uuC5Ryras/JeIkNHH8XIUoX/PiIrhCGb3zJnP shh8U/j4tolOBS5HRTLs1epirAq5YaoyBnFKkhVSGj6XTAEWtViEi3q8+dxnc/7v7F7e wsDFASoVceZq4HNvcxjQ9cn9EHaaW5fBD3F6xL3ZE1tcdLQ+qz7mCc8w0+iqLmhvKn0M Kocw== X-Gm-Message-State: APjAAAUFy76/pBWC6lsQf0L2MBmrsvVvYsNG7oLjcibKNCPjIV1A327w 6upLmC+JU7UAkpZNw2tXO4/upR/iy2XlQYwjVo8= X-Google-Smtp-Source: APXvYqzFqxl0IjWXJ6VsUKmp0LNovIDeYnKlWBu0d67Ipu4adFoYIKtAwsc4ag5C5XQllo4kLVUl7kHCVw8+PZNBbSE= X-Received: by 2002:aca:5883:: with SMTP id m125mr14119366oib.58.1563206594054; Mon, 15 Jul 2019 09:03:14 -0700 (PDT) MIME-Version: 1.0 References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <45cc67f6-3dd4-9788-29e5-4cc82471e6ee@nomountain.net> <9683DFBC-1816-4C0A-8D8A-4CE36318C72C@cisco.com> <469416D4-F549-4CAD-9C81-3D4A5A271B6A@cisco.com> In-Reply-To: From: Phillip Hallam-Baker Date: Mon, 15 Jul 2019 12:03:01 -0400 Message-ID: To: Bret Jordan Cc: Eliot Lear , smart@irtf.org, Melinda Shore , IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000bfcf54058dba6512" Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 16:03:17 -0000 --000000000000bfcf54058dba6512 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am pretty sure this is not security 101 stuff. In fact I am pretty sure that it will be quite a while before the academy really gets to grips with this stuff. They don't have the same biases we do but they have different ones. For example, the need to patch systems is brought up and this is almost always seen as a good thing. Not in the process control world it isn't. The problem of unauthorized updates is a very serious concern for them. Devices that automatically update themselves are vulnerable to a denial of service attack by the device provider. This is not an attack many device providers are worried about because it isn't an attack that is going to affect them (for a start) and they think they can trust themselves. Which may well not be true. I have seen a single employee cause $1 million worth of vandalism after being upset that his wages were being garnished for alimony. I really doubt that more than 5% of the companies that make IoT devices have effective controls. The same is true of devices that depend on a tied service. My Revolv hub is useless because Google bought the company and shut down the service leaving me with $2500 worth of dead equipment in my walls. This is not 101 stuff and in fact I don't think that a single one of the IoT vendors out there is showing that they understand it. We are still at what I call the 'narcissistic' phase of the market in which every medium sized IoT vendor thinks it is all about themselves. The fact that an IoT device makes the owner dependent on the provider is totally a security issue. The fact that the device providers don't want to acknowledge it doesn't make it any less so. I have spent well over $25,000 on IoT devices in the past few years. Of these, I cannot think of a single one that I can give an unqualified recommendation for. And there are security issues with every single one of them. On Mon, Jul 15, 2019 at 11:07 AM Bret Jordan wrote: > Eliot, > > However, many here assume that the endpoint can run security software, > that security software is available for all endpoints, or that security > software can be updated all at once across an organization/enterprise. > Other also assume that if you just patched your software, you would be > safe. These assumptions are horribly wrong and goes to show the > fundamental lack of understanding. > > The reason I called them out the way I did was I was trying to be > explicitly clear on where the attack was coming from and what role the > endpoint had in that attack. I did not want to assume that everyone > understood the attack surface and threat model. > > So a client may initiate the connection to a compromised site or content. > This is a very common case for initial infection. However, once the thre= at > actor is in the network, they often move laterally through the network an= d > compromise machines where the attack is not initiated from the victim > endpoint, but rather initiated from a compromised endpoint. So what you c= an > see and do to protect your network changes. > > All of this is pretty basic network/cyber security 101 stuff. What the > IETF needs to know is how SoC analysts need and require sensors on the > network, network log data, and DNS data to help identify these attacks an= d > find them. We always had a saying when I was on the other side of the > fence, =E2=80=9Coperating systems and software can always be made to lie,= but the > network never does..=E2=80=9D Network analysis and network forensics is a= critical > part of the day-to-day analysis in a SoC. This is often how intrusion se= ts > are detected and threat actors behavior in the network is tracked. This = is > not about selling product as some believe. This is about organizations an= d > enterprises protecting their systems, networks, and data. > > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that > can not be unscrambled is an egg." > > On Jul 15, 2019, at 2:01 AM, Eliot Lear wrote: > > Hi Bret, > > > 1) Is the content or content provider that the user is going to > compromised and trying to attack the endpoint? > 2) Is the content provider that the user is going to a stage 2 delivery > site? > 3) Is the content provider that the user is going to the location for > outbound malicious content (data exfiltration, CnC traffic) > 4) Is the content provider that the user is going to adversely tracking > and monitoring everything the end client does, aka active surveillance > versus passive surveillance? > 5) Is the remote site that the user did not go to attack the end point. > > > While we tend to think of endpoints as being equivalent in class, in whic= h > case your use of the term "content provider=E2=80=9D would be somewhat re= dundant, > from a scaling perspective I am far more concerned about unwatched > unmanaged endpoints than I am about content services. And again, to me i= t > is a matter of what problems I think might be tractable. > > Eliot > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --000000000000bfcf54058dba6512 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I a= m pretty sure this is not security 101 stuff. In fact I am pretty sure that= it will be quite a while before the academy really gets to grips with this= stuff. They don't have the same biases we do but they have different o= nes.=C2=A0

=
For example, t= he need to patch systems is brought up and this is almost always seen as a = good thing. Not in the process control world it isn't. The problem of u= nauthorized updates is a very serious concern for them.

Devices that automatically update themselves= are vulnerable to a denial of service attack by the device provider.
=

This is not an attack many dev= ice providers are worried about because it isn't an attack that is goin= g to affect them (for a start) and they think they can trust themselves. Wh= ich may well not be true. I have seen a single employee cause $1 million wo= rth of vandalism after being upset that his wages were being garnished for = alimony. I really doubt that more than 5% of the companies that make IoT de= vices have effective controls.

The same is true of devices that depend on a tied service. My Revolv = hub is useless because Google bought the company and shut down the service = leaving me with $2500 worth of dead equipment in my walls.

This is not 101 stuff and in fact I don&= #39;t think that a single one of the IoT vendors out there is showing that = they understand it. We are still at what I call the 'narcissistic' = phase of the market in which every medium sized IoT vendor thinks it is all= about themselves.


The fact that an= IoT device makes the owner dependent on the provider is totally a security= issue. The fact that the device providers don't want to acknowledge it= doesn't make it any less so.

I have spent well over $25,000 on IoT devices in the past few ye= ars. Of these, I cannot think of a single one that I can give an unqualifie= d recommendation for. And there are security issues with every single one o= f them.


On Mon, Jul 15, 2019 at 11:07 AM Bret Jordan <jordan.ietf@gmail.com> wrote:
Eliot,

However, many here assume that the endpoint= can run security software, that security software is available for all end= points, or that security software can be updated all at once across an orga= nization/enterprise. Other also assume that if you just patched your softwa= re, you would be safe.=C2=A0 These assumptions are horribly wrong and goes = to show the fundamental lack of understanding.

The= reason I called them out the way I did was I was trying to be explicitly c= lear on where the attack was coming from and what role the endpoint had in = that attack. I did not want to assume that everyone understood the attack s= urface and threat model.=C2=A0

So a client may ini= tiate the connection to a compromised site or content. This is a very commo= n case for initial infection.=C2=A0 However, once the threat actor is in th= e network, they often move laterally through the network and compromise mac= hines where the attack is not initiated from the victim endpoint, but rathe= r initiated from a compromised endpoint. So what you can see and do to prot= ect your network changes.=C2=A0

All of this is pre= tty basic network/cyber security 101 stuff.=C2=A0 What the IETF needs to kn= ow is how SoC analysts need and require sensors on the network, network log= data, and DNS data to help identify these attacks and find them. We always= had a saying when I was on the other side of the fence, =E2=80=9Coperating= systems and software can always be made to lie, but the network never does= ..=E2=80=9D Network analysis and network forensics is a critical part of th= e day-to-day analysis in a SoC.=C2=A0 This is often how intrusion sets are = detected and threat actors behavior in the network is tracked.=C2=A0 This i= s not about selling product as some believe. This is about organizations an= d enterprises protecting their systems, networks, and data. =C2=A0

Thanks,
Bret
= PGP Fingerprint:=C2=A063B4 FC53 680A 6B7D 1447 =C2=A0F2C0 74F8 ACAE 7415 00= 50
&qu= ot;Without cryptography vihv vivc ce xhrnrw, however, the only thing that c= an not be unscrambled is an egg."

On Jul 15, 2019, at 2:01 AM, Eliot = Lear <lear@CISCO.COM= > wrote:

Hi Bret,


1) Is= the content or content provider that the user is going to compromised and = trying to attack the endpoint?
2) Is the content provider that the user = is going to a stage 2 delivery site?
3) Is the content provider that the= user is going to the location for outbound malicious content (data exfiltr= ation, CnC traffic)
4) Is the content provider that the user is going to= adversely tracking and monitoring everything the end client does, aka acti= ve surveillance versus passive surveillance?
5) Is the remote site that = the user did not go to attack the end point.

While we t= end to think of endpoints as being equivalent in class, in which case your = use of the term "content provider=E2=80=9D would be somewhat redundant= , from a scaling perspective I am far more concerned about unwatched unmana= ged endpoints than I am about content services.=C2=A0 And again, to me it i= s a matter of what problems I think might be tractable.

Eliot

_______________________________= ________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--000000000000bfcf54058dba6512-- From nobody Mon Jul 15 09:16:36 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD281201E5 for ; Mon, 15 Jul 2019 09:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_HI=-5, 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 HDGlhUkH6HNS for ; Mon, 15 Jul 2019 09:16:32 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154F51201E4 for ; Mon, 15 Jul 2019 09:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9579; q=dns/txt; s=iport; t=1563207392; x=1564416992; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=N13LoiowyybiA01V642pR/uJJ3WHqu6HXtG7jhCpMqA=; b=bhb1ppWJV6GrAk8w6Y2owsQLtpcjf9+ZUVI5CslMUrCro0SFjQ5fMGxz KpEjyqQJ+OoZdyTk/tH+JEGxnYw5MKQ6AGSDfHycWuT/PzCNsGhjp8hUS CNZV6ZENH4EsT8Llvp7EG4Q8CNDtMmghFEMB+yqXpu0usjSxFhdt9YGKZ Y=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAAB9pixd/xbLJq1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVgIBAQEBCwGBZwWBOisBIBIohByIe4tTJZJ6h34CBwEBAQk?= =?us-ascii?q?DAQEvAQGEQAIOgno3Bg4BAwEBBAEBAgEFbYVIhUoBAQEBAgEjTQcCBQsLGBg?= =?us-ascii?q?SAgJXBhODIgGBew+rcIEyhUeEZhCBNAGBUIdFgmCBf4E4DBOBTlAuPoQoa4I?= =?us-ascii?q?7MoImBIwFTQKIHZUFbQmCG4IfgQyOLoIzG4ItlV2OZpMUgwsCBAYFAhWBZiI?= =?us-ascii?q?3B4EaMxoIGxVlAYFZaD6COm8BDI0TPQMwjX2CLgEB?= X-IronPort-AV: E=Sophos;i="5.63,494,1557187200"; d="asc'?scan'208,217";a="14262987" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jul 2019 16:16:30 +0000 Received: from ams3-vpn-dhcp3718.cisco.com (ams3-vpn-dhcp3718.cisco.com [10.61.78.134]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x6FGFWeN028388 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Jul 2019 16:16:29 GMT From: Eliot Lear Message-Id: <2E98BE46-174B-4423-976C-6EB48A3A714F@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_DB5207E9-3DF1-48CC-8377-66F138A7E1E5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 15 Jul 2019 18:16:29 +0200 In-Reply-To: Cc: Bret Jordan , smart@irtf.org, Melinda Shore , IETF SecDispatch To: Phillip Hallam-Baker References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <45cc67f6-3dd4-9788-29e5-4cc82471e6ee@nomountain.net> <9683DFBC-1816-4C0A-8D8A-4CE36318C72C@cisco.com> <469416D4-F549-4CAD-9C81-3D4A5A271B6A@cisco.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.78.134, ams3-vpn-dhcp3718.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 16:16:35 -0000 --Apple-Mail=_DB5207E9-3DF1-48CC-8377-66F138A7E1E5 Content-Type: multipart/alternative; boundary="Apple-Mail=_2BE77785-3AC0-4B0F-A62D-9BEE6E6AFA43" --Apple-Mail=_2BE77785-3AC0-4B0F-A62D-9BEE6E6AFA43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Phil, > On 15 Jul 2019, at 18:03, Phillip Hallam-Baker = wrote: >=20 > I am pretty sure this is not security 101 stuff. In fact I am pretty = sure that it will be quite a while before the academy really gets to = grips with this stuff. They don't have the same biases we do but they = have different ones. >=20 > For example, the need to patch systems is brought up and this is = almost always seen as a good thing. Not in the process control world it = isn't. The problem of unauthorized updates is a very serious concern for = them. I think I agree with your thesis statement but not your supporting = statement above. There are a great many =E2=80=9Cbest practices=E2=80=9D = that are coming out, and they all to a one usually involve usernames and = passwords for a good number of devices that might not require either. = And in fact, the idea of a password for machine controlled devices is = Just Bad. Patches themselves from the vendors are absolutely required to be = available, but the timing of their installation needs to be left to = customers based on when =E2=80=93 if at all =E2=80=93 those devices can = allow for a window where the device may miss a beat. But even in these = cases, process control systems need in service upgrade mechanisms, = because the reality is that the bugs will be there. >=20 > Devices that automatically update themselves are vulnerable to a = denial of service attack by the device provider. >=20 > This is not an attack many device providers are worried about because = it isn't an attack that is going to affect them (for a start) and they = think they can trust themselves. Which may well not be true. I have seen = a single employee cause $1 million worth of vandalism after being upset = that his wages were being garnished for alimony. I really doubt that = more than 5% of the companies that make IoT devices have effective = controls. Ok, but that is no reason to not have automated updates available. That = is more of a reason to have strong audit processes in place. >=20 > The same is true of devices that depend on a tied service. My Revolv = hub is useless because Google bought the company and shut down the = service leaving me with $2500 worth of dead equipment in my walls. >=20 > This is not 101 stuff and in fact I don't think that a single one of = the IoT vendors out there is showing that they understand it. We are = still at what I call the 'narcissistic' phase of the market in which = every medium sized IoT vendor thinks it is all about themselves. >=20 >=20 > The fact that an IoT device makes the owner dependent on the provider = is totally a security issue. The fact that the device providers don't = want to acknowledge it doesn't make it any less so. I agree that this is indeed a security issue, but that doesn=E2=80=99t = mean that it=E2=80=99s the wrong way to go. There are other factors to = take into consideration, not the least of which is cogs and e-Waste = associated with unnecessarily shipping extra horse power to 20 million = endpoints when a little elastic processing in the cloud will do. Eliot --Apple-Mail=_2BE77785-3AC0-4B0F-A62D-9BEE6E6AFA43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Phil,



On 15 Jul 2019, at 18:03, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

I am pretty sure this is not security 101 = stuff. In fact I am pretty sure that it will be quite a while before the = academy really gets to grips with this stuff. They don't have the same = biases we do but they have different ones. 

For example, the need to patch systems is = brought up and this is almost always seen as a good thing. Not in the = process control world it isn't. The problem of unauthorized updates is a = very serious concern for them.


I think I agree with = your thesis statement but not your supporting statement above. =  There are a great many =E2=80=9Cbest practices=E2=80=9D that are = coming out, and they all to a one usually involve usernames and = passwords for a good number of devices that might not require either. =  And in fact, the idea of a password for machine controlled devices = is Just Bad.

Patches themselves from = the vendors are absolutely required to be = available, but the timing of their installation needs to be left to = customers based on when =E2=80=93 if at all =E2=80=93 those devices can = allow for a window where the device may miss a beat.  But even in = these cases, process control systems need in service upgrade mechanisms, = because the reality is that the bugs will be there.



Devices that automatically update themselves = are vulnerable to a denial of service attack by the device = provider.

This is not an attack many device providers = are worried about because it isn't an attack that is going to affect = them (for a start) and they think they can trust themselves. Which may = well not be true. I have seen a single employee cause $1 million worth = of vandalism after being upset that his wages were being garnished for = alimony. I really doubt that more than 5% of the companies that make IoT = devices have effective controls.

Ok, but that is no reason to not have automated updates = available.  That is more of a reason to have strong audit processes = in place.


The same is true of devices that depend on a = tied service. My Revolv hub is useless because Google bought the company = and shut down the service leaving me with $2500 worth of dead equipment = in my walls.

This is not 101 stuff = and in fact I don't think that a single one of the IoT vendors out there = is showing that they understand it. We are still at what I call the = 'narcissistic' phase of the market in which every medium sized IoT = vendor thinks it is all about themselves.


The fact that an IoT = device makes the owner dependent on the provider is totally a security = issue. The fact that the device providers don't want to acknowledge it = doesn't make it any less so.

I agree that this is indeed a security issue, but that = doesn=E2=80=99t mean that it=E2=80=99s the wrong way to go.  There = are other factors to take into consideration, not the least of which is = cogs and e-Waste associated with unnecessarily shipping extra horse = power to 20 million endpoints when a little elastic processing in the = cloud will do.

Eliot

= --Apple-Mail=_2BE77785-3AC0-4B0F-A62D-9BEE6E6AFA43-- --Apple-Mail=_DB5207E9-3DF1-48CC-8377-66F138A7E1E5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXSym3QAKCRBugA9nE248 uLeqAJ9c4Rhwq3HmtlWZIlUSDDMg5GpkdACg7CibsPhcSwhl13CC3/lHvbBrKNU= =LUmE -----END PGP SIGNATURE----- --Apple-Mail=_DB5207E9-3DF1-48CC-8377-66F138A7E1E5-- From nobody Mon Jul 15 09:24:13 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F664120176 for ; Mon, 15 Jul 2019 09:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 Ig8L0xYnT54p for ; Mon, 15 Jul 2019 09:24:09 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 31E32120168 for ; Mon, 15 Jul 2019 09:24:09 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id u14so7666176pfn.2 for ; Mon, 15 Jul 2019 09:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=yHZnHZQT7W1VbBLWQy2PoMdnhJkjmXv/qcHKp6GSFhs=; b=M+5o1SR15lvoyjb0o+2ZWufsaaRpGFuTX1u115CWHkN+4aj7NKKWd/lRqWtVFZqsQ9 AYEttH8RFac2BvsLp0pazt2LHAMhJCFF2WgKJKi9gir5PxuVjfqyHYT5mVIwbJHdPkjh 5Dm3rCf5hSarjxz045+fKI34Jdc9gsExUVmG0acnW06vQnqcCdtHKYlCeD9Pt9SaVVFW 73mL2CvzqXBvgG/faLWoHd4cv8f9T0ThNJDUA+Q2wFadBBO6Xen6WG1yxw0k+Y0/jXxe zEUtGf8ITqY6C70kjFSxRbzVWBROc5sSg9UKxgm6xCwYxKPlGVL+Vl98hWTdcX8bPpD8 7yzw== 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=yHZnHZQT7W1VbBLWQy2PoMdnhJkjmXv/qcHKp6GSFhs=; b=FuN95XPeKccFCaRKbkBXi76PzyfYdU1WJ7dfb+eKPOehKIMQMKt6E2Ds6ywX+nbOUJ CUwPPH6XtJ2/Q/XEcq1GrcYMdH7VCAe4duoV2eTkvcLYoDbZ6/7HcXiYP4z/GNKOxflk g9Eb7dnRp5hbZA7QZlSozNW08wXNqrUp8zeYPRIZ0AQSQdlkyyiDsVcFqkCLNx8TooR4 Jh8Bn/xG1Wt/Fi5CV+oCqEKKS104crSwi4DX0BVVWrtaFFpFR6SlhsIi8ifK4aAkEyOS 4nbI3qPGqiwjOy294o51OpQm6c+k5lYe/79xuLCZbG4NeMVMH/WCRY/KUfCmNWAjitFU eq4Q== X-Gm-Message-State: APjAAAWBjWvaIswndKOuxw4+A55TlFjE36doQ1nhW6P3eNIE+yd/+GgZ w78pRR9W6Rh8OBueDf92Bd8= X-Google-Smtp-Source: APXvYqzemOfg7fCJHQZYUL4WDhv2zmEXKYX8+v5EkklN0v1BM1ehnBTQAeXFF/nRxjGjNBFiyOdc7A== X-Received: by 2002:a63:fd50:: with SMTP id m16mr27471960pgj.192.1563207848687; Mon, 15 Jul 2019 09:24:08 -0700 (PDT) Received: from ?IPv6:2605:a601:a990:4d00:a925:658c:7e16:1f17? ([2605:a601:a990:4d00:a925:658c:7e16:1f17]) by smtp.gmail.com with ESMTPSA id z2sm15997596pgg.58.2019.07.15.09.24.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jul 2019 09:24:07 -0700 (PDT) From: Bret Jordan Message-Id: <57C9DB3F-7694-45F1-A8AF-8BC242CC1383@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E2A33079-237E-45BF-8835-D2F9BF6D37BC" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 15 Jul 2019 10:24:05 -0600 In-Reply-To: <2E98BE46-174B-4423-976C-6EB48A3A714F@cisco.com> Cc: Phillip Hallam-Baker , smart@irtf.org, Melinda Shore , IETF SecDispatch To: Eliot Lear References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <45cc67f6-3dd4-9788-29e5-4cc82471e6ee@nomountain.net> <9683DFBC-1816-4C0A-8D8A-4CE36318C72C@cisco.com> <469416D4-F549-4CAD-9C81-3D4A5A271B6A@cisco.com> <2E98BE46-174B-4423-976C-6EB48A3A714F@cisco.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 16:24:12 -0000 --Apple-Mail=_E2A33079-237E-45BF-8835-D2F9BF6D37BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My key points were due to the responses I hear form some in the IETF, = specifically =E2=80=9CIf you just patched your endpoints there would be no issue=E2=80=9D= =E2=80=9CAll endpoints can easily run security software=E2=80=9D Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Jul 15, 2019, at 10:16 AM, Eliot Lear wrote: >=20 > Phil, >=20 >=20 >=20 >> On 15 Jul 2019, at 18:03, Phillip Hallam-Baker > wrote: >>=20 >> I am pretty sure this is not security 101 stuff. In fact I am pretty = sure that it will be quite a while before the academy really gets to = grips with this stuff. They don't have the same biases we do but they = have different ones.=20 >>=20 >> For example, the need to patch systems is brought up and this is = almost always seen as a good thing. Not in the process control world it = isn't. The problem of unauthorized updates is a very serious concern for = them. >=20 >=20 > I think I agree with your thesis statement but not your supporting = statement above. There are a great many =E2=80=9Cbest practices=E2=80=9D = that are coming out, and they all to a one usually involve usernames and = passwords for a good number of devices that might not require either. = And in fact, the idea of a password for machine controlled devices is = Just Bad. >=20 > Patches themselves from the vendors are absolutely required to be = available, but the timing of their installation needs to be left to = customers based on when =E2=80=93 if at all =E2=80=93 those devices can = allow for a window where the device may miss a beat. But even in these = cases, process control systems need in service upgrade mechanisms, = because the reality is that the bugs will be there. >=20 >=20 >>=20 >> Devices that automatically update themselves are vulnerable to a = denial of service attack by the device provider. >>=20 >> This is not an attack many device providers are worried about because = it isn't an attack that is going to affect them (for a start) and they = think they can trust themselves. Which may well not be true. I have seen = a single employee cause $1 million worth of vandalism after being upset = that his wages were being garnished for alimony. I really doubt that = more than 5% of the companies that make IoT devices have effective = controls. >=20 > Ok, but that is no reason to not have automated updates available. = That is more of a reason to have strong audit processes in place. >=20 >>=20 >> The same is true of devices that depend on a tied service. My Revolv = hub is useless because Google bought the company and shut down the = service leaving me with $2500 worth of dead equipment in my walls. >>=20 >> This is not 101 stuff and in fact I don't think that a single one of = the IoT vendors out there is showing that they understand it. We are = still at what I call the 'narcissistic' phase of the market in which = every medium sized IoT vendor thinks it is all about themselves. >>=20 >>=20 >> The fact that an IoT device makes the owner dependent on the provider = is totally a security issue. The fact that the device providers don't = want to acknowledge it doesn't make it any less so. >=20 > I agree that this is indeed a security issue, but that doesn=E2=80=99t = mean that it=E2=80=99s the wrong way to go. There are other factors to = take into consideration, not the least of which is cogs and e-Waste = associated with unnecessarily shipping extra horse power to 20 million = endpoints when a little elastic processing in the cloud will do. >=20 > Eliot >=20 --Apple-Mail=_E2A33079-237E-45BF-8835-D2F9BF6D37BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My = key points were due to the responses I hear form some in the IETF, = specifically

=E2=80=9C= If you just patched your endpoints there would be no issue=E2=80=9D
<= div class=3D"">=E2=80=9CAll endpoints can easily run security = software=E2=80=9D



Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Jul 15, 2019, at 10:16 AM, Eliot Lear <lear@CISCO.COM> = wrote:

Phil,


On 15 = Jul 2019, at 18:03, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

I am pretty sure this is not security 101 = stuff. In fact I am pretty sure that it will be quite a while before the = academy really gets to grips with this stuff. They don't have the same = biases we do but they have different ones. 

For example, the need to patch systems is = brought up and this is almost always seen as a good thing. Not in the = process control world it isn't. The problem of unauthorized updates is a = very serious concern for them.


I think I agree with your thesis statement but not your = supporting statement above.  There are a great many =E2=80=9Cbest = practices=E2=80=9D that are coming out, and they all to a one usually = involve usernames and passwords for a good number of devices that might = not require either.  And in fact, the idea of a password for = machine controlled devices is Just Bad.

Patches themselves from the vendors are = absolutely required to be available, but the = timing of their installation needs to be left to customers based on when = =E2=80=93 if at all =E2=80=93 those devices can allow for a window where = the device may miss a beat.  But even in these cases, process = control systems need in service upgrade mechanisms, because the reality = is that the bugs will be there.



Devices that automatically update themselves = are vulnerable to a denial of service attack by the device = provider.

This is not an attack many device providers = are worried about because it isn't an attack that is going to affect = them (for a start) and they think they can trust themselves. Which may = well not be true. I have seen a single employee cause $1 million worth = of vandalism after being upset that his wages were being garnished for = alimony. I really doubt that more than 5% of the companies that make IoT = devices have effective controls.

Ok, but that is no reason to not have = automated updates available.  That is more of a reason to have = strong audit processes in place.


The same is true of = devices that depend on a tied service. My Revolv hub is useless because = Google bought the company and shut down the service leaving me with = $2500 worth of dead equipment in my walls.

This is not 101 stuff and in fact I don't = think that a single one of the IoT vendors out there is showing that = they understand it. We are still at what I call the 'narcissistic' phase = of the market in which every medium sized IoT vendor thinks it is all = about themselves.


The fact that an IoT device makes the owner = dependent on the provider is totally a security issue. The fact that the = device providers don't want to acknowledge it doesn't make it any less = so.

I = agree that this is indeed a security issue, but that doesn=E2=80=99t = mean that it=E2=80=99s the wrong way to go.  There are other = factors to take into consideration, not the least of which is cogs and = e-Waste associated with unnecessarily shipping extra horse power to 20 = million endpoints when a little elastic processing in the cloud will = do.

Eliot


= --Apple-Mail=_E2A33079-237E-45BF-8835-D2F9BF6D37BC-- From nobody Mon Jul 15 10:02:36 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC291201E0 for ; Mon, 15 Jul 2019 10:02:25 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 7SHqOW4UMTtB for ; Mon, 15 Jul 2019 10:02:24 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 296571201EC for ; Mon, 15 Jul 2019 10:02:17 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id z75so8003468pgz.5 for ; Mon, 15 Jul 2019 10:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bbvN+6WQO48xJUmt7zYKXGwf7rFwSwcvFIYLA3WzvWc=; b=JqYpU/+3gZVEotgozAgkr+oCXGhpepcz+6+U2yIyfzr+g/KEQ484n9xB4BAXsM7iEj J7H/5ZJ/CEtpxNxrg0FKaROOJp7x7myMpx1DhHHMjOC2/hghI8dffyFVl8bgV+HIAvDb EK7VTn2iPX3bqR+DdEAoo9/YorebtrCbfybOXxZmLPr1GxNUEuIHnNf9T16eFMCdN3Tg fVs2MGL1pr4SAV/AgUk3N+6Lw8X6fnoEmwd4CTjvtWmToM6KEqlG1FeW3qEgp5T5KUo3 v/6NA0zVR2vOU0b0QPi+O3aOJPf1tPHdbhjFREmGI9iLbTnC78LYTpcwDf6CW6ynRP1N PRIQ== 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=bbvN+6WQO48xJUmt7zYKXGwf7rFwSwcvFIYLA3WzvWc=; b=Cyo8UqoLKztKGmNPy3KH9K0jM/86zRxjxM/YG1DEunFr/NuyyJ+AHPzX439qiSJWie xST7kxZJzeW4x4i17qcQR5IGhdAvuYwarOGvbVJh1CduF1iOJLlHUKGcExtaDFcim/NE rPgyn2aGtmALXzllYj5axgrw+V3XmhiaXheTF7d8+VkJlNWRDBrSzYXL6YDHm0SM13/n 8Ja98IxO1aEUs6ACkYi/z2D9lcQHhCtKoAFdP19Uj7IOtDq66wXNw07xtiYNRkzBx3nc 83QxEDs+Ako/s1C+uOzb2EV50g2kn2Tz6eZE7Bs9EGVUoQ0Lb/jUEOXdssSt6gbxUudT qwbQ== X-Gm-Message-State: APjAAAUQqoE0MdEskbeVZBSUI4M4I4sCX55idwt9q0GQYik14js6SyCp 4ZMVt/hh4shn/gK+3E/GEFI= X-Google-Smtp-Source: APXvYqyVk8cpVwKiB5S8sCwirFHGxRGUYU5B9+TE+rgqMY4DydfDEPqOJ0ug7UGZ8Df4lZ3tNhpwFQ== X-Received: by 2002:a65:4cc4:: with SMTP id n4mr28980894pgt.307.1563210136582; Mon, 15 Jul 2019 10:02:16 -0700 (PDT) Received: from ?IPv6:2605:a601:a990:4d00:a925:658c:7e16:1f17? ([2605:a601:a990:4d00:a925:658c:7e16:1f17]) by smtp.gmail.com with ESMTPSA id e6sm21596962pfn.71.2019.07.15.10.02.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jul 2019 10:02:15 -0700 (PDT) From: Bret Jordan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A11723D8-9DF2-4580-96FD-04AA3FEEDC82" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 15 Jul 2019 11:02:12 -0600 In-Reply-To: Cc: Kathleen Moriarty , Eliot Lear , smart@irtf.org, Dominique Lazanski , IETF SecDispatch , Stephen Farrell To: Eric Rescorla References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 17:02:26 -0000 --Apple-Mail=_A11723D8-9DF2-4580-96FD-04AA3FEEDC82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ekr, It is not so much that it was designed wrong, but that when critical = functionality was removed, there was no alternative method added to = support critical use cases. So one can argue that some decisions were = done from a myopic point of view, without realizing the problems they = will create.=20 There are many examples, but let us just take two for right now. I am = sure I will enrage people to no end and cause an uproar, but so be it.=20= Hiding the Server Certificate This is a wonderful thing for open internet sessions as it help prevent = passive analysis of users traffic and where a user is going. So from = that side, it is great. However, from the managed network stand point it = is terrible. This feature/data is a critical element used in managed = networks and is critical for ensuring regulatory compliance. The problem = is not so much that the WG decided to hide it. The problem is the WG did = not and has not yet provided an alternative solution to fill in the = missing gap. So either the WG does not understand the operational = security requirements around it, or they are just choosing to ignore = them. DNS over HTTPS and DANE This is also a really neat idea. However, when you layer this with = DANE+DNS_SEC you get to a point where installed trust anchors no longer = become effective. Further, managed networks really rely on DNS data for = both first line defense and retrospective analysis of threat actor / CnC = behavior. So DNS over HTTPs by itself is not a bad thing. But the way = it is being implemented in products and the possibility of using it with = other solutions like DANE can make operational security significantly = more challenging if not impossible. Threat Actors are already starting = to use DoH to launch attacks, since it provides a way for them to get = around some security controls. So it becomes critical that for things = like DoH that products provide a way for it to be turned off, or for = managed networks to specify their own DoH servers. Further, managed = networks need to start looking at locating their internal DNS servers on = the WAN side of their proxies / firewalls so that they can create = islands of trust and rewrite the DNS_SEC on the fly if they need too. = But all of this should be called out and where possible, we should = provide ways for management networks to still do what they need.=20 So I would like the security considerations to be updated to help ensure = that we ask the questions, like =E2=80=9Cwhat is this going to do to = operational security?=E2=80=9D, =E2=80=9Chow is this going to impact = incident response and network forensics?=E2=80=9D. I want to also be = super clear that I am not against these technologies by themselves. But = we need to ask these hard questions and provide solutions that can still = enable managed networks to protect themselves. Thinking that = everything can and should be done on the endpoint is just outright = naive.=20 Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Jul 15, 2019, at 9:25 AM, Eric Rescorla wrote: >=20 >=20 >=20 >=20 > On Mon, Jul 15, 2019 at 7:50 AM Bret Jordan > wrote: > Kathleen, >=20 >=20 >> I do think there is work for the IRTF as well and would like to see = that encouraged. The shift to strong encryption is good, but upends the = current security management models for many. >=20 > This is one of the points I made during my talk at RSA. These = technologies by themselves, are all really great. The problem comes is = when you start using all of them together. To the naive comment earlier = that this is about vendors trying to sell product, no, this is about = network and cyber defenders and SoC analysts trying to do their job. = There are things like regulatory compliance that organizations and = enterprises are required to follow. Some times I feel like we are so = worried about one piece of the security pie, that we completely neglect = the others.=20 >=20 > Bret, >=20 > As I said before, this is extremely general and hard to act on. >=20 > What would be most helpful at this point would be for you to describe = a few ways in which you think the IETF should have designed protocols = differently, so that we can discuss them. >=20 > -Ekr >=20 >=20 > Here in the IETF everyone needs to better understand how SoC analysts = and network/cyber defenders do their jobs, what they are asked to do, = and what tools are available to them.=20 >=20 > Bret --Apple-Mail=_A11723D8-9DF2-4580-96FD-04AA3FEEDC82 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ekr,

It = is not so much that it was designed wrong, but that when critical = functionality was removed, there was no alternative method added to = support critical use cases. So one can argue that some decisions were = done from a myopic point of view, without realizing the problems they = will create. 

There are many examples, but let us just take two for right = now.  I am sure I will enrage people to no end and cause an uproar, = but so be it. 


Hiding the Server = Certificate
This is a wonderful thing for open = internet sessions as it help prevent passive analysis of users traffic = and where a user is going. So from that side, it is great. However, from = the managed network stand point it is terrible. This feature/data is a = critical element used in managed networks and is critical for ensuring = regulatory compliance. The problem is not so much that the WG decided to = hide it. The problem is the WG did not and has not yet provided an = alternative solution to fill in the missing gap. So either the WG does = not understand the operational security requirements around it, or they = are just choosing to ignore them.


DNS = over HTTPS and DANE
This is also a really neat = idea. However, when you layer this with DANE+DNS_SEC you get to a point = where installed trust anchors no longer become effective.  Further, = managed networks really rely on DNS data for both first line defense and = retrospective analysis of threat actor / CnC behavior.  So DNS over = HTTPs by itself is not a bad thing.  But the way it is being = implemented in products and the possibility of using it with other = solutions like DANE can make operational security significantly more = challenging if not impossible.  Threat Actors are already starting = to use DoH to launch attacks, since it provides a way for them to get = around some security controls. So it becomes critical that for things = like DoH that products provide a way for it to be turned off, or for = managed networks to specify their own DoH servers.  Further, = managed networks need to start looking at locating their internal DNS = servers on the WAN side of their proxies / firewalls so that they can = create islands of trust and rewrite the DNS_SEC on the fly if they need = too.  But all of this should be called out and where possible, we = should provide ways for management networks to still do what they = need. 


So I would like the security = considerations to be updated to help ensure that we ask the questions, = like =E2=80=9Cwhat is this going to do to operational security?=E2=80=9D, = =E2=80=9Chow is this going to impact incident response and network = forensics?=E2=80=9D.  I want to also be super clear that I am not = against these technologies by themselves. But we need to ask these hard = questions and provide solutions that can still enable managed networks = to protect themselves.   Thinking that everything can and should be = done on the endpoint is just outright naive. 



Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Jul 15, 2019, at 9:25 AM, Eric Rescorla <ekr@rtfm.com> = wrote:




On Mon, Jul = 15, 2019 at 7:50 AM Bret Jordan <jordan.ietf@gmail.com> wrote:
Kathleen,


I do think there = is work for the IRTF as well and would like to see that = encouraged.  The shift to strong encryption is good, but upends the = current security management models for = many.

This is one of the points I made during my talk at RSA.  = These technologies by themselves, are all really great.  The = problem comes is when you start using all of them together.  To the = naive comment earlier that this is about vendors trying to sell product, = no, this is about network and cyber defenders and SoC analysts trying to = do their job. There are things like regulatory compliance that = organizations and enterprises are required to follow. Some times I feel = like we are so worried about one piece of the security pie, that we = completely neglect the others. 

Bret,

As I said before, this = is extremely general and hard to act on.

What would be most helpful at this = point would be for you to describe a few ways in which you think the = IETF should have designed protocols differently, so that we can discuss = them.

-Ekr


Here in = the IETF everyone needs to better understand how SoC analysts and = network/cyber defenders do their jobs, what they are asked to do, and = what tools are available to them. 

Bret
=

= --Apple-Mail=_A11723D8-9DF2-4580-96FD-04AA3FEEDC82-- From nobody Mon Jul 15 11:08:03 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDA9120196 for ; Mon, 15 Jul 2019 11:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 QUcFj3d2Enad for ; Mon, 15 Jul 2019 11:07:59 -0700 (PDT) Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com [209.85.210.46]) (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 AB94A120124 for ; Mon, 15 Jul 2019 11:07:59 -0700 (PDT) Received: by mail-ot1-f46.google.com with SMTP id z23so17963361ote.13 for ; Mon, 15 Jul 2019 11:07:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9Hun1S8TTyCGuQDnqUa1V67rfDOvBK5N5U0XN5R1D+k=; b=nirCYDoslI0hSOScy4rvUbzTvLTL+z5n5Z7rQlqpl62aBaE4VpwnGtVaE3HJMuk1Y8 qp6yLazNfbcotg0FuEi0Yr7lXs4wbuhqsKHUS4JsXUV4YnCgmVtxmg3imY8+ET8MMMph XWMnP7noAjmecgSyGLWR3vsiZC+8N3mBuV+n1ZMd0gU8b73xAs6SslMqT/cJK5DPi9Ay QPg4use1NNLcsjHGgkdDtkbzAdUqpoAH3nMfpJIGiaD4JkSBy/nzL1hwobnutgptdUjh soppO6egJfsvRLYh7+T+xK2PN0jzVG5OZGilct3yvg63Tvs/0k8ZQk9ckqbos3mFZEqV JrkQ== X-Gm-Message-State: APjAAAVLqDno8IuOXNWp1qCGT4hZgnPYRBZmpGPKMEn36ZhEE3uq/o3Q SsHUF8XvWPYMrxN5dqrmLVjMqXbUQyvXb4HJ/yE= X-Google-Smtp-Source: APXvYqx+K306ZcekV/l5FVVetP1uvTQQXRBN1FObUSn0gCdqwjawwFXgyUF0Ba9coOcFaEv5iS7LuNiBEFSbClhcX8c= X-Received: by 2002:a05:6830:1206:: with SMTP id r6mr21488960otp.37.1563214078954; Mon, 15 Jul 2019 11:07:58 -0700 (PDT) MIME-Version: 1.0 References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <45cc67f6-3dd4-9788-29e5-4cc82471e6ee@nomountain.net> <9683DFBC-1816-4C0A-8D8A-4CE36318C72C@cisco.com> <469416D4-F549-4CAD-9C81-3D4A5A271B6A@cisco.com> <2E98BE46-174B-4423-976C-6EB48A3A714F@cisco.com> In-Reply-To: <2E98BE46-174B-4423-976C-6EB48A3A714F@cisco.com> From: Phillip Hallam-Baker Date: Mon, 15 Jul 2019 14:07:48 -0400 Message-ID: To: Eliot Lear Cc: Bret Jordan , Melinda Shore , IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000e2510b058dbc23ad" Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 18:08:02 -0000 --000000000000e2510b058dbc23ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 15, 2019 at 12:16 PM Eliot Lear wrote: > Phil, > > On 15 Jul 2019, at 18:03, Phillip Hallam-Baker > wrote: > > I am pretty sure this is not security 101 stuff. In fact I am pretty sure > that it will be quite a while before the academy really gets to grips wit= h > this stuff. They don't have the same biases we do but they have different > ones. > > For example, the need to patch systems is brought up and this is almost > always seen as a good thing. Not in the process control world it isn't. T= he > problem of unauthorized updates is a very serious concern for them. > > > > I think I agree with your thesis statement but not your supporting > statement above. There are a great many =E2=80=9Cbest practices=E2=80=9D= that are coming > out, and they all to a one usually involve usernames and passwords for a > good number of devices that might not require either. And in fact, the > idea of a password for machine controlled devices is Just Bad. > > Patches themselves from the vendors are absolutely *required* to be > available, but the timing of their installation needs to be left to > customers based on when =E2=80=93 if at all =E2=80=93 those devices can a= llow for a window > where the device may miss a beat. But even in these cases, process contr= ol > systems need in service upgrade mechanisms, because the reality is that t= he > bugs will be there. > No, there is no absolute security requirement here. There are two concerns that are potentially in conflict 1) The vendor may have introduced a security vulnerability 2) The vendor may use an update to reduce or remove functionality. Again, I have $2,000 worth of Nest equipment in the house. Google recently announced that they are discontinuing support for their previous interconnectivity support that my current home configuration uses. My hub provider may or may not support the new scheme. What this means is that my device vendor has abused its update privilege to restrict my device functionality for its own profit. That is a security concern that affects my wallet and it matters much more to me than the possibility that the vendor might want to distribute a legitimate update patch to address their potential incompetence. Setting up the first requirement that affects a manufacturer interest as absolute and unchallengable is wrong. There are two requirements here. patches are not a security requirement, they are a security control. > This is not an attack many device providers are worried about because it > isn't an attack that is going to affect them (for a start) and they think > they can trust themselves. Which may well not be true. I have seen a sing= le > employee cause $1 million worth of vandalism after being upset that his > wages were being garnished for alimony. I really doubt that more than 5% = of > the companies that make IoT devices have effective controls. > > > Ok, but that is no reason to not have automated updates available. That > is more of a reason to have strong audit processes in place. > If the vendors were capable of doing strong audit controls, they would be capable of writing code that can't be compromised by a buffer overrun exploit. I see this demand for patching as being an anti-pattern that is being promoted by the folk who think that dumping linux plus some Python on an IoT device and shipping it is an acceptable IoT approach. It isn't. You cannot secure a platform with 15 million lines of code. IoT devices should not be built round kernels designed to support a general purpose computing model. The attack surface is ridiculous. There is no way that is going to be patchable. Using a dedicated IoT kernel like .NET Core running on the bare metal with as little intermediation as possible is the way forward. > > The fact that an IoT device makes the owner dependent on the provider is > totally a security issue. The fact that the device providers don't want t= o > acknowledge it doesn't make it any less so. > > > I agree that this is indeed a security issue, but that doesn=E2=80=99t me= an that > it=E2=80=99s the wrong way to go. There are other factors to take into > consideration, not the least of which is cogs and e-Waste associated with > unnecessarily shipping extra horse power to 20 million endpoints when a > little elastic processing in the cloud will do. > Cloud computing is good. But it doesn't have to be the cloud provided by the manufacturer. Devices should connect to the cloud I provide which may be off site or may be onsite. A Raspberry Pi W for $5 has more computing power than the machine I used when I was designing the Web specs at CERN. We used the same class of machine to control experiments with 550 tons of depleted uranium. Moving the control points off site is a lazy model. The smart home should be capable of working even if the Internet service is down. I have at least two dozen machines in the house capable of delivering a gigaflop. So I really should not need to move anything out of my house to process. The podcast series I am currently editing is called 'Should this be Internet' and it is about IoT devices. I will be giving something of a preview a week on Thursday. Spoiler alert: the answer on all the segments so far is 'no'. And I am the person who has been spending a small fortune buying all this stuff. My big fear here is that we are trading on the enthusiasm of the early adopter market and there is a real risk that if we don't start building IoT devices that aren't more trouble than they are worth before that enthusiasm is spent, we will end up with an IoT winter. Remember that (almost) everything we are currently seeing in 'AI' is stuff that was basically developed in the 1980s. They set expectations that couldn't be met by the technology of the day. By the later 1990s, the machines were plenty powerful enough but the AI winter didn't see a thaw for another decade. --000000000000e2510b058dbc23ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 15, 2019 at 12:16 PM Eliot Lear <lear@cisco.com> wrote:
Phil,
On 15 Jul 2019, at 18:= 03, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

I am pretty sure this is not security 101 stuff. I= n fact I am pretty sure that it will be quite a while before the academy re= ally gets to grips with this stuff. They don't have the same biases we = do but they have different ones.=C2=A0
=
For example, the need to patch sys= tems is brought up and this is almost always seen as a good thing. Not in t= he process control world it isn't. The problem of unauthorized updates = is a very serious concern for them.

=

I think I agree with your thesis statement but no= t your supporting statement above.=C2=A0 There are a great many =E2=80=9Cbe= st practices=E2=80=9D that are coming out, and they all to a one usually in= volve usernames and passwords for a good number of devices that might not r= equire either.=C2=A0 And in fact, the idea of a password for machine contro= lled devices is Just Bad.

Patches themselves from = the vendors are absolutely required=C2=A0to be available, but the ti= ming of their installation needs to be left to customers based on when =E2= =80=93 if at all =E2=80=93 those devices can allow for a window where the d= evice may miss a beat.=C2=A0 But even in these cases, process control syste= ms need in service upgrade mechanisms, because the reality is that the bugs= will be there.

No, there is no absolute secu= rity requirement here. There are two concerns that are potentially in confl= ict

<= div class=3D"gmail_default" style=3D"font-size:small">1) The vendor may hav= e introduced a security vulnerability
2) The vendor may use an update to reduce or remove = functionality.
=
Again, I h= ave $2,000 worth of Nest equipment in the house. Google recently announced = that they are discontinuing support for their previous interconnectivity su= pport that my current home configuration uses. My hub provider may or may n= ot support the new scheme. What this means is that my device vendor has abu= sed its update privilege to restrict my device functionality for its own pr= ofit.

That is a security = concern that affects my wallet and it matters much more to me than the poss= ibility that the vendor might want to distribute a legitimate update patch = to address their potential incompetence.

Setting up the first requirement that affects a manufacture= r interest as absolute and unchallengable is wrong. There are two requireme= nts here. patches are not a security requirement, they are a security contr= ol.=C2=A0
This is not an attack many device= providers are worried about because it isn't an attack that is going t= o affect them (for a start) and they think they can trust themselves. Which= may well not be true. I have seen a single employee cause $1 million worth= of vandalism after being upset that his wages were being garnished for ali= mony. I really doubt that more than 5% of the companies that make IoT devic= es have effective controls.

Ok, = but that is no reason to not have automated updates available.=C2=A0 That i= s more of a reason to have strong audit processes in place.

If the vendors were capable of doing strong audit controls, they w= ould be capable of writing code that can't be compromised by a buffer o= verrun exploit.=C2=A0

I s= ee this demand for patching as being an anti-pattern that is being promoted= by the folk who think that dumping linux plus some Python on an IoT device= and shipping it is an acceptable IoT approach. It isn't. You cannot se= cure a platform with 15 million lines of code. IoT devices should not be bu= ilt round kernels designed to support a general purpose computing model. Th= e attack surface is ridiculous. There is no way that is going to be patchab= le.

<= div class=3D"gmail_default" style=3D"font-size:small">Using a dedicated IoT= kernel like .NET Core running on the bare metal with as little intermediat= ion=C2=A0 as possible is the way forward.

=
The fact that an IoT device makes the owner = dependent on the provider is totally a security issue. The fact that the de= vice providers don't want to acknowledge it doesn't make it any les= s so.

I agree that this is ind= eed a security issue, but that doesn=E2=80=99t mean that it=E2=80=99s the w= rong way to go.=C2=A0 There are other factors to take into consideration, n= ot the least of which is cogs and e-Waste associated with unnecessarily shi= pping extra horse power to 20 million endpoints when a little elastic proce= ssing in the cloud will do.

Cloud computing is good= . But it doesn't have to be the cloud provided by the manufacturer.
Devices= should connect to the cloud I provide which may be off site or may be onsi= te. A Raspberry Pi W for $5 has more computing power than the machine I use= d when I was designing the Web specs at CERN. We used the same class of mac= hine to control experiments with 550 tons of depleted uranium.=C2=A0
<= div class=3D"gmail_default" style=3D"font-size:small">
Moving the control points off = site is a lazy model. The smart home should be capable of working even if t= he Internet service is down. I have at least two dozen machines in the hous= e capable of delivering a gigaflop. So I really should not need to move any= thing out of my house to process.


The podcast series I am currently editing is called 'Should this be In= ternet' and it is about IoT devices. I will be giving something of a pr= eview a week on Thursday. Spoiler alert: the answer on all the segments so = far is 'no'. And I am the person who has been spending a small fort= une buying all this stuff.

My big fear here is that we are trading on the enthusiasm of the early ad= opter market and there is a real risk that if we don't start building I= oT devices that aren't more trouble than they are worth before that ent= husiasm is spent, we will end up with an IoT winter.

Remember that (almost) everything we are curren= tly seeing in 'AI' is stuff that was basically developed in the 198= 0s. They set expectations that couldn't be met by the technology of the= day. By the later 1990s, the machines were plenty powerful enough but the = AI winter didn't see a thaw for another decade.
--000000000000e2510b058dbc23ad-- From nobody Tue Jul 16 08:36:29 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F03D1207A4 for ; Tue, 16 Jul 2019 08:36:25 -0700 (PDT) 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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 WAE4liC20WxK for ; Tue, 16 Jul 2019 08:36:23 -0700 (PDT) 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 77123120791 for ; Tue, 16 Jul 2019 08:36:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 535B63808A; Tue, 16 Jul 2019 11:36:11 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CFC44CA1; Tue, 16 Jul 2019 11:36:13 -0400 (EDT) To: secdispatch@ietf.org References: <6535.1560786935@dooku.sandelman.ca> <10505.1560789112@dooku.sandelman.ca> <12718.1560790704@dooku.sandelman.ca> <040a01d5263c$6c51efa0$44f5cee0$@augustcellars.com> <16160.1560951514@localhost> Cc: Daniel Harkins From: Michael Richardson Message-ID: <57b7caef-e814-947b-c705-6e02c35e2cd3@sandelman.ca> Date: Tue, 16 Jul 2019 11:36:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <16160.1560951514@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Secdispatch] addressing Content-Type-Encoding errata on EST / RFC7030 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 15:36:26 -0000 On 2019-06-19 9:38 a.m., Michael Richardson wrote: > > Dear secdispatch Chairs, > > I have written draft-richardson-lamps-rfc7030est-clarify-02 to deal with > the errata: > https://www.rfc-editor.org/errata/eid5107 > > it turns out that deployed code prevents us from having a signal that > would let us remove the needless base64 encoding, but at least we can > remove the deprecated CTE header which was not being used anyway. Hi secdispatch, I don't think that I really need any in-person time next week on this. I'm just looking for guidance on where/how such a document should proceed. AD-sponsor? LAMPS? Something else? The base64/Content-Type-Encoding situation definitely caused a lot of confusion for the BRSKI inter-operation testing that has occurred in the past few months. > > I believe that we can deal with: > https://www.rfc-editor.org/errata/eid4384 > https://www.rfc-editor.org/errata/eid5108 > > in this document as well, although I haven't yet done that. The result would > be a standards track document that Updates RFC7030. There is an additional errata of a completely editorial from July 13. I don't really speak enough ASN.1 to know if the ASN.1 errata is valid. I'm told that Dan Harkins has other reasons to re-open RFC7030, and while I think we could satisfy the PS->IS step via interoperation and deployment experience, I'm not burning to do that work. > > As an aside, I think that the errata needs to move from reported to accepted. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Thu Jul 18 10:49:04 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F59120AD4 for ; Thu, 18 Jul 2019 10:49:02 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 MrgR7E3DhtkS for ; Thu, 18 Jul 2019 10:49:00 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id A7EC2120ADC for ; Thu, 18 Jul 2019 10:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1563472139; d=isode.com; s=june2016; i=@isode.com; bh=ZzhlWsXGPE+PIkvYdod4PkvVUwFXw2zYyknrWdPEw00=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=vgVtcDWNdrgr/14Du99CL3xtFdeqcnvDsCAPQOIO0k83kW7gewlEp3C80k+nArmxPDvSrq 3VGqMk5rrhNE+9MjSJhzpL5TNOkg481V9c1aYWi382F2OtxAaGzWdvh1axv64xRFcpqQ7K VZDYc0eFemZJLiqGijP9YLESGfaBO4I=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 18 Jul 2019 18:48:59 +0100 To: Michael Richardson , secdispatch@ietf.org Cc: Daniel Harkins References: <6535.1560786935@dooku.sandelman.ca> <10505.1560789112@dooku.sandelman.ca> <12718.1560790704@dooku.sandelman.ca> <040a01d5263c$6c51efa0$44f5cee0$@augustcellars.com> <16160.1560951514@localhost> <57b7caef-e814-947b-c705-6e02c35e2cd3@sandelman.ca> From: Alexey Melnikov Message-ID: Date: Thu, 18 Jul 2019 18:48:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: <57b7caef-e814-947b-c705-6e02c35e2cd3@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Secdispatch] addressing Content-Type-Encoding errata on EST / RFC7030 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2019 17:49:03 -0000 Hi Michael, On 16/07/2019 16:36, Michael Richardson wrote: > On 2019-06-19 9:38 a.m., Michael Richardson wrote: >> >> Dear secdispatch Chairs, >> >> I have written draft-richardson-lamps-rfc7030est-clarify-02 to deal with >> the errata: >> =C2=A0=C2=A0=C2=A0 https://www.rfc-editor.org/errata/eid5107 >> >> it turns out that deployed code prevents us from having a signal that >> would let us remove the needless base64 encoding, but at least we can >> remove the deprecated CTE header which was not being used anyway. > > Hi secdispatch, I don't think that I really need any in-person time=20 > next week on this.=C2=A0 I'm just looking for guidance on where/how such a= =20 > document should proceed.=C2=A0 AD-sponsor? LAMPS? Something else? I think I was the ART AD who spotted the problem, so arguably it is my=20 fault :-). We should talk in Montreal. I think AD-sponsored would be Ok=20 if changes are constrained. Best Regards, Alexey > The base64/Content-Type-Encoding situation definitely caused a lot of=20 > confusion for the BRSKI inter-operation testing that has occurred in=20 > the past few months. > >> >> I believe that we can deal with: >> =C2=A0=C2=A0=C2=A0=C2=A0 https://www.rfc-editor.org/errata/eid4384 >> =C2=A0=C2=A0=C2=A0=C2=A0 https://www.rfc-editor.org/errata/eid5108 >> >> in this document as well, although I haven't yet done that.=C2=A0 The=20 >> result would >> be a standards track document that Updates RFC7030. > > There is an additional errata of a completely editorial from July 13. > I don't really speak enough ASN.1 to know if the ASN.1 errata is valid. > > I'm told that Dan Harkins has other reasons to re-open RFC7030, and=20 > while I think we could satisfy the PS->IS step via interoperation and=20 > deployment experience, I'm not burning to do that work. > >> >> As an aside, I think that the errata needs to move from reported to=20 >> accepted. >> From nobody Fri Jul 19 19:20:43 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6BF12014E for ; Fri, 19 Jul 2019 19:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, 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 header.b=iIgbDm12; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sGuIXwPX 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 DBZiU5ZyJ8yB for ; Fri, 19 Jul 2019 19:20:39 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BBB2120139 for ; Fri, 19 Jul 2019 19:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6273; q=dns/txt; s=iport; t=1563589238; x=1564798838; h=from:to:subject:date:message-id:mime-version; bh=s3S2OS+mGXPe7Opsit5ZcX1Y2Kb8geAAUQOS101wqis=; b=iIgbDm12WML2RS00tDgraOvguKBxzbfbWT1vdrZ3nAAOdF86SNFkD8tq PNtDx6/d68PuRZKaYH00ekglRIBC9D7NSBz6giR2hrKjtCR8TV3Km04gO Ewy3TbYdxaYEgPxcZrvg6kR78VbWZZ99GZ0OKuCx+yxf2Ia/t8ZvYRsOA w=; IronPort-PHdr: =?us-ascii?q?9a23=3AYGFmrxzwy5BHXmDXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YR2N/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuOAFfhIfrCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BNBgBHeTJd/5hdJa1mghmBFS9QA21?= =?us-ascii?q?VIAQLKoQdg0cDjXxMlQqEVYEugSQDVAkBAQEMAQEjCgIBAYRAGYI7IzQJDgE?= =?us-ascii?q?DAQEEAQECAQZthR4BC4VjEQoTAQE4EQFKAgQwJwQ1gwABgR1NAx0BAgygAgK?= =?us-ascii?q?BOIhgcYEygnkBAQWBNgKBD4I9GIITAwaBNItfF4F/gREnH4VrAQEDgguCXjK?= =?us-ascii?q?CJo54hH6Ia44GCQKCGYZYjTQbgi2HJYQMiiyGA4cyh0iQCAIEAgQFAg4BAQW?= =?us-ascii?q?BUDiBWHAVZQGCQYYzhRSFP3IMgR2OfgEB?= X-IronPort-AV: E=Sophos;i="5.64,285,1559520000"; d="scan'208,217";a="598364310" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Jul 2019 02:20:37 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x6K2KbIj006376 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 20 Jul 2019 02:20:37 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 19 Jul 2019 21:20:36 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 19 Jul 2019 21:20:36 -0500 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 19 Jul 2019 21:20:36 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VUKDXFCRLbeX1jzKyAGQXGu/EXwy0nyoW75RMF97hjexKDKr7imQ8M3BJolilaz2xDnJwU4mQwAB0mOQR3d/g7QA0c8F9mvCDJ0dhZCkQpZlI63eZN13sXO5hoauUCwxSZIIbPFwnmlZuPx3jG1/S9B+1AZJPtrlOgnAQRxOR5lGhtje7f+Jmg7cG2GWFBVyBZMFQgKAg6p+f2x1FO3u9kYterH1OqyU6dhXXD/Wd7hT6EPjSUV06bbpyt1XoeMdjz61jOBuNpgjPhhao+vmssr9FJjgRQj9HropI/tdzasxADJbYVgj+TZRX2Hiu65AOsYPZTOo9WYzTryNTbLHdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s3S2OS+mGXPe7Opsit5ZcX1Y2Kb8geAAUQOS101wqis=; b=T3AkqW0AZbkTW1JMeChieZYRkAUcnxb5UOsOltb2PdIVrMjQTjWsm+nvmC1ddzsDRu681pqWFV+Br4ft9tDefgBlKUZhztthPWDoIPIXp3Y1JwHgfwCIZVI0IEaWJIobYlo7wi75IJH5mDqJOmJbu3GG4zWNC15zEzynazpqEzhHx4RXJbgi/kTnM6X+Q7hTrj+e2JtKYpr/rvGOnNOXPWDzQdkUwcNBgKrr9zgwYoeCEg8Np0ZLOKon2lLe0/NXMg+Ji+Ba8xgfnd3H/eAnbSnqzM9MMzER58+C4huAwgCvhoQL5BlUki5equSbYF5dt8e/tBWQZhtmauA87CHbcA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s3S2OS+mGXPe7Opsit5ZcX1Y2Kb8geAAUQOS101wqis=; b=sGuIXwPXRXhR7PzNh/jXc+61kv2ZfZyS65Kkonxmgs/tOpbXS1PbaRzQJozvnWrJqMzJGXqB438KjW4gEe/325A+JSj5VWCa7ATzaNUWW6gz3TEopA63tx7v3UDxw4FXbc8sJKBF9fE+6Wl/qJKRKFHJ9y7KQpOJ9wH8K3lvZSM= Received: from BYAPR11MB3046.namprd11.prod.outlook.com (20.177.225.213) by BYAPR11MB2679.namprd11.prod.outlook.com (52.135.227.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Sat, 20 Jul 2019 02:20:35 +0000 Received: from BYAPR11MB3046.namprd11.prod.outlook.com ([fe80::c895:4d83:c5b8:b3d6]) by BYAPR11MB3046.namprd11.prod.outlook.com ([fe80::c895:4d83:c5b8:b3d6%6]) with mapi id 15.20.2073.012; Sat, 20 Jul 2019 02:20:35 +0000 From: "David Carrel (carrel)" To: "secdispatch@ietf.org" Thread-Topic: Controller-IKE Thread-Index: AQHVPqG2qaTEIVD/zEy+2+Xv9S/jDw== Date: Sat, 20 Jul 2019 02:20:35 +0000 Message-ID: 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=carrel@cisco.com; x-originating-ip: [2001:420:c0c8:1003::692] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7075f9de-b881-497d-d5b5-08d70cb8d95d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2679; x-ms-traffictypediagnostic: BYAPR11MB2679: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0104247462 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(39860400002)(346002)(366004)(396003)(189003)(199004)(2351001)(606006)(33656002)(3480700005)(14454004)(236005)(6512007)(54896002)(102836004)(5640700003)(6306002)(6916009)(53936002)(66946007)(6436002)(478600001)(5660300002)(46003)(1730700003)(66476007)(81156014)(966005)(6506007)(71190400001)(66446008)(790700001)(476003)(6116002)(64756008)(71200400001)(2501003)(486006)(76116006)(6486002)(25786009)(186003)(256004)(7736002)(14444005)(2906002)(8936002)(81166006)(8676002)(99286004)(2616005)(86362001)(36756003)(66556008)(68736007)(316002)(4744005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2679; H:BYAPR11MB3046.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /h34rdcDsM6JORJVTph2v0wxNtC0FDfl2sMGNYg3b4NBLr00gHEMsKwEP8tvstsBugsFpBiMXlfxdoAbkY4f8e44/ZM+KXSDDnhNX4CdbInoo6ngETwBTIYoapEiN3Gk0UfCFn2XPUYUdKaWZfTOuapxxve+K20WGm7U6oI7O/vEJxAeE1n92dTQKZOFk17vawy44KUBiTKo1uLM64uOg1RuQpDFtzv1B4zdm1AvBN6XnAg3mZ2ERmgh2ADM9IIfPUfp8xG3On5fH67KkEXlemaZHrXpWKawQ0um9eMkT4RZ47ygGf/j7g7u2oI3cBGA9Krd93e3Dd8eKCtlbCanzpv/ne5PSf/T0Xl1xnbeM1+iftLju2L2oe6EiPjbP6DMY0cvLY/upLtLNBmrnKtiedNkO2nQmbgF/rKKG/L6Rec= Content-Type: multipart/alternative; boundary="_000_CDF9062534F640C38AE4AACD50D70C2Eciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7075f9de-b881-497d-d5b5-08d70cb8d95d X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2019 02:20:35.4966 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: carrel@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2679 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.30, xch-aln-020.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: [Secdispatch] Controller-IKE X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 02:20:41 -0000 --_000_CDF9062534F640C38AE4AACD50D70C2Eciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9sa3MsDQoNCkkgd291bGQgbGlrZSB0byBwcmVzZW50IENvbnRyb2xsZXItSUtFIGluIHRoZSBN b250cmVhbCBTZWN1cml0eSBEaXNwYXRjaCBtZWV0aW5nLiAgVGhlcmUgaXMgZ3Jvd2luZyBpbnRl cmVzdCBmcm9tIHJvdXRpbmcgZm9sa3MsIGFuZCBJIHN0cm9uZ2x5IGZlZWwgd2Ugc2hvdWxkIGV2 YWx1YXRlIGFuZCBwcm9ncmVzcyB0aGlzIGluIHRoZSBzZWN1cml0eSBhcmVhLiAgSeKAmWxsIGhh dmUgc29tZSBzbGlkZXMgdG8gc2hhcmUgc2hvcnRseS4gIEZvciBub3csIHBsZWFzZSBkbyByZWFk IHRoZSBkcmFmdC4gIEFsc28gdGhlcmUgYXJlIHNvbWUgZHJhZnRzIHJlZmVyZW5jaW5nIHRoaXM6 DQoNCkNvbnRyb2xsZXItSUtFOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2Fy cmVsLWlwc2VjbWUtY29udHJvbGxlci1pa2UtMDENCg0KQWxzbyBzb21lIGRvY3MgcmVmZXJlbmNp bmcgdGhpcyBmb3JtIG9mIGtleSBtYW5hZ2VtZW50Og0KQkVTUywgU2VjdXJlIEVWUE46IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWphc3NpLWJlc3Mtc2VjdXJlLWV2cG4tMDIN CkFuZDogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWR1bmJhci1iZXNzLWJncC1z ZHdhbi11c2FnZS0wMQ0KDQpDb21tZW50cyBhcHByZWNpYXRlZC4NCg0KRGF2ZQ0KDQo= --_000_CDF9062534F640C38AE4AACD50D70C2Eciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIg dmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Gb2xrcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgd291bGQgbGlrZSB0byBwcmVzZW50 IENvbnRyb2xsZXItSUtFIGluIHRoZSBNb250cmVhbCBTZWN1cml0eSBEaXNwYXRjaCBtZWV0aW5n LiZuYnNwOyBUaGVyZSBpcyBncm93aW5nIGludGVyZXN0IGZyb20gcm91dGluZyBmb2xrcywgYW5k IEkgc3Ryb25nbHkgZmVlbCB3ZSBzaG91bGQgZXZhbHVhdGUgYW5kIHByb2dyZXNzIHRoaXMgaW4g dGhlIHNlY3VyaXR5IGFyZWEuJm5ic3A7DQogSeKAmWxsIGhhdmUgc29tZSBzbGlkZXMgdG8gc2hh cmUgc2hvcnRseS4mbmJzcDsgRm9yIG5vdywgcGxlYXNlIGRvIHJlYWQgdGhlIGRyYWZ0LiZuYnNw OyBBbHNvIHRoZXJlIGFyZSBzb21lIGRyYWZ0cyByZWZlcmVuY2luZyB0aGlzOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Q29udHJvbGxlci1JS0U6IDxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYXJyZWwtaXBzZWNtZS1jb250cm9s bGVyLWlrZS0wMSI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FycmVsLWlw c2VjbWUtY29udHJvbGxlci1pa2UtMDE8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5BbHNvIHNvbWUgZG9jcyByZWZlcmVuY2luZyB0aGlzIGZvcm0gb2Yga2V5 IG1hbmFnZW1lbnQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkJFU1MsIFNlY3VyZSBFVlBOOiA8L3NwYW4+ PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNhamFzc2ktYmVzcy1z ZWN1cmUtZXZwbi0wMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNhamFzc2kt YmVzcy1zZWN1cmUtZXZwbi0wMjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BbmQ6IDwvc3Bhbj48YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHVuYmFyLWJlc3MtYmdwLXNkd2FuLXVz YWdlLTAxIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHVuYmFyLWJlc3MtYmdw LXNkd2FuLXVzYWdlLTAxPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5D b21tZW50cyBhcHByZWNpYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPkRhdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CDF9062534F640C38AE4AACD50D70C2Eciscocom_-- From nobody Sun Jul 21 07:19:40 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CD6120075 for ; Sun, 21 Jul 2019 07:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 5mujmF4m-EAR for ; Sun, 21 Jul 2019 07:19:37 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 ECAED120020 for ; Sun, 21 Jul 2019 07:19:36 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id j19so37552718otq.2 for ; Sun, 21 Jul 2019 07:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Emux27tcfus2l6NEdEyn4wq8sBLv5QrzftjHqAx2vt8=; b=lAG9Lw1QFrV/P1jRmJFr8DbGHCoKbJo1I42pfIOxYcj8OF/6lzssjnMWYc/iAbJ9dn fhOh3Nq8yah4s9hbHyGZTBWCN1Z0eKNs9VP3jQVmcXcL+EpahRiMthgdqeXDacxBgX2T sKHs5xSuDqsrs2zaaP46GCI4l6AaaVyHpJp7wzfDBabpIzC0PN2A/gcS6s87voA2ob/L L6QriySn/MbZUTR5xtaU6yBLYTJI9y1tROwlrQo+g3DEW0/cf7TJwGQgf5HRqLNzl6YK jkwui/A8BIWbKzvOuXT1YudbUxtjZJFA4raUpOIhIvpzdOdidNtpPASgGRBFdLeB8/oJ W3qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Emux27tcfus2l6NEdEyn4wq8sBLv5QrzftjHqAx2vt8=; b=bwTQyVFE34slldNxcJwqqHtFdsN+KVEo3o+R7NuJXKZxMK1rR7C/9YYFwZLBFCcS5i uQuKcKcH4E5cOK99ESQ+/QW+34ge4HXMvXpEu/DJwqOLMK7Dud9UMRGI0vThTgkVtQ4v 8t66QewP5C8cMNoi+qkoe5pc6It8muPZCwbc6e+yFbP8/1pD6wPCq4hyNicI0X46os8M wmxuDcZBVldLhyzeC5GIqJ+Wxr5fdB33vrZ8yCupraK8sOf/Zfc3FIHyA+K3yF4yA/Zf Bgy3R2J2ElCliAnVBupcIbo0QaSqQ0u/7DBmk8ipmtIpgnyMXQ8Y/25UZljYXoGneW1q O6LA== X-Gm-Message-State: APjAAAVGYkWMwgZul7apudwmHBCUeWcPd77qrm80N3ghAaQemQ7Uj0Xj sfp+5vGHT28h2C8zoxf6GbXOAsksLbqYb9/2xZY= X-Google-Smtp-Source: APXvYqwhmAAhMZtUn59NpvvmdObkrJQnjWLD79Al2sOV7Tu5sID0GoxuKRpBgFdAVb9vKPG8FYCUqLZ1XxK7eKp+2Ig= X-Received: by 2002:a9d:226c:: with SMTP id o99mr45441683ota.42.1563718776141; Sun, 21 Jul 2019 07:19:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Sun, 21 Jul 2019 10:19:16 -0400 Message-ID: To: "David Carrel (carrel)" Cc: "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002e4c35058e31a6f1" Archived-At: Subject: Re: [Secdispatch] Controller-IKE X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 14:19:39 -0000 --0000000000002e4c35058e31a6f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave, Thanks for sharing this work. This seems like an interesting problem to compare with IKE/TLS and MLS -- where IKE and TLS are about configuring a 1-1 security context and MLS is about establishing a single security context across N participants, the goal here seems to be to maintain a full matrix of N^2 security contexts with sub-linear messaging to update a row/column. Given that different shape, it seems like the association with IKE is pretty tenuous. It might be clearer to consider this an alternative to IKE for this mesh case, in the sense of being an external key exchange protocol that results in the production of IPsec SAs. It would be helpful to have a clearer idea of the security objectives here, especially around things like forward security and post-compromise security. The obvious objective of providing equivalent assurances to a collection of N^2 individually negotiated SAs seems unlikely to be feasible here. In particular, the protocol in the current document doesn't provide it, since multiple SAs are "fate shared" due to key reuse -- if an attacker compromises one peer's DH key, then a whole "row" of SAs are compromised. --Richard On Fri, Jul 19, 2019 at 10:20 PM David Carrel (carrel) wrote: > Folks, > > > > I would like to present Controller-IKE in the Montreal Security Dispatch > meeting. There is growing interest from routing folks, and I strongly fe= el > we should evaluate and progress this in the security area. I=E2=80=99ll = have some > slides to share shortly. For now, please do read the draft. Also there > are some drafts referencing this: > > > > Controller-IKE: > https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-01 > > > > Also some docs referencing this form of key management: > > BESS, Secure EVPN: > https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-02 > > And: https://tools.ietf.org/html/draft-dunbar-bess-bgp-sdwan-usage-01 > > > > Comments appreciated. > > > > Dave > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --0000000000002e4c35058e31a6f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave,

Thanks for sharing = this work.=C2=A0 This seems like an interesting problem to compare with IKE= /TLS and MLS -- where IKE and TLS are about configuring a 1-1 security cont= ext and MLS is about establishing a single security context across N partic= ipants, the goal here seems to be to maintain a full matrix of N^2 security= contexts with sub-linear messaging to update a row/column.
<= br>
Given that different shape, it seems like the association wit= h IKE is pretty tenuous.=C2=A0 It might be clearer to consider this an alte= rnative to IKE for this mesh case, in the sense of being an external key ex= change protocol that results in the production of IPsec SAs.

=
It would be helpful to have a clearer idea of the security objec= tives here, especially around things like forward security and post-comprom= ise security.=C2=A0 The obvious objective of providing equivalent assurance= s to a collection of N^2 individually negotiated SAs seems unlikely to be f= easible here.=C2=A0 In particular, the protocol in the current document doe= sn't provide it, since multiple SAs are "fate shared" due to = key reuse -- if an attacker compromises one peer's DH key, then a whole= "row" of SAs are compromised.

--Richard=

On Fri, Jul 19, 2019 at 10:20 PM David Carrel (carrel) <carrel@cisco.com> wrote:

Folks,<= /span>

=C2=A0<= /span>

I would like to prese= nt Controller-IKE in the Montreal Security Dispatch meeting.=C2=A0 There is= growing interest from routing folks, and I strongly feel we should evaluat= e and progress this in the security area.=C2=A0 I=E2=80=99ll have some slides to share shortly.=C2=A0 For now, please do r= ead the draft.=C2=A0 Also there are some drafts referencing this:=

=C2=A0<= /span>

Controller-IKE: https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-01

=C2=A0<= /span>

Also some docs refere= ncing this form of key management:

BESS, Secure EVPN: https://tools.ietf.org/html/draft-sajassi-bess-secure= -evpn-02

And: https://tools.ietf.org/html/draft-dunbar-bess-bgp-sdwan-usage-= 01

=C2=A0<= /span>

Comments appreciated.=

=C2=A0<= /span>

Dave

=C2=A0<= /span>

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--0000000000002e4c35058e31a6f1-- From nobody Mon Jul 22 06:01:13 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6AA12027A for ; Mon, 22 Jul 2019 06:01:10 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 9k6KnRhxFHaK for ; Mon, 22 Jul 2019 06:01:08 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 B867912011D for ; Mon, 22 Jul 2019 06:01:08 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id a27so28496169qkk.5 for ; Mon, 22 Jul 2019 06:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=sSckOapoH74PZKDxGOUOa1eoa1UfmRSpyVgTJiEOXgM=; b=cGvJC9WHyDcgex1azgvJOMQrxGHQ9e6ygidt23VAAzw5DkhMNEGiMnoqqh6zL3yEvy CGGaLbxomIyi3sLMB6PjpSu0rRXWJjW83Og9C0+Rnh/psvjwFpCNxbpQ42nHOwUf3r/S z5MzUVbdxoNd2oCjhL9L+iVDoN/cO7AXCtKKeUGCtP4G5P7lHHWQ0As84z/re3jVXxVq q2tZCMD3OIOsWZmfq0F+Ai0KyZXFsyslE+0+XQga2bR0psMShMiHHADSX0nYrxl7cyTz 32oQw0bcCafDHaD9viN80qkmEB7ZtrWdycyItbaa5JXIvfd7/U6cWHPB+UWQSHWy6mtX PKIA== 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:date :subject:message-id:to; bh=sSckOapoH74PZKDxGOUOa1eoa1UfmRSpyVgTJiEOXgM=; b=hAaxtFpAGg8BwV0nemBnDThlIWczpoQqnahRrLCAOH7MGJToQX89rlXXeWvGyaLF3F P7sVnurLjNim/6RuIrzej3hf9Unhpm80dg62s18vfkSCIh8EJ5O8csJr0IMkvbzaHDF3 giOv0rdyXRjDhy3WDXlYIVVgy2jh2007ojGp0GCZ1zvrSb/CDia0Jl0e7pVO7oH2IV1V bLvlWc9GJuaHXZBeVZuH7w2GpnwG09hNGxmgL8zYtWeGX+ipYkNmhDBlBQknRjIOK6Tq Qbn34WtS/U3gmqpVAIHbrlenCwzax6+nsr6SQfq1wmG4odojOUGNXcXKZx5n4+9w/h/b JaHA== X-Gm-Message-State: APjAAAU5tG2+t8xDGIjmisfCtq/dU4sz13z6v5gH3jaOLH9blVwQQgep H6ithtH86mHit+xPlkh3duAMGBKrHybr5A== X-Google-Smtp-Source: APXvYqxHvePSYrpuy6TFcpJCk2CL7eAErLm1OIe6GBC9j/1/4QgV8UQkz52TdmZlV+xoO9u3HY5bFw== X-Received: by 2002:a05:620a:14bc:: with SMTP id x28mr14548434qkj.116.1563800467688; Mon, 22 Jul 2019 06:01:07 -0700 (PDT) Received: from [172.20.1.46] ([216.113.24.76]) by smtp.gmail.com with ESMTPSA id e7sm17110152qtp.91.2019.07.22.06.01.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 06:01:07 -0700 (PDT) From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Mon, 22 Jul 2019 09:01:06 -0400 Message-Id: <48722D11-D432-41E7-8930-885FEF519228@gmail.com> To: secdispatch@ietf.org X-Mailer: iPhone Mail (16F203) Archived-At: Subject: [Secdispatch] Minutes & Jabber volunteers X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 13:01:10 -0000 Hello! Can we get one more volunteer to take minutes and one to be jabber scribe? A big thank you to Bret Jordan for offering to be one of the minute takers. Best regards, Kathleen Sent from my mobile device From nobody Mon Jul 22 06:57:13 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8CE1200B5 for ; Mon, 22 Jul 2019 06:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5pNYaO_-OkJ for ; Mon, 22 Jul 2019 06:57:10 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 6DAAF120059 for ; Mon, 22 Jul 2019 06:57:10 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id h21so38523732qtn.13 for ; Mon, 22 Jul 2019 06:57:10 -0700 (PDT) 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=nlt70cndGwHQogZXGs0EhMMOnICAhKIop31br+qxxBs=; b=C4MLStnB5P/cLNTO+CgSWZJS1/x357uDEa/2R7GB2gCimjNSnVrNMuzJrEUBQPDq9e DC7Au7nSuBPGmzJB94BC1PIOL9YoZVjJFAIA+yCrI+J5XfacKETyywCglpuhNzBolHVM fYVU1qwKpuJ19zofOIem779zhR8kjnCfvMviCxFkKNNg0p+dfhdUCi9PXvIaCexi+7DI Q9EUvDY52YkG6LlyzEDN+WDdojisRHv3nXn9CsNaUMBtSFlUS5YMgkpmj4Bud8axx31r cFYhIuu0ouea4EbUdWoIwZJYLyd6i/WTHRusJmdoFLMG8DYgNkjDjdAuQT39D3ZeGS6H kbIQ== 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=nlt70cndGwHQogZXGs0EhMMOnICAhKIop31br+qxxBs=; b=t2jio9VuG0qGvA0MNw4ManfA2sfFKM4tBdGejlNEK/iKO245m1zSRzqb4GwhIylRNh 8fpiZmt79SqAm/nV/2WnQWK9NJaVLbtYAGVuWY3ExLUIhu8iR7ZKebOSxUdbwjqkq9Zw bXbcygOs2xlrja+a0lhF84DAFzC8xm2G0Nfl0xPEfJs3hNaOOVziCgAxc7PLOjPpED0a IuuvEJKLJ6+z4SqyrSnDJ0G8FrlmH6Nx67RoX3YN6wPjL1JoIQ9KLdgqv7b6WroTDF63 Rp6iXQIytz8/fNqHEhRiZLlN+ARysDHXf+pIj5e5njzR4NvC5FCnedkWcaoiMikWUhgd fAiw== X-Gm-Message-State: APjAAAX0hBbibg4omYY94axabyG3bnDXyBzfbRbMG10WPG5/WBTItpwR C9ZuhgbxMDqka8eqbv6oFUi3cKnb X-Google-Smtp-Source: APXvYqxEIn3uJNTOZqFdcm2YcFB5KbP6CPqlvxDFaurckSPVm9HmSggxgQHRg8zJzUCEekjhP44erg== X-Received: by 2002:ac8:2181:: with SMTP id 1mr50764455qty.263.1563803829291; Mon, 22 Jul 2019 06:57:09 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:b43a:b744:15e3:9b? ([2001:67c:370:128:b43a:b744:15e3:9b]) by smtp.gmail.com with ESMTPSA id h1sm20441353qkh.101.2019.07.22.06.57.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 06:57:08 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-D4CA851D-1815-4923-A2E7-C08D958F76D3 Mime-Version: 1.0 (1.0) From: Bret Jordan X-Mailer: iPhone Mail (16F203) In-Reply-To: <48722D11-D432-41E7-8930-885FEF519228@gmail.com> Date: Mon, 22 Jul 2019 09:57:08 -0400 Cc: secdispatch@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <2B74B1CD-D50A-4668-A3F5-49F15F3DBA7B@gmail.com> References: <48722D11-D432-41E7-8930-885FEF519228@gmail.com> To: Kathleen Moriarty Archived-At: Subject: Re: [Secdispatch] Minutes & Jabber volunteers X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 13:57:13 -0000 --Apple-Mail-D4CA851D-1815-4923-A2E7-C08D958F76D3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Thanks Kathleen for all that you do.=20 Bret=20 Sent from my Commodore 128D PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > On Jul 22, 2019, at 9:01 AM, Kathleen Moriarty wrote: >=20 > Hello! >=20 > Can we get one more volunteer to take minutes and one to be jabber scribe?= >=20 > A big thank you to Bret Jordan for offering to be one of the minute takers= . >=20 > Best regards, > Kathleen=20 >=20 > Sent from my mobile device >=20 > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch --Apple-Mail-D4CA851D-1815-4923-A2E7-C08D958F76D3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Kathleen for all that you do. <= div>
Bret 

Sent from my C= ommodore 128D

PGP Finger= print: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050<= /span>
Hello!

Can we= get one more volunteer to take minutes and one to be jabber scribe?<= br>
A big thank you to Bret Jordan for offering to be o= ne of the minute takers.

Best regards,
Kathleen

Sent from my mobile d= evice

_____________________________________= __________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.or= g/mailman/listinfo/secdispatch
= --Apple-Mail-D4CA851D-1815-4923-A2E7-C08D958F76D3-- From nobody Mon Jul 22 07:29:15 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312D71202DD for ; Mon, 22 Jul 2019 07:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbcgQcmiAIsT for ; Mon, 22 Jul 2019 07:29:11 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::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 086871202A9 for ; Mon, 22 Jul 2019 07:29:11 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id u15so29736792oiv.0 for ; Mon, 22 Jul 2019 07:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SLKbx14/ry9/kAOnptyU0i9P8cj/QSKc/tBikp/Sw/E=; b=P5r+LWoBfv1hj9GSVkg0fjBkzVcYoUIZkIJ34FDbFvnAnYDj1/FfXdNEuXiWX2jatD huPWaggiHKLE8WelZqOzVS9H2OsBKXvvfMFlT0ql1pYAVunJ7BrjFp0UL9RpNQZCqZpJ Wy7/xGsTZWlrTGhsoBYZUbjtoo+8EV23v6C+BOLF+llyY9zLVW5+EyN3HwDmv9RisIwH 8haDinRH+aroulfjRXnUOQOK+sXWTqso86dTN/AOSYP5AgTWpVzHuxKnxBcriEsBqldW T423zUjo5seaUOusFHQpntr6B/gKTvB17cpow2EF6xHH68ckPsd3mc73GbHW0IZozdqz 0PHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SLKbx14/ry9/kAOnptyU0i9P8cj/QSKc/tBikp/Sw/E=; b=PDTeeNEg7541iABhVD4e6tQeZLcwT9WERwULYJXfgEAP/EnBLE7TnLD6QIxi1hNLUg dO0awJ1Kjv7osc4y5wWzbHQmSUdpQwT9po+TSHjl0H5UFskhWLWpS94CxbbboQnJrYOq 9g1OewOy/xgbo5uXWfZXj9Q87aAM/8urqmj4W3+N6lauq+7zCe6JLPDDmCG+qz6qrsZy vovHSJI1JZVup4uuCv9axb8NiXVMgex2c03B7ZBphBMM9MvnBAMtELBZ0rW56xqoLBDg 9dr1lUbo0Hkv8kIJ04zzIq84bvm/7C+M/Ra8Dizq7/ZyGuzckCl7cVWciWCn051DjRr9 qH+A== X-Gm-Message-State: APjAAAWiZpRLfA6iJiXh0ALfCTwtI+NPt85ds0zrn7NCaaj/AzVXSnBg B5QO4iBwU8GE5H1OwpT7TL4+KVa9zv0e7yhsxJQ= X-Google-Smtp-Source: APXvYqzGgT7yI0ekN3NbT1GuRk/oG2r1OPvGuH8zM10bbdlO4NQuE6VcVfg1kk/iz99+MJYu+29Wh7YXkre0z3s8nGo= X-Received: by 2002:aca:3808:: with SMTP id f8mr33286784oia.158.1563805750365; Mon, 22 Jul 2019 07:29:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kathleen Moriarty Date: Mon, 22 Jul 2019 10:28:31 -0400 Message-ID: To: "David Carrel (carrel)" Cc: "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003f93b9058e45e6db" Archived-At: Subject: Re: [Secdispatch] Controller-IKE X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 14:29:13 -0000 --0000000000003f93b9058e45e6db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi David, Could you please explain how this is different from the adopted work in I2NSF, https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection= / ? This is referenced in your draft along with one another, but there is no analysis on why they don't fit the need. The draft in I2NSF pulled in the IPsecMe working group and underwent significant revisions as a result to deal with several initial security issues. If there 's a gap that can be solved with that draft, could that be a way forward or is this needed for some specific reason? It would be helpful to understand this. Thank you, Kathleen On Fri, Jul 19, 2019 at 10:20 PM David Carrel (carrel) wrote: > Folks, > > > > I would like to present Controller-IKE in the Montreal Security Dispatch > meeting. There is growing interest from routing folks, and I strongly fe= el > we should evaluate and progress this in the security area. I=E2=80=99ll = have some > slides to share shortly. For now, please do read the draft. Also there > are some drafts referencing this: > > > > Controller-IKE: > https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-01 > > > > Also some docs referencing this form of key management: > > BESS, Secure EVPN: > https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-02 > > And: https://tools.ietf.org/html/draft-dunbar-bess-bgp-sdwan-usage-01 > > > > Comments appreciated. > > > > Dave > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --=20 Best regards, Kathleen --0000000000003f93b9058e45e6db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi David,

Could you please explain how = this is different from the adopted work in I2NSF,=C2=A0https:= //datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/= =C2=A0?

This is referenced in your draft along wit= h one another, but there is no analysis on why they don't fit the need.= =C2=A0 The draft in I2NSF pulled in the IPsecMe working group and underwent= significant revisions as a result to deal with several initial security is= sues.=C2=A0 If there 's a gap that can be solved with that draft, could= that be a way forward or is this needed for some specific reason?=C2=A0 It= would be helpful to understand this.

Thank you,
Kathleen

On Fri, Jul 19, 2019 at 10:20 PM David Carrel (carre= l) <carrel@cisco.com> wrote:<= br>

Folks,<= /span>

=C2=A0<= /span>

I would like to prese= nt Controller-IKE in the Montreal Security Dispatch meeting.=C2=A0 There is= growing interest from routing folks, and I strongly feel we should evaluat= e and progress this in the security area.=C2=A0 I=E2=80=99ll have some slides to share shortly.=C2=A0 For now, please do r= ead the draft.=C2=A0 Also there are some drafts referencing this:=

=C2=A0<= /span>

Controller-IKE: https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-01

=C2=A0<= /span>

Also some docs refere= ncing this form of key management:

BESS, Secure EVPN: https://tools.ietf.org/html/draft-sajassi-bess-secure= -evpn-02

And: https://tools.ietf.org/html/draft-dunbar-bess-bgp-sdwan-usage-= 01

=C2=A0<= /span>

Comments appreciated.=

=C2=A0<= /span>

Dave

=C2=A0<= /span>

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


--

Best regards,
Kathleen
--0000000000003f93b9058e45e6db-- From nobody Mon Jul 22 07:32:36 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3132120396 for ; Mon, 22 Jul 2019 07:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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_HELO_NONE=0.001, SPF_NONE=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=rtfm-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 HYiitEST6UjM for ; Mon, 22 Jul 2019 07:32:31 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 D7DCA120331 for ; Mon, 22 Jul 2019 07:32:30 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id v85so26772854lfa.6 for ; Mon, 22 Jul 2019 07:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=petWBepd+z7rTabHUo4yc75aIKiLQFeXDQrFrZDx018=; b=oppw/q9mQmPpqFuREMK4L0Iu75RCCYrnP9cEUEOCTLmosQHHRY5tjBZMZ/wwhCxKSy YHPXzX3blRrsejE+eUkO5eO2PvEppE+y4ZiHG4UcVzIo+EP4RRN1gP5zQy0eU0Ssv/Gr N/9xHcIZgOjUypBNjkq3D5IggHK+Ob1cvKto/ODRJsZBLbCsqyKiasF0+jDTfKfTwgKf eWea8Yh4FAL4b4Ryx9wWNI2Ja6+yOdg5H/J+nhmZGapNJMDMvRBXeXQNeK6adIYillI0 1jNPmThCWtNpuP2if3+ugeQy8YL0ynLoXgyDAzKncSyDcQLp3DAHYJhw+QxxT1eHqvAk ahug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=petWBepd+z7rTabHUo4yc75aIKiLQFeXDQrFrZDx018=; b=SJ5fPYICWEOXzTVWbuhB0F2Lgdl7m4J0o1fnNE9IeE7h2080WVMKNgj2o296qUKhcJ b2MmJeB7qicquLSUofskMDJYBcSJOdm2WQHi+oDGmWSLm0elfbIFWhgao4zpaPfvTrJ9 RwKPN9/McuZMfDqdlrrrxW7RRsMuE5NhX3BmGilq3EyrhTy9PLCmIvOWpgi7aMi3OuO4 cP9Vdi1x9htmiDdckCZBVhB1iQNy38/KKA5bzQ231JJaJZU/msTcJUputp0HpMpFVFGO c4QaLFLr8Nqo3u43vfnPeYDVCEcE/YHP1ISRvKse1U7YKG4+r1HDx/2u5E9J7n9gQ+WF TmQg== X-Gm-Message-State: APjAAAWnrc60KRKb2fsvkusjy3sgJOmMDN2AKXanjt0Mb3Ep90ML7F83 eTvJBAKDI8z96r/tHzFccTa8zYSKQ6OPi3Axo+s= X-Google-Smtp-Source: APXvYqxE4i2Yd7xoC+n3VJDlByRU1WZwiR+WKboWglKfmjI/lxOuboBU6EtnFlQ/dGM+pIgaIyrFDovC7PpCevbjpeA= X-Received: by 2002:ac2:528e:: with SMTP id q14mr30045037lfm.17.1563805949161; Mon, 22 Jul 2019 07:32:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Mon, 22 Jul 2019 07:31:52 -0700 Message-ID: To: "David Carrel (carrel)" Cc: "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000190665058e45f264" Archived-At: Subject: Re: [Secdispatch] Controller-IKE X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 14:32:35 -0000 --000000000000190665058e45f264 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Document: draft-carrel-ipsecme-controller-ike-01.txt I took a quick look at this document, and I have a few thoughts, in no particular order. * I understand the desire to think of this as an extension of IKE, but it's actually pretty different, and I'm not sure how much leverage you are getting from trying to make them similar. * I think it would be useful to be a little clearer about what resource you are trying to conserve here. I get that using straight IKE would require N^2 associations, but this does as well. It doesn't require N^2 protocol exchanges, but it requires N^2 DH operations (if everyone wants to talk to everyone else). So, the main value seems to be that you can send to someone in 0-RTT without exchanging any messages beforehand. Is that correct? * The PFS story here seems pretty bad: I'm assuming that people aren't going to change their DH keys very often (as it's extremely expensive for everyone else). * What happens if node A takes node B's DH key and nonce and advertises them as its own? If I understand the draft correctly, C will end up with the same SPKI and keys between C-B and C-A. Is that right? If so, that sounds at minimum like an identity misbinding attack, but if you are using implicit IVs (https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-07), then wouldn't you get nonce reuse, which would be quite bad. * You also seem to have a KCI problem, where if your keys is compromised, an attacker can impersonate anyone to you. ISTM that you would be in a better position if you adopted a 0-RTT DH flow in the style of OPTLS. I.e., A and B each have keys g^a, g^b and you mix them in with ephemeral DH keys g^x and g^y. This kind of exchange is reasonably well studied, and has good PFS and key confirmation properties. You can piggyback the key establishment messages along with the data you want to send, so you'll still get data on the first message. -Ekr On Fri, Jul 19, 2019 at 7:20 PM David Carrel (carrel) wrote: > Folks, > > > > I would like to present Controller-IKE in the Montreal Security Dispatch > meeting. There is growing interest from routing folks, and I strongly fe= el > we should evaluate and progress this in the security area. I=E2=80=99ll = have some > slides to share shortly. For now, please do read the draft. Also there > are some drafts referencing this: > > > > Controller-IKE: > https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-01 > > > > Also some docs referencing this form of key management: > > BESS, Secure EVPN: > https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-02 > > And: https://tools.ietf.org/html/draft-dunbar-bess-bgp-sdwan-usage-01 > > > > Comments appreciated. > > > > Dave > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --000000000000190665058e45f264 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Document: draft-carrel-ipsecme-controller-ike-01.txt<= br>
I took a quick look at this document, and I have a few thoughts,
= in no particular order.

* I understand the desire to think of this a= s an extension
of IKE, but it's actually pretty different, and I'= ;m not sure
how much leverage you are getting from trying to make themsimilar.

* I think it would be useful to be a little clearer about= what
resource you are trying to conserve here. I get that using straigh= t
IKE would require N^2 associations, but this does as well. It doesn= 9;t
require N^2 protocol exchanges, but it requires N^2 DH operations (i= f
everyone wants to talk to everyone else). So, the main value seems
= to be that you can send to someone in 0-RTT without exchanging
any messa= ges beforehand. Is that correct?

* The PFS story here seems pretty b= ad: I'm assuming that people
aren't going to change their DH key= s very often (as it's extremely
expensive for everyone else).
* What happens if node A takes node B's DH key and nonce and
advert= ises them as its own? If I understand the draft correctly,
C will end up= with the same SPKI and keys between C-B and C-A.
Is that right? If so, = that sounds at minimum like an identity
misbinding attack, but if you ar= e using implicit IVs
(https://tools.ietf.org/html/draft-ietf-ipsecme-impl= icit-iv-07),
then wouldn't you get nonce reuse, which would be q= uite bad.

* You also seem to have a KCI problem, where if your keys = is
compromised, an attacker can impersonate anyone to you.


IS= TM that you would be in a better position if you adopted a 0-RTT DH
flow= in the style of OPTLS. I.e., A and B each have keys g^a, g^b and
you mi= x them in with ephemeral DH keys g^x and g^y. This kind of
exchange is r= easonably well studied, and has good PFS and key
confirmation properties= . You can piggyback the key establishment
messages along with the data y= ou want to send, so you'll still get
data on the first message.
<= br>
-Ekr











On Fri, Jul 19, 2019 at 7:20 PM David Carrel (carrel) <<= a href=3D"mailto:carrel@cisco.com">carrel@cisco.com> wrote:

Folks,<= /span>

=C2=A0<= /span>

I would like to prese= nt Controller-IKE in the Montreal Security Dispatch meeting.=C2=A0 There is= growing interest from routing folks, and I strongly feel we should evaluat= e and progress this in the security area.=C2=A0 I=E2=80=99ll have some slides to share shortly.=C2=A0 For now, please do r= ead the draft.=C2=A0 Also there are some drafts referencing this:=

=C2=A0<= /span>

Controller-IKE: https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-01

=C2=A0<= /span>

Also some docs refere= ncing this form of key management:

BESS, Secure EVPN: https://tools.ietf.org/html/draft-sajassi-bess-secure= -evpn-02

And: https://tools.ietf.org/html/draft-dunbar-bess-bgp-sdwan-usage-= 01

=C2=A0<= /span>

Comments appreciated.=

=C2=A0<= /span>

Dave

=C2=A0<= /span>

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--000000000000190665058e45f264-- From nobody Mon Jul 22 07:59:28 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08A91200B1 for ; Mon, 22 Jul 2019 07:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, 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 header.b=eht/wFpi; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=RKMiD61M 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 8qLZISLUkiZK for ; Mon, 22 Jul 2019 07:59:23 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 171F4120059 for ; Mon, 22 Jul 2019 07:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16249; q=dns/txt; s=iport; t=1563807562; x=1565017162; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ILz8DL2ipaE5KFMI6XcITX+pHtjYpeRIFEHO5WAF/+E=; b=eht/wFpiFrVpikRy/i0imLYAx97YT29/+h1DTOo3aLPwQ8e998cZ7JTw hXm93j6KjcCtAyruSa4u3STrHDpCd16ORvxnBhBGleHHVQuS7fc3RneLQ ho8BeMBuMB6YL1bZaZiJcA1yL15v3VtArWhXqPf7DOU/tYQvW4O9ce+3P w=; IronPort-PHdr: =?us-ascii?q?9a23=3A8zFIwxNEM08pZ9d0/wkl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEuKQ/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjwJeTwYigSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAABrzjVd/5xdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGBFC9QA21VIAQLKoQdg0cDhFKJK4JbiVSJJ4R?= =?us-ascii?q?VgS6BJANUCQEBAQwBARgBDAgCAQGDekYCF4JMIzQJDgEDAQEEAQECAQZthR4?= =?us-ascii?q?MhUoBAQEBAwEBEBEdAQEsCwEPAgEIEQMBAigDAgICHwYLFAkIAgQOBSKDAAG?= =?us-ascii?q?BHU0DHQECDKAdAoE4iGBxgTKCeQEBBYE2Ag5BQII8DQuCEwMGgTQBi14XgX+?= =?us-ascii?q?BEScfgkw+ghpHAQEDAYF9DQmCVTKCJo54hH6Ia41GQAkCghmGWIlAg3Qbgi2?= =?us-ascii?q?HJYQMiiyUfYF1jhMCBAIEBQIOAQEFgVA4gVhwFTsqAYJBgkKDcYUUhT9yAQu?= =?us-ascii?q?BHY5xAQE?= X-IronPort-AV: E=Sophos;i="5.64,295,1559520000"; d="scan'208,217";a="599824900" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jul 2019 14:59:21 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x6MExMtd003474 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Jul 2019 14:59:22 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 22 Jul 2019 09:59:21 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 22 Jul 2019 09:59:20 -0500 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 22 Jul 2019 10:59:20 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cgmpGD9I020uQudAg6EKvziod/2kRNfyD0gnYeCd8VwFYmcbpqiRZAT7UIgGXovnf+wrWhkiP+TMsLGcUpucr9b7pzjFxS6IIccslJ1o4pAR6IFbqXYaahEf6VdtHEFiRyDZZTs8jbOp1NBEfSjxx0utC1tgaqxvHlGUBwfpPMW5jjOfGHCUw6AhU7mwgcuP26zurQuCWwzYn5seHz1DhKp3oPmxqm9o5qQLiyP56sTbkWqazTZNIRqv6/1sTYVkguohTNO76+qgq4uWFZxtZ7pRNtAtuG8P41soCblALPuhFJjq2A/D/ap2z8IeUIiwY8LuTRvJZ2RlX/glGgszvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ILz8DL2ipaE5KFMI6XcITX+pHtjYpeRIFEHO5WAF/+E=; b=kQYIWfb+QEVke+G+qwOgjdCRZl9uJTtTO2uYT1s9rLbF5BPquaPpU0VM9IGovFRiXGN/1o+QAE6nzUYUcXx4IpnCIj01TZ85SedVUGE43gtQH6J+GlMVypPfajnnF13gVN9l+mXpNwEiE9i4FeAmktsxWlLjLTOkY2MElp+8cScHE02qN8cuylvBVWuLM7kNoQCZfmYYgMTknMaNhULXWHF/JVFu79SFK544vcOLijv/muxnWkhQS6SZHaEPLoh+oA8apT9joYIXMFVK9+blRZC2tuhiiZT7vZ/jVoBzttezD7bMwvs6K6H1e1Bx9Moj9sLBzkEM2Rio6p41Ms66DA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ILz8DL2ipaE5KFMI6XcITX+pHtjYpeRIFEHO5WAF/+E=; b=RKMiD61MDYhyWH3qHbBp/aDUc9tN3FL+s4YJgJ26kV2ZjOSqOhXZNB6SJrJmzSdXJ78QwDDCcrmxUGoPvitamz8e/61Ib4XzFMiFsQ8/YlvF0XYdxzZIGuk4vB7KutSoLUAI92WQgsMWLDsN0ypBReqSxpFzh7fLBwofK6Mjg7g= Received: from BYAPR11MB3046.namprd11.prod.outlook.com (20.177.225.213) by BYAPR11MB3206.namprd11.prod.outlook.com (20.177.127.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Mon, 22 Jul 2019 14:59:18 +0000 Received: from BYAPR11MB3046.namprd11.prod.outlook.com ([fe80::c895:4d83:c5b8:b3d6]) by BYAPR11MB3046.namprd11.prod.outlook.com ([fe80::c895:4d83:c5b8:b3d6%6]) with mapi id 15.20.2073.012; Mon, 22 Jul 2019 14:59:18 +0000 From: "David Carrel (carrel)" To: Kathleen Moriarty CC: "secdispatch@ietf.org" Thread-Topic: [Secdispatch] Controller-IKE Thread-Index: AQHVPqG2qaTEIVD/zEy+2+Xv9S/jD6bWtjWA//+TP4A= Date: Mon, 22 Jul 2019 14:59:18 +0000 Message-ID: <10D8DC7B-13D7-474B-89EF-905C5B31DEBE@cisco.com> 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=carrel@cisco.com; x-originating-ip: [2001:420:c0c8:1008::132] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 49345e50-17da-454f-7727-08d70eb52c10 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3206; x-ms-traffictypediagnostic: BYAPR11MB3206: x-ms-exchange-purlcount: 7 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01068D0A20 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(366004)(346002)(396003)(136003)(189003)(199004)(14444005)(2906002)(68736007)(256004)(99286004)(81156014)(8676002)(81166006)(25786009)(4326008)(8936002)(66946007)(66446008)(7736002)(36756003)(76116006)(66556008)(5660300002)(2616005)(66476007)(476003)(46003)(11346002)(14454004)(33656002)(446003)(64756008)(316002)(606006)(6506007)(229853002)(6306002)(102836004)(71190400001)(6246003)(54896002)(6512007)(6116002)(6916009)(53936002)(76176011)(86362001)(71200400001)(6436002)(966005)(6486002)(486006)(478600001)(186003)(53546011)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3206; H:BYAPR11MB3046.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: hxEZnYCRRvcHI2FyL0phKo8IubMpxPsSb9k4KRHlRh+LQrvq3uemr9VsSGgBRkEQ1gP1Pb88UbJSX395m5Ohp+5qlHro5RJyvLItCM5VsrPhly8AvSFPIVZFgcnqj121U/Mq4Mqc9dwQ4YaSB6peqGmS+lFBr9B9WbT4jbOtkAe38Aqc8wHi1jOlYWJ71Pc/e+F5TtVzFq4lSF1t13Eo6a8+eKGwI8Lx7n3GfEJEuyoK7ldd7uiayqdz8EXI8nfaqC24ahAAI3G/BJC/0JX9O2vfLEEyRt3QTAO+j46kv+sIKpnW52Z5BYeTLfAoS12XxAi2Or5lRVm7fSsFICIITR0Foj6TYHLsC1Dn8SqA8DKbm8+AlWtXYpsOj8DDc/859Oc7gOukl+WqpwWw3RHDfN7jRsWi560BRF89o/HzwLI= Content-Type: multipart/alternative; boundary="_000_10D8DC7B13D7474B89EF905C5B31DEBEciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 49345e50-17da-454f-7727-08d70eb52c10 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2019 14:59:18.5671 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: carrel@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3206 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.28, xch-rcd-018.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Secdispatch] Controller-IKE X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 14:59:26 -0000 --_000_10D8DC7B13D7474B89EF905C5B31DEBEciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S2F0aGxlZW4sDQoNCkkgaGF2ZSBkaXNjdXNzZWQgQ29udHJvbGxlci1JS0UgaW4gdGhlIEkyTlNG IG1lZXRpbmdzIGFuZCBJIGZvbGxvdyBpdCBjbG9zZWx5LiAgSTJOU0YgZmxvdyBwcm90ZWN0aW9u IGRyYWZ0IGRpc2N1c3NlcyB0d28gd2F5cyB0byBjb25maWd1cmUgdGhlIGRldmljZSBmb3Iga2V5 IG1hbmFnZW1lbnQuICBZb3UgY2FuIGNvbmZpZ3VyZSBpdCBmb3IgSUtFIGFuZCBzZW5kIGFsbCB0 aGUgc3RhdGljIElLRSBjb25maWd1cmF0aW9uIHRvIHRoZSBkZXZpY2UsIG9yIHlvdSBjYW4gY29u ZmlndXJlIGl0IGZvciBOTyBrZXkgZXhjaGFuZ2UgYW5kIGhhdmUgdGhlIGNvbnRyb2wgc3RhdGlv biBwdXNoIHRoZSBJUHNlYyBrZXlzIHRvIHRoZSBkZXZpY2UuICBUaGUgSUtFIG9wdGlvbiBpcyBw cmV0dHkgc3RyYWlnaHRmb3J3YXJkIGFuZCBzdGFuZGFyZC4gIFRoZSBzdGF0aWMga2V5IG9wdGlv biBpcyDigKYgd2hhdCBpdCBpcy4NCg0KQ29udG9sbGVyLUlLRSB3b3VsZCBhbHNvIGZpdCBpbnRv IHRoZSBJMk5TRiBmcmFtZXdvcmsuICBJZiBDb250cm9sbGVyLUlLRSBtb3ZlcyBmb3J3YXJkLCB0 aGVuIEkgd291bGQgd2FudCB0byBzZWUgYWRkaXRpb25zIHRvIHRoZSBJMk5TRiBmbG93IHByb3Rl Y3Rpb24gdG8gYWxsb3cgaXQgdG8gY29uZmlndXJlIGEgM3JkIGtleSBtYW5hZ2VtZW50IG9wdGlv bi4gIEkyTlNGIGZsb3cgcHJvdGVjdGlvbiB3b3VsZCBub3QgY2FycnkgdGhlIENvbnRyb2xsZXIt SUtFIG1lc3NhZ2VzLCBidXQgaXQgd291bGQgY29uZmlndXJlIHRoZSBkZXZpY2UgdG8gZG8gQ29u dHJvbGxlci1JS0UuICBUaGUgYWN0dWFsIENvbnRyb2xsZXItSUtFIGV4Y2hhbmdlIHdvdWxkIGJl IHdpdGggdGhlIFJSLg0KDQpEYXZlDQoNCg0KRnJvbTogS2F0aGxlZW4gTW9yaWFydHkgPGthdGhs ZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPg0KRGF0ZTogTW9uZGF5LCBKdWx5IDIyLCAyMDE5 IGF0IDEwOjI5IEFNDQpUbzogIkRhdmlkIENhcnJlbCAoY2FycmVsKSIgPGNhcnJlbEBjaXNjby5j b20+DQpDYzogInNlY2Rpc3BhdGNoQGlldGYub3JnIiA8c2VjZGlzcGF0Y2hAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW1NlY2Rpc3BhdGNoXSBDb250cm9sbGVyLUlLRQ0KDQpIaSBEYXZpZCwNCg0K Q291bGQgeW91IHBsZWFzZSBleHBsYWluIGhvdyB0aGlzIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBh ZG9wdGVkIHdvcmsgaW4gSTJOU0YsIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtaTJuc2Ytc2RuLWlwc2VjLWZsb3ctcHJvdGVjdGlvbi8gPw0KDQpUaGlzIGlzIHJl ZmVyZW5jZWQgaW4geW91ciBkcmFmdCBhbG9uZyB3aXRoIG9uZSBhbm90aGVyLCBidXQgdGhlcmUg aXMgbm8gYW5hbHlzaXMgb24gd2h5IHRoZXkgZG9uJ3QgZml0IHRoZSBuZWVkLiAgVGhlIGRyYWZ0 IGluIEkyTlNGIHB1bGxlZCBpbiB0aGUgSVBzZWNNZSB3b3JraW5nIGdyb3VwIGFuZCB1bmRlcndl bnQgc2lnbmlmaWNhbnQgcmV2aXNpb25zIGFzIGEgcmVzdWx0IHRvIGRlYWwgd2l0aCBzZXZlcmFs IGluaXRpYWwgc2VjdXJpdHkgaXNzdWVzLiAgSWYgdGhlcmUgJ3MgYSBnYXAgdGhhdCBjYW4gYmUg c29sdmVkIHdpdGggdGhhdCBkcmFmdCwgY291bGQgdGhhdCBiZSBhIHdheSBmb3J3YXJkIG9yIGlz IHRoaXMgbmVlZGVkIGZvciBzb21lIHNwZWNpZmljIHJlYXNvbj8gIEl0IHdvdWxkIGJlIGhlbHBm dWwgdG8gdW5kZXJzdGFuZCB0aGlzLg0KDQpUaGFuayB5b3UsDQpLYXRobGVlbg0KDQpPbiBGcmks IEp1bCAxOSwgMjAxOSBhdCAxMDoyMCBQTSBEYXZpZCBDYXJyZWwgKGNhcnJlbCkgPGNhcnJlbEBj aXNjby5jb208bWFpbHRvOmNhcnJlbEBjaXNjby5jb20+PiB3cm90ZToNCkZvbGtzLA0KDQpJIHdv dWxkIGxpa2UgdG8gcHJlc2VudCBDb250cm9sbGVyLUlLRSBpbiB0aGUgTW9udHJlYWwgU2VjdXJp dHkgRGlzcGF0Y2ggbWVldGluZy4gIFRoZXJlIGlzIGdyb3dpbmcgaW50ZXJlc3QgZnJvbSByb3V0 aW5nIGZvbGtzLCBhbmQgSSBzdHJvbmdseSBmZWVsIHdlIHNob3VsZCBldmFsdWF0ZSBhbmQgcHJv Z3Jlc3MgdGhpcyBpbiB0aGUgc2VjdXJpdHkgYXJlYS4gIEnigJlsbCBoYXZlIHNvbWUgc2xpZGVz IHRvIHNoYXJlIHNob3J0bHkuICBGb3Igbm93LCBwbGVhc2UgZG8gcmVhZCB0aGUgZHJhZnQuICBB bHNvIHRoZXJlIGFyZSBzb21lIGRyYWZ0cyByZWZlcmVuY2luZyB0aGlzOg0KDQpDb250cm9sbGVy LUlLRTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhcnJlbC1pcHNlY21lLWNv bnRyb2xsZXItaWtlLTAxDQoNCkFsc28gc29tZSBkb2NzIHJlZmVyZW5jaW5nIHRoaXMgZm9ybSBv ZiBrZXkgbWFuYWdlbWVudDoNCkJFU1MsIFNlY3VyZSBFVlBOOiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtc2FqYXNzaS1iZXNzLXNlY3VyZS1ldnBuLTAyDQpBbmQ6IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kdW5iYXItYmVzcy1iZ3Atc2R3YW4tdXNhZ2UtMDEN Cg0KQ29tbWVudHMgYXBwcmVjaWF0ZWQuDQoNCkRhdmUNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NClNlY2Rpc3BhdGNoIG1haWxpbmcgbGlzdA0KU2Vj ZGlzcGF0Y2hAaWV0Zi5vcmc8bWFpbHRvOlNlY2Rpc3BhdGNoQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXNwYXRjaA0KDQoNCi0tDQoNCkJlc3Qg cmVnYXJkcywNCkthdGhsZWVuDQo= --_000_10D8DC7B13D7474B89EF905C5B31DEBEciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1CC851058478FF46A16C018A41005626@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkthdGhsZWVuLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgZGlzY3Vz c2VkIENvbnRyb2xsZXItSUtFIGluIHRoZSBJMk5TRiBtZWV0aW5ncyBhbmQgSSBmb2xsb3cgaXQg Y2xvc2VseS4mbmJzcDsgSTJOU0YgZmxvdyBwcm90ZWN0aW9uIGRyYWZ0IGRpc2N1c3NlcyB0d28g d2F5cyB0byBjb25maWd1cmUgdGhlIGRldmljZSBmb3Iga2V5IG1hbmFnZW1lbnQuJm5ic3A7IFlv dSBjYW4gY29uZmlndXJlIGl0IGZvciBJS0UgYW5kIHNlbmQgYWxsIHRoZSBzdGF0aWMgSUtFIGNv bmZpZ3VyYXRpb24NCiB0byB0aGUgZGV2aWNlLCBvciB5b3UgY2FuIGNvbmZpZ3VyZSBpdCBmb3Ig Tk8ga2V5IGV4Y2hhbmdlIGFuZCBoYXZlIHRoZSBjb250cm9sIHN0YXRpb24gcHVzaCB0aGUgSVBz ZWMga2V5cyB0byB0aGUgZGV2aWNlLiZuYnNwOyBUaGUgSUtFIG9wdGlvbiBpcyBwcmV0dHkgc3Ry YWlnaHRmb3J3YXJkIGFuZCBzdGFuZGFyZC4mbmJzcDsgVGhlIHN0YXRpYyBrZXkgb3B0aW9uIGlz IOKApiB3aGF0IGl0IGlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db250b2xsZXItSUtFIHdv dWxkIGFsc28gZml0IGludG8gdGhlIEkyTlNGIGZyYW1ld29yay4mbmJzcDsgSWYgQ29udHJvbGxl ci1JS0UgbW92ZXMgZm9yd2FyZCwgdGhlbiBJIHdvdWxkIHdhbnQgdG8gc2VlIGFkZGl0aW9ucyB0 byB0aGUgSTJOU0YgZmxvdyBwcm90ZWN0aW9uIHRvIGFsbG93IGl0IHRvIGNvbmZpZ3VyZSBhIDM8 c3VwPnJkPC9zdXA+IGtleSBtYW5hZ2VtZW50IG9wdGlvbi4mbmJzcDsgSTJOU0YgZmxvdyBwcm90 ZWN0aW9uDQogd291bGQgbm90IGNhcnJ5IHRoZSBDb250cm9sbGVyLUlLRSBtZXNzYWdlcywgYnV0 IGl0IHdvdWxkIGNvbmZpZ3VyZSB0aGUgZGV2aWNlIHRvIGRvIENvbnRyb2xsZXItSUtFLiZuYnNw OyBUaGUgYWN0dWFsIENvbnRyb2xsZXItSUtFIGV4Y2hhbmdlIHdvdWxkIGJlIHdpdGggdGhlIFJS LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXZlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+S2F0aGxlZW4gTW9yaWFydHkgJmx0O2thdGhs ZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXks IEp1bHkgMjIsIDIwMTkgYXQgMTA6MjkgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O0RhdmlkIENh cnJlbCAoY2FycmVsKSZxdW90OyAmbHQ7Y2FycmVsQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzog PC9iPiZxdW90O3NlY2Rpc3BhdGNoQGlldGYub3JnJnF1b3Q7ICZsdDtzZWNkaXNwYXRjaEBpZXRm Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtTZWNkaXNwYXRjaF0gQ29udHJvbGxl ci1JS0U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+SGkgRGF2aWQsIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Db3Vs ZCB5b3UgcGxlYXNlIGV4cGxhaW4gaG93IHRoaXMgaXMgZGlmZmVyZW50IGZyb20gdGhlIGFkb3B0 ZWQgd29yayBpbiBJMk5TRiwmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWkybnNmLXNkbi1pcHNlYy1mbG93LXByb3RlY3Rpb24vIj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkybnNmLXNkbi1pcHNlYy1m bG93LXByb3RlY3Rpb24vPC9hPiZuYnNwOz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj5UaGlzIGlzIHJlZmVyZW5jZWQgaW4geW91ciBkcmFmdCBhbG9uZyB3 aXRoIG9uZSBhbm90aGVyLCBidXQgdGhlcmUgaXMgbm8gYW5hbHlzaXMgb24gd2h5IHRoZXkgZG9u J3QgZml0IHRoZSBuZWVkLiZuYnNwOyBUaGUgZHJhZnQgaW4gSTJOU0YgcHVsbGVkIGluIHRoZSBJ UHNlY01lIHdvcmtpbmcgZ3JvdXAgYW5kIHVuZGVyd2VudCBzaWduaWZpY2FudCByZXZpc2lvbnMg YXMgYQ0KIHJlc3VsdCB0byBkZWFsIHdpdGggc2V2ZXJhbCBpbml0aWFsIHNlY3VyaXR5IGlzc3Vl cy4mbmJzcDsgSWYgdGhlcmUgJ3MgYSBnYXAgdGhhdCBjYW4gYmUgc29sdmVkIHdpdGggdGhhdCBk cmFmdCwgY291bGQgdGhhdCBiZSBhIHdheSBmb3J3YXJkIG9yIGlzIHRoaXMgbmVlZGVkIGZvciBz b21lIHNwZWNpZmljIHJlYXNvbj8mbmJzcDsgSXQgd291bGQgYmUgaGVscGZ1bCB0byB1bmRlcnN0 YW5kIHRoaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ VGhhbmsgeW91LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkthdGhsZWVuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gRnJpLCBKdWwgMTksIDIwMTkgYXQgMTA6 MjAgUE0gRGF2aWQgQ2FycmVsIChjYXJyZWwpICZsdDs8YSBocmVmPSJtYWlsdG86Y2FycmVsQGNp c2NvLmNvbSI+Y2FycmVsQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6LjVpbiI+DQpGb2xrcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KSSB3b3VsZCBsaWtlIHRvIHByZXNl bnQgQ29udHJvbGxlci1JS0UgaW4gdGhlIE1vbnRyZWFsIFNlY3VyaXR5IERpc3BhdGNoIG1lZXRp bmcuJm5ic3A7IFRoZXJlIGlzIGdyb3dpbmcgaW50ZXJlc3QgZnJvbSByb3V0aW5nIGZvbGtzLCBh bmQgSSBzdHJvbmdseSBmZWVsIHdlIHNob3VsZCBldmFsdWF0ZSBhbmQgcHJvZ3Jlc3MgdGhpcyBp biB0aGUgc2VjdXJpdHkgYXJlYS4mbmJzcDsgSeKAmWxsIGhhdmUgc29tZSBzbGlkZXMgdG8gc2hh cmUgc2hvcnRseS4mbmJzcDsgRm9yIG5vdywNCiBwbGVhc2UgZG8gcmVhZCB0aGUgZHJhZnQuJm5i c3A7IEFsc28gdGhlcmUgYXJlIHNvbWUgZHJhZnRzIHJlZmVyZW5jaW5nIHRoaXM6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4N CkNvbnRyb2xsZXItSUtFOiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtY2FycmVsLWlwc2VjbWUtY29udHJvbGxlci1pa2UtMDEiIHRhcmdldD0iX2JsYW5rIj4NCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYXJyZWwtaXBzZWNtZS1jb250cm9sbGVy LWlrZS0wMTwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0Oi41aW4iPg0KQWxzbyBzb21lIGRvY3MgcmVmZXJlbmNpbmcgdGhpcyBmb3Jt IG9mIGtleSBtYW5hZ2VtZW50OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0Oi41aW4iPg0KQkVTUywgU2VjdXJlIEVWUE46IDxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWphc3NpLWJlc3Mtc2VjdXJlLWV2cG4tMDIiIHRh cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWphc3Np LWJlc3Mtc2VjdXJlLWV2cG4tMDI8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpBbmQ6IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1kdW5iYXItYmVzcy1iZ3Atc2R3YW4tdXNhZ2UtMDEiIHRhcmdldD0i X2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kdW5iYXItYmVzcy1i Z3Atc2R3YW4tdXNhZ2UtMDE8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCkNvbW1lbnRzIGFwcHJlY2lhdGVkLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVp biI+DQpEYXZlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpTZWNkaXNwYXRjaCBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86U2VjZGlzcGF0Y2hAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5TZWNkaXNwYXRjaEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpc3BhdGNoIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXNwYXRjaDwvYT48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5LYXRobGVlbjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_10D8DC7B13D7474B89EF905C5B31DEBEciscocom_-- From nobody Mon Jul 22 08:42:54 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD6512013B for ; Mon, 22 Jul 2019 08:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, 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 header.b=U3k2wVvQ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QxaDYHtu 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 yNQVCVLV61xh for ; Mon, 22 Jul 2019 08:42:49 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 082DB12012B for ; Mon, 22 Jul 2019 08:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24353; q=dns/txt; s=iport; t=1563810168; x=1565019768; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jTeJHbMO0JRUCyK8CO/eyLGA4MO2VJIyQ5vHBLrtDdI=; b=U3k2wVvQJHoXeA1akWTkfdrqFU0oI/zev7D8NnsWd5fCuncYu9WUk+IJ eXUhg16CVPAf+Ff3pVVxTQ2VsaQNO+7GHqi3/a9DchhpCqvneTIF1FXq+ WA35w9sWVgiUKxDbOr+IY8/kHXkyBMAqescy7m9MAigN8Vl2ZRvQKVMRC 4=; IronPort-PHdr: =?us-ascii?q?9a23=3ADLxZ1h09BFedW94rsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxGOt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQAkThNvPuRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIAAAb2DVd/5RdJa1dCRwBAQEEAQE?= =?us-ascii?q?HBAEBgVMHAQELAYEULyQFJwNtVSAECyqEHYNHA4RSiSuCNiWSe4RVgS6BJAN?= =?us-ascii?q?UCQEBAQwBARgBCgoCAQGDekYCF4JMIzQJDgEDAQEEAQECAQZthR4MhUoBAQE?= =?us-ascii?q?BAwEBEBEdAQEsCwEPAgEIDgMDAQIoAwICAiULFAkIAgQOBSKDAAGBHU0DHQE?= =?us-ascii?q?CDKAlAoE4iGBxgTKCeQEBBYE2AoEPgj4YghMDBoE0AYkVdoFTF4F/gREnDBO?= =?us-ascii?q?CTD6CYQEBA4E0Sg0JglUygiaOeIR+iGuNGW0JAoIZhliEboN+BYRDG4IthyW?= =?us-ascii?q?EDIoslH2QCAIEAgQFAg4BAQWBUDiBWHAVOyoBgkGCQoEmAQiCQoUUhT9yDIE?= =?us-ascii?q?djCErgiUBAQ?= X-IronPort-AV: E=Sophos;i="5.64,295,1559520000"; d="scan'208,217";a="600101951" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jul 2019 15:42:47 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x6MFgl0b001571 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Jul 2019 15:42:47 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 22 Jul 2019 10:42:47 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 22 Jul 2019 10:42:46 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 22 Jul 2019 11:42:46 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kTg5m9F94/NtHLJeu9g6cNAAanAFIeSM3UQZYMfq2nW/BMK/Abg9NtxSjQa3FbJmadTW9a4DnGPoj92aVBinoDBlcEebYK2vqcV2LWY37/bDc6U89dGE/LiDwmR9Er1rfF8R2/ybXHQufqFlxwxf7pJpOT74RJ3ZyaKgbTBNjoPOOgW8FluuaqTzpVX+5GCCztcyktyzDHf/k59WNwKhwhQB4Pqq01tPOOJnGF001N2NniMKSfZOotNlMJy15yNICBbs320XVA66aymxYqX4OlnCpRIG1mtFXecw+A8UbbDg/ZiMEociieY7bzT1vrmFNkPcVU2RGUeOHzvIkApb8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jTeJHbMO0JRUCyK8CO/eyLGA4MO2VJIyQ5vHBLrtDdI=; b=CnsqoMupc4fqf/CJ/LYwi8Y3kUN6xJ5G7GU/CQCvQ7ofcde1vJ3MrfVPYn7pReJ/m0jr1qr9vfbbmsBzNMkWb9G2qS27/LaF7cA6Cn0FI+QXxKVzO9YqEG6U54gIqlxcxdtWtJnN5DaQfaYQBRTddR9d9Wa8K6/2l81RX0jfhNnYfHQ45Rzl3K2lnZmSrHMuYC09pwimsmtj7gHBYQVbAda/HponzZez3+6B2wdLL3MxiYL8xI5b0aA4r4YRn8tATqJuZjorj5cYXg3h1C2nKjzcxifXBDcR/ugPRg0XdUEk5V2LoJW7kDj4AE7vQ+E6ptQoMBJQcG+DEwfqRv96zg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jTeJHbMO0JRUCyK8CO/eyLGA4MO2VJIyQ5vHBLrtDdI=; b=QxaDYHtuLnZT01I2MPyMsl1pzmVisLwOZQuYEGPkA6OvWVUtjcNqHt/WxZdygP5HtHrV7P04OCxe9v6MXOAVe61CidzuI0ZzugSe7dr6YVnS9xsRqx8kHjWPzHoU8ai0V5qlTs4POrTL7FwgGnBTu9RfwhZ0Lar00ZyiDHBcGGs= Received: from BYAPR11MB3046.namprd11.prod.outlook.com (20.177.225.213) by BYAPR11MB2758.namprd11.prod.outlook.com (52.135.228.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Mon, 22 Jul 2019 15:42:45 +0000 Received: from BYAPR11MB3046.namprd11.prod.outlook.com ([fe80::c895:4d83:c5b8:b3d6]) by BYAPR11MB3046.namprd11.prod.outlook.com ([fe80::c895:4d83:c5b8:b3d6%6]) with mapi id 15.20.2073.012; Mon, 22 Jul 2019 15:42:45 +0000 From: "David Carrel (carrel)" To: Eric Rescorla CC: "secdispatch@ietf.org" Thread-Topic: [Secdispatch] Controller-IKE Thread-Index: AQHVPqG2qaTEIVD/zEy+2+Xv9S/jD6bWtyQA//+edAA= Date: Mon, 22 Jul 2019 15:42:44 +0000 Message-ID: <698A5E01-5924-4D6C-9BD9-A8E87712086B@cisco.com> 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=carrel@cisco.com; x-originating-ip: [2001:420:c0c8:1008::132] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2de1e4ba-1358-4289-992e-08d70ebb3d9a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2758; x-ms-traffictypediagnostic: BYAPR11MB2758: x-ms-exchange-purlcount: 7 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01068D0A20 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(136003)(396003)(39860400002)(366004)(199004)(189003)(6486002)(486006)(6436002)(6916009)(316002)(478600001)(76176011)(6116002)(86362001)(25786009)(4326008)(71190400001)(71200400001)(14454004)(68736007)(8676002)(6506007)(476003)(81166006)(81156014)(2906002)(5660300002)(8936002)(186003)(91956017)(46003)(6246003)(7736002)(36756003)(76116006)(54896002)(6306002)(53546011)(966005)(53936002)(66476007)(66556008)(229853002)(66946007)(2616005)(102836004)(66446008)(33656002)(64756008)(11346002)(6512007)(99286004)(606006)(256004)(14444005)(446003)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2758; H:BYAPR11MB3046.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: d/CvJAVUE2P/OTkp2+6o9P1VHvrd3K4w+9z6/uHmSsKjOb4xuQF+ApLC12KvKdljbjX7xiXNSpBzGPrtX198/P4By64BrwVz0KMULwYGea6oCn4LoHvZPzei10wv+zlysfPcZJMhxJ9ixVb+52b9ig6qISFtzuhvkA7/+BYyL96VILBM3Ptbu2RQdhNLJ2wwNZdv5d+HdlcYvNcgFlst+WKaoPPT7Om1irn3YsWiGswmY3MfdE3wgFamLEBh5F2+e6YfaWGXj/fkcoRhJAl/gROgu23vx6gbKX5ZcIVJ7DIs39whIz1ZLwR05wmYErvPOEs0sihPvThxobTOKivFKqsde7nPqygLBh3PZOItRMEbMU5ifugIrZy3PgVA94N4ClhngRn8Gx6fu1yIjaFc9BAuTRRrbcmAuBunMVni2Qo= Content-Type: multipart/alternative; boundary="_000_698A5E0159244D6C9BD9A8E87712086Bciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2de1e4ba-1358-4289-992e-08d70ebb3d9a X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2019 15:42:44.9870 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: carrel@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2758 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [Secdispatch] Controller-IKE X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 15:42:52 -0000 --_000_698A5E0159244D6C9BD9A8E87712086Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RWtyLA0KDQpUaGFua3MhICBSZXNwb25zZXMgaW5saW5lIOKApg0KDQpGcm9tOiBFcmljIFJlc2Nv cmxhIDxla3JAcnRmbS5jb20+DQpEYXRlOiBNb25kYXksIEp1bHkgMjIsIDIwMTkgYXQgMTA6MzIg QU0NClRvOiAiRGF2aWQgQ2FycmVsIChjYXJyZWwpIiA8Y2FycmVsQGNpc2NvLmNvbT4NCkNjOiAi c2VjZGlzcGF0Y2hAaWV0Zi5vcmciIDxzZWNkaXNwYXRjaEBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbU2VjZGlzcGF0Y2hdIENvbnRyb2xsZXItSUtFDQoNCkRvY3VtZW50OiBkcmFmdC1jYXJyZWwt aXBzZWNtZS1jb250cm9sbGVyLWlrZS0wMS50eHQNCg0KSSB0b29rIGEgcXVpY2sgbG9vayBhdCB0 aGlzIGRvY3VtZW50LCBhbmQgSSBoYXZlIGEgZmV3IHRob3VnaHRzLA0KaW4gbm8gcGFydGljdWxh ciBvcmRlci4NCg0KKiBJIHVuZGVyc3RhbmQgdGhlIGRlc2lyZSB0byB0aGluayBvZiB0aGlzIGFz IGFuIGV4dGVuc2lvbg0Kb2YgSUtFLCBidXQgaXQncyBhY3R1YWxseSBwcmV0dHkgZGlmZmVyZW50 LCBhbmQgSSdtIG5vdCBzdXJlDQpob3cgbXVjaCBsZXZlcmFnZSB5b3UgYXJlIGdldHRpbmcgZnJv bSB0cnlpbmcgdG8gbWFrZSB0aGVtDQpzaW1pbGFyLg0KVGhpcyBpc27igJl0IGFuIGV4dGVuc2lv biBvZiBJS0UuICBJdCBpcyBhbiBhbHRlcm5hdGl2ZS4gIEl0IHByb3ZpZGVzIHRoZSBmdW5jdGlv bmFsaXR5IHRoYXQgYSBzdGFuZGFyZCBJS0UgcHJvY2VzcyBwcm92aWRlcy4gIEJhc2ljYWxseSBp dCBjcmVhdGVzIHBhaXJ3aXNlIGtleXMgYW5kIGNyZWF0ZXMgSVBzZWMgU0FzLiAgRm9yIGV4YW1w bGUsIHlvdSBjYW4gcmVtb3ZlIGEgTGludXggdXNlcnNwYWNlIElLRSBkYWVtb24gYW5kIHJlcGxh Y2UgaXQgd2l0aCBDb250cm9sbGVyLUlLRSBhbmQgc3RpbGwgdXRpbGl6ZSB0aGUgdW5tb2RpZmll ZCBrZXJuZWwgSVBzZWMuDQoNCg0KKiBJIHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBiZSBh IGxpdHRsZSBjbGVhcmVyIGFib3V0IHdoYXQNCnJlc291cmNlIHlvdSBhcmUgdHJ5aW5nIHRvIGNv bnNlcnZlIGhlcmUuIEkgZ2V0IHRoYXQgdXNpbmcgc3RyYWlnaHQNCklLRSB3b3VsZCByZXF1aXJl IE5eMiBhc3NvY2lhdGlvbnMsIGJ1dCB0aGlzIGRvZXMgYXMgd2VsbC4gSXQgZG9lc24ndA0KcmVx dWlyZSBOXjIgcHJvdG9jb2wgZXhjaGFuZ2VzLCBidXQgaXQgcmVxdWlyZXMgTl4yIERIIG9wZXJh dGlvbnMgKGlmDQpldmVyeW9uZSB3YW50cyB0byB0YWxrIHRvIGV2ZXJ5b25lIGVsc2UpLiBTbywg dGhlIG1haW4gdmFsdWUgc2VlbXMNCnRvIGJlIHRoYXQgeW91IGNhbiBzZW5kIHRvIHNvbWVvbmUg aW4gMC1SVFQgd2l0aG91dCBleGNoYW5naW5nDQphbnkgbWVzc2FnZXMgYmVmb3JlaGFuZC4gSXMg dGhhdCBjb3JyZWN0Pw0KWW91IGFyZSByaWdodCB0aGF0IHRoZXJlIGNvbnRpbnVlcyB0byBiZSBO XjIgYXNzb2NpYXRpb25zIGFuZCB0aGlzIGRvZXMgbm90IHJlZHVjZSB0aGUgREggY2FsY3VsYXRp b25zLCBidXQgKGFzIHlvdSBub3RlKSB0aGlzIGRvZXMgcmVkdWNlIHRoZSBudW1iZXIgb2YgcGVl ci10by1wZWVyIG1lc3NhZ2VzIGFuZCBkb2VzIHJlZHVjZSB0aGUgUlRULiAgRGVwZW5kaW5nIG9u IHRoZSBzaXplIG9mIHRoZSBmdWxsIG1lc2ggU0QtV0FOLCBhbmQgdGhlIGJhbmR3aWR0aCBjb3N0 cywgdGhlIHJlZHVjdGlvbiBvZiBtZXNzYWdlcyBpcyBkZWZpbml0ZWx5IGEgcG9zaXRpdmUuICBU aGVyZSBhcmUgb3RoZXIgYmVuZWZpdHMgc3VjaCBhcyBhbGxvd2luZyBmb3IgdGhlIHVzZSBvZiDi gJxzZWN1cmXigJ0gcHJvdmlzaW9uZWQgbmV0d29ya3MgZm9yIGNvbnRyb2wsIHdoaWxlIHV0aWxp emluZyBsb3dlciBzZWN1cml0eSAocHVibGljKSBuZXR3b3JrcyBmb3IgSVBzZWMgdHJhZmZpYy4g IEFuZCBpbiBmYWN0IHRoZXJlIGFyZSBhcHBsaWNhdGlvbnMgd2hlcmUgdGhlIGRhdGEgY29ubmVj dGlvbiBiZXR3ZWVuIHBlZXJzIGlzIE5PVCAyLXdheSwgbWVhbmluZyB0cmFkaXRpb25hbCBJS0Ug d2lsbCBub3QgZXN0YWJsaXNoIGJldHdlZW4gdGhlIHBlZXJzLCBidXQgdGhlIFNELVdBTiBkb2Vz IGNvbWUgdXAuDQoNCg0KKiBUaGUgUEZTIHN0b3J5IGhlcmUgc2VlbXMgcHJldHR5IGJhZDogSSdt IGFzc3VtaW5nIHRoYXQgcGVvcGxlDQphcmVuJ3QgZ29pbmcgdG8gY2hhbmdlIHRoZWlyIERIIGtl eXMgdmVyeSBvZnRlbiAoYXMgaXQncyBleHRyZW1lbHkNCmV4cGVuc2l2ZSBmb3IgZXZlcnlvbmUg ZWxzZSkuDQpUcnVlLCB0aGUgREggbG9hZCBjYW4gYmUgZXhwZW5zaXZlLCBidXQgbm8gbW9yZSBz byB0aGFuIGFuIGVxdWl2YWxlbnQgbWVzaCBvZiB0cmFkaXRpb25hbCBJS0UuICBXZSB3b3VsZCBu b3QgbmVlZCB0byByZS1rZXkgYW55IGxlc3Mgb2Z0ZW4uICBJIGJlbGlldmUgdGhpcyBtYWtlcyB0 aGUgUEZTIHN0b3J5IGVxdWl2YWxlbnQuICBJbiBhZGRpdGlvbiwgQ29udHJvbGxlci1JS0UgZG9l cyBhbGxvdyBmb3IgcmVzZW5kaW5nIHRoZSBzYW1lIERIIHB1YmxpYyB2YWx1ZSB3aXRoIGEgbmV3 IG5vbmNlLiAgVGhpcyBkb2VzbuKAmXQgaW1wcm92ZSBQRlMsIGJ1dCBkb2VzIGFsbG93IGZvciBh IG1vcmUgZnJlcXVlbnQgcmUta2V5aW5nIHdpdGhvdXQgaW5jdXJyaW5nIHRoZSBESCBjb3N0Lg0K DQoNCiogV2hhdCBoYXBwZW5zIGlmIG5vZGUgQSB0YWtlcyBub2RlIEIncyBESCBrZXkgYW5kIG5v bmNlIGFuZA0KYWR2ZXJ0aXNlcyB0aGVtIGFzIGl0cyBvd24/IElmIEkgdW5kZXJzdGFuZCB0aGUg ZHJhZnQgY29ycmVjdGx5LA0KQyB3aWxsIGVuZCB1cCB3aXRoIHRoZSBzYW1lIFNQS0kgYW5kIGtl eXMgYmV0d2VlbiBDLUIgYW5kIEMtQS4NCklzIHRoYXQgcmlnaHQ/IElmIHNvLCB0aGF0IHNvdW5k cyBhdCBtaW5pbXVtIGxpa2UgYW4gaWRlbnRpdHkNCm1pc2JpbmRpbmcgYXR0YWNrLCBidXQgaWYg eW91IGFyZSB1c2luZyBpbXBsaWNpdCBJVnMNCihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1pcHNlY21lLWltcGxpY2l0LWl2LTA3KSwNCnRoZW4gd291bGRuJ3QgeW91IGdl dCBub25jZSByZXVzZSwgd2hpY2ggd291bGQgYmUgcXVpdGUgYmFkLg0KVGhpcyBpcyBhIHZlcnkg Z29vZCBvYnNlcnZhdGlvbi4gIFRoZSBzdHJhaWdodGZvcndhcmQgYW5zd2VyIGlzIHRvIG1peCB0 aGUgY29udHJvbGxlciB2YWxpZGF0ZWQgaWRlbnRpdHkgaW50byB0aGUga2V5bWF0IHRvIGVuc3Vy ZSB0aGF0IHNvbWVvbmUgZWxzZSB1c2luZyBteSBESC9ub25jZSB3aWxsIG5vdCBnZW5lcmF0ZSB0 aGUgaWRlbnRpY2FsIGtleXMgd2l0aCBhIDNyZCBwZWVyLiAgVGhhbmtzISENCg0KDQoqIFlvdSBh bHNvIHNlZW0gdG8gaGF2ZSBhIEtDSSBwcm9ibGVtLCB3aGVyZSBpZiB5b3VyIGtleXMgaXMNCmNv bXByb21pc2VkLCBhbiBhdHRhY2tlciBjYW4gaW1wZXJzb25hdGUgYW55b25lIHRvIHlvdS4NCkkg ZG9u4oCZdCBzZWUgdGhpcz8gIENhbiB5b3UgZXhwbGFpbiBmdXJ0aGVyPyAgSWYgbXkgREggcHJp dmF0ZSBpcyBjb21wcm9taXNlZCwgdGhlbiBhbiBhdHRhY2tlciBjYW4gaW1wZXJzb25hdGUgbWUg dG8gYW55b25lIGVsc2UgKHVudGlsIEkgcmUta2V5KS4gIFByZXN1bWFibHkgaWYgeW91IGdldCBt eSBwcml2YXRlIERILCBJIGhhdmUgYmVlbiBjb21wcm9taXNlZCBmdWxseS4gIEJ1dCB0aGlzIGlz IHRoZSBzYW1lIHNpdHVhdGlvbiB3aXRoIGFueSBrZXkgbWFuYWdlbWVudCBwcm90b2NvbC4NCg0K DQoNCklTVE0gdGhhdCB5b3Ugd291bGQgYmUgaW4gYSBiZXR0ZXIgcG9zaXRpb24gaWYgeW91IGFk b3B0ZWQgYSAwLVJUVCBESA0KZmxvdyBpbiB0aGUgc3R5bGUgb2YgT1BUTFMuIEkuZS4sIEEgYW5k IEIgZWFjaCBoYXZlIGtleXMgZ15hLCBnXmIgYW5kDQp5b3UgbWl4IHRoZW0gaW4gd2l0aCBlcGhl bWVyYWwgREgga2V5cyBnXnggYW5kIGdeeS4gVGhpcyBraW5kIG9mDQpleGNoYW5nZSBpcyByZWFz b25hYmx5IHdlbGwgc3R1ZGllZCwgYW5kIGhhcyBnb29kIFBGUyBhbmQga2V5DQpjb25maXJtYXRp b24gcHJvcGVydGllcy4gWW91IGNhbiBwaWdneWJhY2sgdGhlIGtleSBlc3RhYmxpc2htZW50DQpt ZXNzYWdlcyBhbG9uZyB3aXRoIHRoZSBkYXRhIHlvdSB3YW50IHRvIHNlbmQsIHNvIHlvdSdsbCBz dGlsbCBnZXQNCmRhdGEgb24gdGhlIGZpcnN0IG1lc3NhZ2UuDQpEZWZpbml0ZWx5IHdvcnRoIGxv b2tpbmcgYXQuICBJIGNhbuKAmXQgZ2l2ZSB5b3UgYSBxdWljayByZXNwb25zZSBvbiB0aGlzLCBi dXQgSSB3aWxsIGNydW5jaCBvbiB0aGlzLiAgT2YgY291cnNlLCB0aGlzIHdvdWxkIGludm9sdmUg bW9kaWZ5aW5nIEVTUC4gIEkgd291bGRu4oCZdCB3YW50IHRvIG1ha2UgdGhhdCBhIHJlcXVpcmVt ZW50IHRvIHRoaXMgbW92aW5nIGZvcndhcmQsIGJ1dCBpdCBjb3VsZCBiZSBzZXBhcmF0ZWx5IGNv bnNpZGVyZWQgYXMgYW4gRVNQIGV4dGVuc2lvbiB0aGF0IGFueSBLTVAgY291bGQgYXZhaWwgdGhl bXNlbHZlcyBvZi4NCi1Fa3INCg0KRGF2ZQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KT24gRnJp LCBKdWwgMTksIDIwMTkgYXQgNzoyMCBQTSBEYXZpZCBDYXJyZWwgKGNhcnJlbCkgPGNhcnJlbEBj aXNjby5jb208bWFpbHRvOmNhcnJlbEBjaXNjby5jb20+PiB3cm90ZToNCkZvbGtzLA0KDQpJIHdv dWxkIGxpa2UgdG8gcHJlc2VudCBDb250cm9sbGVyLUlLRSBpbiB0aGUgTW9udHJlYWwgU2VjdXJp dHkgRGlzcGF0Y2ggbWVldGluZy4gIFRoZXJlIGlzIGdyb3dpbmcgaW50ZXJlc3QgZnJvbSByb3V0 aW5nIGZvbGtzLCBhbmQgSSBzdHJvbmdseSBmZWVsIHdlIHNob3VsZCBldmFsdWF0ZSBhbmQgcHJv Z3Jlc3MgdGhpcyBpbiB0aGUgc2VjdXJpdHkgYXJlYS4gIEnigJlsbCBoYXZlIHNvbWUgc2xpZGVz IHRvIHNoYXJlIHNob3J0bHkuICBGb3Igbm93LCBwbGVhc2UgZG8gcmVhZCB0aGUgZHJhZnQuICBB bHNvIHRoZXJlIGFyZSBzb21lIGRyYWZ0cyByZWZlcmVuY2luZyB0aGlzOg0KDQpDb250cm9sbGVy LUlLRTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhcnJlbC1pcHNlY21lLWNv bnRyb2xsZXItaWtlLTAxDQoNCkFsc28gc29tZSBkb2NzIHJlZmVyZW5jaW5nIHRoaXMgZm9ybSBv ZiBrZXkgbWFuYWdlbWVudDoNCkJFU1MsIFNlY3VyZSBFVlBOOiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtc2FqYXNzaS1iZXNzLXNlY3VyZS1ldnBuLTAyDQpBbmQ6IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kdW5iYXItYmVzcy1iZ3Atc2R3YW4tdXNhZ2UtMDEN Cg0KQ29tbWVudHMgYXBwcmVjaWF0ZWQuDQoNCkRhdmUNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NClNlY2Rpc3BhdGNoIG1haWxpbmcgbGlzdA0KU2Vj ZGlzcGF0Y2hAaWV0Zi5vcmc8bWFpbHRvOlNlY2Rpc3BhdGNoQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXNwYXRjaA0K --_000_698A5E0159244D6C9BD9A8E87712086Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7469D82DEB5CAC41A633085A5DEA1914@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkVrciw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzISZuYnNwOyBSZXNw b25zZXMgaW5saW5lIOKApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5FcmljIFJlc2NvcmxhICZsdDtla3JAcnRmbS5j b20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgSnVseSAyMiwgMjAxOSBhdCAxMDozMiBB TTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7RGF2aWQgQ2FycmVsIChjYXJyZWwpJnF1b3Q7ICZsdDtj YXJyZWxAY2lzY28uY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7c2VjZGlzcGF0Y2hAaWV0 Zi5vcmcmcXVvdDsgJmx0O3NlY2Rpc3BhdGNoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 IDwvYj5SZTogW1NlY2Rpc3BhdGNoXSBDb250cm9sbGVyLUlLRTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0Oi41aW4iPg0KRG9jdW1lbnQ6 IGRyYWZ0LWNhcnJlbC1pcHNlY21lLWNvbnRyb2xsZXItaWtlLTAxLnR4dDxicj4NCjxicj4NCkkg dG9vayBhIHF1aWNrIGxvb2sgYXQgdGhpcyBkb2N1bWVudCwgYW5kIEkgaGF2ZSBhIGZldyB0aG91 Z2h0cyw8YnI+DQppbiBubyBwYXJ0aWN1bGFyIG9yZGVyLjxicj4NCjxicj4NCiogSSB1bmRlcnN0 YW5kIHRoZSBkZXNpcmUgdG8gdGhpbmsgb2YgdGhpcyBhcyBhbiBleHRlbnNpb248YnI+DQpvZiBJ S0UsIGJ1dCBpdCdzIGFjdHVhbGx5IHByZXR0eSBkaWZmZXJlbnQsIGFuZCBJJ20gbm90IHN1cmU8 YnI+DQpob3cgbXVjaCBsZXZlcmFnZSB5b3UgYXJlIGdldHRpbmcgZnJvbSB0cnlpbmcgdG8gbWFr ZSB0aGVtPGJyPg0Kc2ltaWxhci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhpcyBpc27igJl0IGFuIGV4dGVuc2lvbiBv ZiBJS0UuJm5ic3A7IEl0IGlzIGFuIGFsdGVybmF0aXZlLiZuYnNwOyBJdCBwcm92aWRlcyB0aGUg ZnVuY3Rpb25hbGl0eSB0aGF0IGEgc3RhbmRhcmQgSUtFIHByb2Nlc3MgcHJvdmlkZXMuJm5ic3A7 IEJhc2ljYWxseSBpdCBjcmVhdGVzIHBhaXJ3aXNlIGtleXMgYW5kIGNyZWF0ZXMgSVBzZWMgU0Fz LiZuYnNwOyBGb3IgZXhhbXBsZSwgeW91IGNhbiByZW1vdmUNCiBhIExpbnV4IHVzZXJzcGFjZSBJ S0UgZGFlbW9uIGFuZCByZXBsYWNlIGl0IHdpdGggQ29udHJvbGxlci1JS0UgYW5kIHN0aWxsIHV0 aWxpemUgdGhlIHVubW9kaWZpZWQga2VybmVsIElQc2VjLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxicj4NCjxicj4N CiogSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gYmUgYSBsaXR0bGUgY2xlYXJlciBhYm91 dCB3aGF0PGJyPg0KcmVzb3VyY2UgeW91IGFyZSB0cnlpbmcgdG8gY29uc2VydmUgaGVyZS4gSSBn ZXQgdGhhdCB1c2luZyBzdHJhaWdodDxicj4NCklLRSB3b3VsZCByZXF1aXJlIE5eMiBhc3NvY2lh dGlvbnMsIGJ1dCB0aGlzIGRvZXMgYXMgd2VsbC4gSXQgZG9lc24ndDxicj4NCnJlcXVpcmUgTl4y IHByb3RvY29sIGV4Y2hhbmdlcywgYnV0IGl0IHJlcXVpcmVzIE5eMiBESCBvcGVyYXRpb25zIChp Zjxicj4NCmV2ZXJ5b25lIHdhbnRzIHRvIHRhbGsgdG8gZXZlcnlvbmUgZWxzZSkuIFNvLCB0aGUg bWFpbiB2YWx1ZSBzZWVtczxicj4NCnRvIGJlIHRoYXQgeW91IGNhbiBzZW5kIHRvIHNvbWVvbmUg aW4gMC1SVFQgd2l0aG91dCBleGNoYW5naW5nPGJyPg0KYW55IG1lc3NhZ2VzIGJlZm9yZWhhbmQu IElzIHRoYXQgY29ycmVjdD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+WW91IGFyZSByaWdodCB0aGF0IHRoZXJlIGNvbnRp bnVlcyB0byBiZSBOXjIgYXNzb2NpYXRpb25zIGFuZCB0aGlzIGRvZXMgbm90IHJlZHVjZSB0aGUg REggY2FsY3VsYXRpb25zLCBidXQgKGFzIHlvdSBub3RlKSB0aGlzIGRvZXMgcmVkdWNlIHRoZSBu dW1iZXIgb2YgcGVlci10by1wZWVyIG1lc3NhZ2VzIGFuZCBkb2VzIHJlZHVjZSB0aGUgUlRULiZu YnNwOyBEZXBlbmRpbmcNCiBvbiB0aGUgc2l6ZSBvZiB0aGUgZnVsbCBtZXNoIFNELVdBTiwgYW5k IHRoZSBiYW5kd2lkdGggY29zdHMsIHRoZSByZWR1Y3Rpb24gb2YgbWVzc2FnZXMgaXMgZGVmaW5p dGVseSBhIHBvc2l0aXZlLiZuYnNwOyBUaGVyZSBhcmUgb3RoZXIgYmVuZWZpdHMgc3VjaCBhcyBh bGxvd2luZyBmb3IgdGhlIHVzZSBvZiDigJxzZWN1cmXigJ0gcHJvdmlzaW9uZWQgbmV0d29ya3Mg Zm9yIGNvbnRyb2wsIHdoaWxlIHV0aWxpemluZyBsb3dlciBzZWN1cml0eSAocHVibGljKSBuZXR3 b3Jrcw0KIGZvciBJUHNlYyB0cmFmZmljLiZuYnNwOyBBbmQgaW4gZmFjdCB0aGVyZSBhcmUgYXBw bGljYXRpb25zIHdoZXJlIHRoZSBkYXRhIGNvbm5lY3Rpb24gYmV0d2VlbiBwZWVycyBpcyBOT1Qg Mi13YXksIG1lYW5pbmcgdHJhZGl0aW9uYWwgSUtFIHdpbGwgbm90IGVzdGFibGlzaCBiZXR3ZWVu IHRoZSBwZWVycywgYnV0IHRoZSBTRC1XQU4gZG9lcyBjb21lIHVwLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxicj4N Cjxicj4NCiogVGhlIFBGUyBzdG9yeSBoZXJlIHNlZW1zIHByZXR0eSBiYWQ6IEknbSBhc3N1bWlu ZyB0aGF0IHBlb3BsZTxicj4NCmFyZW4ndCBnb2luZyB0byBjaGFuZ2UgdGhlaXIgREgga2V5cyB2 ZXJ5IG9mdGVuIChhcyBpdCdzIGV4dHJlbWVseTxicj4NCmV4cGVuc2l2ZSBmb3IgZXZlcnlvbmUg ZWxzZSkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPlRydWUsIHRoZSBESCBsb2FkIGNhbiBiZSBleHBlbnNpdmUsIGJ1dCBu byBtb3JlIHNvIHRoYW4gYW4gZXF1aXZhbGVudCBtZXNoIG9mIHRyYWRpdGlvbmFsIElLRS4mbmJz cDsgV2Ugd291bGQgbm90IG5lZWQgdG8gcmUta2V5IGFueSBsZXNzIG9mdGVuLiZuYnNwOyBJIGJl bGlldmUgdGhpcyBtYWtlcyB0aGUgUEZTIHN0b3J5IGVxdWl2YWxlbnQuICZuYnNwO0luIGFkZGl0 aW9uLCBDb250cm9sbGVyLUlLRQ0KIGRvZXMgYWxsb3cgZm9yIHJlc2VuZGluZyB0aGUgc2FtZSBE SCBwdWJsaWMgdmFsdWUgd2l0aCBhIG5ldyBub25jZS4mbmJzcDsgVGhpcyBkb2VzbuKAmXQgaW1w cm92ZSBQRlMsIGJ1dCBkb2VzIGFsbG93IGZvciBhIG1vcmUgZnJlcXVlbnQgcmUta2V5aW5nIHdp dGhvdXQgaW5jdXJyaW5nIHRoZSBESCBjb3N0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxicj4NCjxicj4NCiogV2hh dCBoYXBwZW5zIGlmIG5vZGUgQSB0YWtlcyBub2RlIEIncyBESCBrZXkgYW5kIG5vbmNlIGFuZDxi cj4NCmFkdmVydGlzZXMgdGhlbSBhcyBpdHMgb3duPyBJZiBJIHVuZGVyc3RhbmQgdGhlIGRyYWZ0 IGNvcnJlY3RseSw8YnI+DQpDIHdpbGwgZW5kIHVwIHdpdGggdGhlIHNhbWUgU1BLSSBhbmQga2V5 cyBiZXR3ZWVuIEMtQiBhbmQgQy1BLjxicj4NCklzIHRoYXQgcmlnaHQ/IElmIHNvLCB0aGF0IHNv dW5kcyBhdCBtaW5pbXVtIGxpa2UgYW4gaWRlbnRpdHk8YnI+DQptaXNiaW5kaW5nIGF0dGFjaywg YnV0IGlmIHlvdSBhcmUgdXNpbmcgaW1wbGljaXQgSVZzPGJyPg0KKDxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwc2VjbWUtaW1wbGljaXQtaXYtMDciPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwc2VjbWUtaW1wbGljaXQtaXYt MDc8L2E+KSw8YnI+DQp0aGVuIHdvdWxkbid0IHlvdSBnZXQgbm9uY2UgcmV1c2UsIHdoaWNoIHdv dWxkIGJlIHF1aXRlIGJhZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhpcyBpcyBhIHZlcnkgZ29vZCBvYnNlcnZhdGlv bi4mbmJzcDsgVGhlIHN0cmFpZ2h0Zm9yd2FyZCBhbnN3ZXIgaXMgdG8gbWl4IHRoZSBjb250cm9s bGVyIHZhbGlkYXRlZCBpZGVudGl0eSBpbnRvIHRoZSBrZXltYXQgdG8gZW5zdXJlIHRoYXQgc29t ZW9uZSBlbHNlIHVzaW5nIG15IERIL25vbmNlIHdpbGwgbm90IGdlbmVyYXRlIHRoZSBpZGVudGlj YWwga2V5cyB3aXRoDQogYSAzPHN1cD5yZDwvc3VwPiBwZWVyLiZuYnNwOyBUaGFua3MhITxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDou NWluIj4NCjxicj4NCjxicj4NCiogWW91IGFsc28gc2VlbSB0byBoYXZlIGEgS0NJIHByb2JsZW0s IHdoZXJlIGlmIHlvdXIga2V5cyBpczxicj4NCmNvbXByb21pc2VkLCBhbiBhdHRhY2tlciBjYW4g aW1wZXJzb25hdGUgYW55b25lIHRvIHlvdS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSBkb27igJl0IHNlZSB0aGlzPyZu YnNwOyBDYW4geW91IGV4cGxhaW4gZnVydGhlcj8mbmJzcDsgSWYgbXkgREggcHJpdmF0ZSBpcyBj b21wcm9taXNlZCwgdGhlbiBhbiBhdHRhY2tlciBjYW4gaW1wZXJzb25hdGUgbWUgdG8gYW55b25l IGVsc2UgKHVudGlsIEkgcmUta2V5KS4mbmJzcDsgUHJlc3VtYWJseSBpZiB5b3UgZ2V0IG15IHBy aXZhdGUgREgsIEkgaGF2ZSBiZWVuIGNvbXByb21pc2VkDQogZnVsbHkuJm5ic3A7IEJ1dCB0aGlz IGlzIHRoZSBzYW1lIHNpdHVhdGlvbiB3aXRoIGFueSBrZXkgbWFuYWdlbWVudCBwcm90b2NvbC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxl ZnQ6LjVpbiI+DQo8YnI+DQo8YnI+DQo8YnI+DQpJU1RNIHRoYXQgeW91IHdvdWxkIGJlIGluIGEg YmV0dGVyIHBvc2l0aW9uIGlmIHlvdSBhZG9wdGVkIGEgMC1SVFQgREg8YnI+DQpmbG93IGluIHRo ZSBzdHlsZSBvZiBPUFRMUy4gSS5lLiwgQSBhbmQgQiBlYWNoIGhhdmUga2V5cyBnXmEsIGdeYiBh bmQ8YnI+DQp5b3UgbWl4IHRoZW0gaW4gd2l0aCBlcGhlbWVyYWwgREgga2V5cyBnXnggYW5kIGde eS4gVGhpcyBraW5kIG9mPGJyPg0KZXhjaGFuZ2UgaXMgcmVhc29uYWJseSB3ZWxsIHN0dWRpZWQs IGFuZCBoYXMgZ29vZCBQRlMgYW5kIGtleTxicj4NCmNvbmZpcm1hdGlvbiBwcm9wZXJ0aWVzLiBZ b3UgY2FuIHBpZ2d5YmFjayB0aGUga2V5IGVzdGFibGlzaG1lbnQ8YnI+DQptZXNzYWdlcyBhbG9u ZyB3aXRoIHRoZSBkYXRhIHlvdSB3YW50IHRvIHNlbmQsIHNvIHlvdSdsbCBzdGlsbCBnZXQ8YnI+ DQpkYXRhIG9uIHRoZSBmaXJzdCBtZXNzYWdlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5EZWZpbml0ZWx5IHdvcnRoIGxv b2tpbmcgYXQuJm5ic3A7IEkgY2Fu4oCZdCBnaXZlIHlvdSBhIHF1aWNrIHJlc3BvbnNlIG9uIHRo aXMsIGJ1dCBJIHdpbGwgY3J1bmNoIG9uIHRoaXMuICZuYnNwO09mIGNvdXJzZSwgdGhpcyB3b3Vs ZCBpbnZvbHZlIG1vZGlmeWluZyBFU1AuJm5ic3A7IEkgd291bGRu4oCZdCB3YW50IHRvIG1ha2Ug dGhhdCBhIHJlcXVpcmVtZW50IHRvIHRoaXMgbW92aW5nIGZvcndhcmQsDQogYnV0IGl0IGNvdWxk IGJlIHNlcGFyYXRlbHkgY29uc2lkZXJlZCBhcyBhbiBFU1AgZXh0ZW5zaW9uIHRoYXQgYW55IEtN UCBjb3VsZCBhdmFpbCB0aGVtc2VsdmVzIG9mLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPi1Fa3I8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RGF2ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0 Oi41aW4iPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24g RnJpLCBKdWwgMTksIDIwMTkgYXQgNzoyMCBQTSBEYXZpZCBDYXJyZWwgKGNhcnJlbCkgJmx0Ozxh IGhyZWY9Im1haWx0bzpjYXJyZWxAY2lzY28uY29tIj5jYXJyZWxAY2lzY28uY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCkZvbGtzLDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+ DQpJIHdvdWxkIGxpa2UgdG8gcHJlc2VudCBDb250cm9sbGVyLUlLRSBpbiB0aGUgTW9udHJlYWwg U2VjdXJpdHkgRGlzcGF0Y2ggbWVldGluZy4mbmJzcDsgVGhlcmUgaXMgZ3Jvd2luZyBpbnRlcmVz dCBmcm9tIHJvdXRpbmcgZm9sa3MsIGFuZCBJIHN0cm9uZ2x5IGZlZWwgd2Ugc2hvdWxkIGV2YWx1 YXRlIGFuZCBwcm9ncmVzcyB0aGlzIGluIHRoZSBzZWN1cml0eSBhcmVhLiZuYnNwOyBJ4oCZbGwg aGF2ZSBzb21lIHNsaWRlcyB0byBzaGFyZSBzaG9ydGx5LiZuYnNwOyBGb3Igbm93LA0KIHBsZWFz ZSBkbyByZWFkIHRoZSBkcmFmdC4mbmJzcDsgQWxzbyB0aGVyZSBhcmUgc29tZSBkcmFmdHMgcmVm ZXJlbmNpbmcgdGhpczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KQ29udHJvbGxlci1JS0U6IDxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYXJyZWwtaXBzZWNtZS1jb250cm9sbGVyLWlrZS0w MSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNh cnJlbC1pcHNlY21lLWNvbnRyb2xsZXItaWtlLTAxPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpBbHNvIHNvbWUgZG9j cyByZWZlcmVuY2luZyB0aGlzIGZvcm0gb2Yga2V5IG1hbmFnZW1lbnQ6PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpCRVNTLCBTZWN1cmUg RVZQTjogPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNhamFzc2kt YmVzcy1zZWN1cmUtZXZwbi0wMiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXNhamFzc2ktYmVzcy1zZWN1cmUtZXZwbi0wMjwvYT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCkFuZDogPGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWR1bmJhci1iZXNzLWJncC1z ZHdhbi11c2FnZS0wMSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWR1bmJhci1iZXNzLWJncC1zZHdhbi11c2FnZS0wMTwvYT48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KQ29t bWVudHMgYXBwcmVjaWF0ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCkRhdmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N ClNlY2Rpc3BhdGNoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpTZWNkaXNwYXRj aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlNlY2Rpc3BhdGNoQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2VjZGlzcGF0 Y2giIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NlY2Rpc3BhdGNoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_698A5E0159244D6C9BD9A8E87712086Bciscocom_-- From nobody Mon Jul 22 09:13:30 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECE1120274 for ; Mon, 22 Jul 2019 09:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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_HELO_NONE=0.001, SPF_NONE=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=rtfm-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 h3KAPRFTI5_D for ; Mon, 22 Jul 2019 09:13:25 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 EAD2B1201F8 for ; Mon, 22 Jul 2019 09:13:24 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id v18so38137674ljh.6 for ; Mon, 22 Jul 2019 09:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lU8iFLTx8w3Z4UxWZ1sYxC2ZJjrentvbrZPY217MUk0=; b=CehOREj1VkE4o5pJcf+3B0PD/yfwH9LXJ6UgWoPhD2N/h0qlAObDP0bw/G49lIZPx/ 00dTGi4S1LZi5Vn2+HeMOJaClgz5ZL6j0cEJxgFF1rPkzGyrzue3DJwQjqXbCbJX5or+ gdDjoKCFocgE+5WRG0GnM0M0IdaAS0cB0G4lhpOin/h2RHdbSK0XjLtY2I6+FIehL0mS ryX800zLgYAyHR0Zh3eYFcRK+ySN/3tqTjniZ6/60MKnk9Ju4dtN5Q8nYvq78EKxqZSA Ul5uSyvwpp6bm9p7Sn5PuvoUMYVgFOZ3RTa7b/YuI7yCammAGW4Gxt8bNIPzr3PBtgfu eXug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lU8iFLTx8w3Z4UxWZ1sYxC2ZJjrentvbrZPY217MUk0=; b=Kj9lARUKHKfdpu/XnWccHY/5PMj2C7tvFN8iEihdeMs18vy/cH9CMjGJ6pzPKNrkyv l3IvSelYYq5QNRjagSABR8zdlGKyjvtVwQt5Q+dBgIu6gXgyfr1XMrWsGaDcXrZIKpoh DFwXKOVX5glR9qCIAfgVPtJGuDqbF53C8rjKB/iyn4w7f37SabJARSs7mqD6hRnmUx4+ UZUVrABnwSQOqoz9cxD/L6NWJehXYlUlD7S5gH2fumYlyX0PJfSDQzoZBdWpNhov3M0P RcNp6UeWXfHLzyYEyG4exvBb2JVi2AHmWfSIhsF69ldZ8ZVlksOkTorOWP9SZm0qoVCM 5Ftw== X-Gm-Message-State: APjAAAXMBL66o3edmYxIh0oM+vRvI158/jwX43v+wF/IS4MYGVpyI04r aRubM6ACH1ySVnd88UXpGp6AQ/PloqwCFtNGIKI= X-Google-Smtp-Source: APXvYqxl3K2nvaOFzOxSp3tTSeXrxAgWy/GuXX9oY2DXVGGKTLkdGzwA2WuNQhCEx9bS2SWSHPj6v1pVF9vWjSHO30A= X-Received: by 2002:a2e:b0e6:: with SMTP id h6mr35177205ljl.18.1563812003038; Mon, 22 Jul 2019 09:13:23 -0700 (PDT) MIME-Version: 1.0 References: <698A5E01-5924-4D6C-9BD9-A8E87712086B@cisco.com> In-Reply-To: <698A5E01-5924-4D6C-9BD9-A8E87712086B@cisco.com> From: Eric Rescorla Date: Mon, 22 Jul 2019 09:12:46 -0700 Message-ID: To: "David Carrel (carrel)" Cc: "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f00cae058e475a60" Archived-At: Subject: Re: [Secdispatch] Controller-IKE X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 16:13:29 -0000 --000000000000f00cae058e475a60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 22, 2019 at 8:42 AM David Carrel (carrel) wrote: > Ekr, > > > > Thanks! Responses inline =E2=80=A6 > > > > *From: *Eric Rescorla > *Date: *Monday, July 22, 2019 at 10:32 AM > *To: *"David Carrel (carrel)" > *Cc: *"secdispatch@ietf.org" > *Subject: *Re: [Secdispatch] Controller-IKE > > > > Document: draft-carrel-ipsecme-controller-ike-01.txt > > I took a quick look at this document, and I have a few thoughts, > in no particular order. > > * I understand the desire to think of this as an extension > of IKE, but it's actually pretty different, and I'm not sure > how much leverage you are getting from trying to make them > similar. > > This isn=E2=80=99t an extension of IKE. It is an alternative. It provid= es the > functionality that a standard IKE process provides. Basically it creates > pairwise keys and creates IPsec SAs. For example, you can remove a Linux > userspace IKE daemon and replace it with Controller-IKE and still utilize > the unmodified kernel IPsec. > Yes. My point is that it's not clear to me why you are calling it "Controller IKE" or using the IKE crypto functions, which aren't really what we usually pick for new protocols. > > > * I think it would be useful to be a little clearer about what > resource you are trying to conserve here. I get that using straight > IKE would require N^2 associations, but this does as well. It doesn't > require N^2 protocol exchanges, but it requires N^2 DH operations (if > everyone wants to talk to everyone else). So, the main value seems > to be that you can send to someone in 0-RTT without exchanging > any messages beforehand. Is that correct? > > You are right that there continues to be N^2 associations and this does > not reduce the DH calculations, but (as you note) this does reduce the > number of peer-to-peer messages and does reduce the RTT. Depending on th= e > size of the full mesh SD-WAN, and the bandwidth costs, the reduction of > messages is definitely a positive. There are other benefits such as > allowing for the use of =E2=80=9Csecure=E2=80=9D provisioned networks for= control, while > utilizing lower security (public) networks for IPsec traffic. And in fac= t > there are applications where the data connection between peers is NOT > 2-way, meaning traditional IKE will not establish between the peers, but > the SD-WAN does come up. > Thanks. This is helpful. > * The PFS story here seems pretty bad: I'm assuming that people > aren't going to change their DH keys very often (as it's extremely > expensive for everyone else). > > True, the DH load can be expensive, but no more so than an equivalent mes= h > of traditional IKE. We would not need to re-key any less often. I belie= ve > this makes the PFS story equivalent. > This doesn't seem correct to me. Consider the case where you do pairwise IKE and then delete the SA and the DH ephemerals. At this point, compromise doesn't leak the traffic keys at all. By contrast, in Controller-IKE because I need to store my DH share indefinitely in case a new peer comes online, then that represents a long-term source of compromise. > * What happens if node A takes node B's DH key and nonce and > advertises them as its own? If I understand the draft correctly, > C will end up with the same SPKI and keys between C-B and C-A. > Is that right? If so, that sounds at minimum like an identity > misbinding attack, but if you are using implicit IVs > (https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-07), > then wouldn't you get nonce reuse, which would be quite bad. > > This is a very good observation. The straightforward answer is to mix th= e > controller validated identity into the keymat to ensure that someone else > using my DH/nonce will not generate the identical keys with a 3rd peer. > Thanks!! > That's probably enough, but I'd want to see some kind of analysis that shows that this is true. > > > * You also seem to have a KCI problem, where if your keys is > compromised, an attacker can impersonate anyone to you. > > I don=E2=80=99t see this? Can you explain further? If my DH private is > compromised, then an attacker can impersonate me to anyone else (until I > re-key). Presumably if you get my private DH, I have been compromised > fully. But this is the same situation with any key management protocol. > Not exactly. Consider a protocol like TLS 1.3 where you have both short and long term keys. Compromise of your long-term key (e.g., it's leaked but your machine isn't still compromised) allows someone to impersonate you to other people but not to impersonate other people to you, because they can't forge a signature you will accept. However, that's not the case with Controller-IKE. I don't believe that it's possible to achieve KCI resistance with a static-static DH protocol like Controller-IKE but you can with a combined ephemeral/static protocol like OPTLS. > > ISTM that you would be in a better position if you adopted a 0-RTT DH > flow in the style of OPTLS. I.e., A and B each have keys g^a, g^b and > you mix them in with ephemeral DH keys g^x and g^y. This kind of > exchange is reasonably well studied, and has good PFS and key > confirmation properties. You can piggyback the key establishment > messages along with the data you want to send, so you'll still get > data on the first message. > > Definitely worth looking at. I can=E2=80=99t give you a quick response o= n this, > but I will crunch on this. Of course, this would involve modifying ESP. = I > wouldn=E2=80=99t want to make that a requirement to this moving forward, = but it > could be separately considered as an ESP extension that any KMP could ava= il > themselves of. > Well, you don't *need* to piggyback: you can send the key establishment messages in separate packets. Piggybacking just gives you fate sharing so there's no way for the ESP messages to arrive in the opposite order. QUIC is a worked example of this style of protocol. -Ekr -Ekr > > > > Dave > > > > > > > > > > > > > > > > > On Fri, Jul 19, 2019 at 7:20 PM David Carrel (carrel) > wrote: > > Folks, > > > > I would like to present Controller-IKE in the Montreal Security Dispatch > meeting. There is growing interest from routing folks, and I strongly fe= el > we should evaluate and progress this in the security area. I=E2=80=99ll = have some > slides to share shortly. For now, please do read the draft. Also there > are some drafts referencing this: > > > > Controller-IKE: > https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-01 > > > > Also some docs referencing this form of key management: > > BESS, Secure EVPN: > https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-02 > > And: https://tools.ietf.org/html/draft-dunbar-bess-bgp-sdwan-usage-01 > > > > Comments appreciated. > > > > Dave > > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > > --000000000000f00cae058e475a60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 22, 2019 at 8:42 AM David= Carrel (carrel) <carrel@cisco.com> wrote:

Ekr,

=C2=A0

Thanks!=C2=A0 Responses inline =E2=80=A6

=C2=A0

From: Eric Rescorla <ekr@rtfm.com>
Date: Monday, July 22, 2019 at 10:32 AM
To: "David Carrel (carrel)" <carrel@cisco.com>
Cc: "= secdispatch@ietf.org" <secdispatch@ietf.org>
Subject: Re: [Secdispatch] Controller-IKE

=C2=A0

Document: draft-carrel-ipsecme-controller-ike-01.txt

I took a quick look at this document, and I have a few thoughts,
in no particular order.

* I understand the desire to think of this as an extension
of IKE, but it's actually pretty different, and I'm not sure
how much leverage you are getting from trying to make them
similar.

This isn=E2=80=99t an e= xtension of IKE.=C2=A0 It is an alternative.=C2=A0 It provides the function= ality that a standard IKE process provides.=C2=A0 Basically it creates pair= wise keys and creates IPsec SAs.=C2=A0 For example, you can remove a Linux userspace IKE daemon and replace it with Controller-IKE and still = utilize the unmodified kernel IPsec.


Yes. My point is that it's not clear to me why yo= u are calling it "Controller IKE" or using the IKE crypto functio= ns, which aren't really what we usually pick for new protocols.



* I think it would be useful to be a little clearer about what
resource you are trying to conserve here. I get that using straight
IKE would require N^2 associations, but this does as well. It doesn't require N^2 protocol exchanges, but it requires N^2 DH operations (if
everyone wants to talk to everyone else). So, the main value seems
to be that you can send to someone in 0-RTT without exchanging
any messages beforehand. Is that correct?

You are right that ther= e continues to be N^2 associations and this does not reduce the DH calculat= ions, but (as you note) this does reduce the number of peer-to-peer message= s and does reduce the RTT.=C2=A0 Depending on the size of the full mesh SD-WAN, and the bandwidth costs, the reductio= n of messages is definitely a positive.=C2=A0 There are other benefits such= as allowing for the use of =E2=80=9Csecure=E2=80=9D provisioned networks f= or control, while utilizing lower security (public) networks for IPsec traffic.=C2=A0 And in fact there are applications where the data= connection between peers is NOT 2-way, meaning traditional IKE will not es= tablish between the peers, but the SD-WAN does come up.


Thanks. This is helpful.


* The PFS story here seems pretty bad: I'm assuming that people
aren't going to change their DH keys very often (as it's extremely<= br> expensive for everyone else).

True, the DH load can b= e expensive, but no more so than an equivalent mesh of traditional IKE.=C2= =A0 We would not need to re-key any less often.=C2=A0 I believe this makes = the PFS story equivalent.

Thi= s doesn't seem correct to me. Consider the case where you do pairwise I= KE and then delete the SA and the DH ephemerals. At this point, compromise = doesn't leak the traffic keys at all. By contrast, in Controller-IKE be= cause I need to store my DH share indefinitely in case a new peer comes onl= ine, then that represents a long-term source of compromise.
<= br>

<= p class=3D"MsoNormal" style=3D"margin-right:0in;margin-bottom:12pt;margin-l= eft:0.5in">
* What happens if node A takes node B's DH key and nonce and
advertises them as its own? If I understand the draft correctly,
C will end up with the same SPKI and keys between C-B and C-A.
Is that right? If so, that sounds at minimum like an identity
misbinding attack, but if you are using implicit IVs
(https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-i= v-07),
then wouldn't you get nonce reuse, which would be quite bad.<= /u>

This is a very good obs= ervation.=C2=A0 The straightforward answer is to mix the controller validat= ed identity into the keymat to ensure that someone else using my DH/nonce w= ill not generate the identical keys with a 3rd peer.=C2=A0 Thanks!!

That's probably enough, but I'd want to see some kind of a= nalysis that shows that this is true.



* You also seem to have a KCI problem, where if your keys is
compromised, an attacker can impersonate anyone to you.

I don=E2=80=99t see thi= s?=C2=A0 Can you explain further?=C2=A0 If my DH private is compromised, th= en an attacker can impersonate me to anyone else (until I re-key).=C2=A0 Pr= esumably if you get my private DH, I have been compromised fully.=C2=A0 But this is the same situation with any key management protoc= ol.

Not exactly. Consider a pr= otocol like TLS 1.3 where you have both short and long term keys. Compromis= e of your long-term key (e.g., it's leaked but your machine isn't s= till compromised) allows someone to impersonate you to other people but not= to impersonate other people to you, because they can't forge a signatu= re you will accept. However, that's not the case with Controller-IKE. I= don't believe that it's possible to achieve KCI resistance with a = static-static DH protocol like Controller-IKE but you can with a combined e= phemeral/static protocol like OPTLS.



ISTM that you would be in a better position if you adopted a 0-RTT DH
flow in the style of OPTLS. I.e., A and B each have keys g^a, g^b and
you mix them in with ephemeral DH keys g^x and g^y. This kind of
exchange is reasonably well studied, and has good PFS and key
confirmation properties. You can piggyback the key establishment
messages along with the data you want to send, so you'll still get
data on the first message.

Definitely worth lookin= g at.=C2=A0 I can=E2=80=99t give you a quick response on this, but I will c= runch on this.=C2=A0 Of course, this would involve modifying ESP.=C2=A0 I w= ouldn=E2=80=99t want to make that a requirement to this moving forward, but it could be separately considered as an ESP extension that any KMP cou= ld avail themselves of.

Well, = you don't *need* to piggyback: you can send the key establishment messa= ges in separate packets. Piggybacking just gives you fate sharing so there&= #39;s no way for the ESP messages to arrive in the opposite order.

QUIC is a worked example of this style of protocol.

-Ekr

-Ekr

=C2=A0

Dave

=C2=A0

=C2=A0










=C2=A0

On Fri, Jul 19, 2019 at = 7:20 PM David Carrel (carrel) <carrel@cisco.com> wrote:

Folks,

=C2=A0

I would like to present Controller-IKE in the Montreal Security Dispatch me= eting.=C2=A0 There is growing interest from routing folks, and I strongly f= eel we should evaluate and progress this in the security area.=C2=A0 I=E2= =80=99ll have some slides to share shortly.=C2=A0 For now, please do read the draft.=C2=A0 Also there are some drafts referencing thi= s:

=C2=A0

Controller-IKE: https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-01

=C2=A0

Also some docs referencing this form of key management:

BESS, Secure EVPN: https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-02=

And: https://tools.ietf.org/html/draft-dunbar-bess-bgp-sdwan-usage-01=

=C2=A0

Comments appreciated.

=C2=A0

Dave

=C2=A0

________________________= _______________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch

--000000000000f00cae058e475a60-- From nobody Mon Jul 22 10:10:05 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE3912004D for ; Mon, 22 Jul 2019 10:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 header.b=eE0aYU2U; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=mO+EXlDD 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 Kbtx1cmQg6sJ for ; Mon, 22 Jul 2019 10:09:57 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B3B120288 for ; Mon, 22 Jul 2019 10:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6729; q=dns/txt; s=iport; t=1563815397; x=1565024997; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Zz1TqkY5V38KZNQAOeuW3+GIRLGudzo28Bef4A/G2/Y=; b=eE0aYU2UHD+fezf/fSnqRarScYC6VS1vlj9OUFM2k3eAARaa5fMTRtXO DGhcNZrCVMFiM9U2MfsG5eisae7++cULcZvp4eGAm4t+SF2QwcBeJZzZx 6DdkYJsxQaAeg5gCSpejeSllR1J0P7mUyDW2KMxFqGihLVWf2StfJ3xMv k=; IronPort-PHdr: =?us-ascii?q?9a23=3Aj5rp8hyGmr4dV8TXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YR2N/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuOAFfhIfrCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChAAD87DVd/5NdJa1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBVQUBAQsBgRQvUANtVSAECyqEHYNHA419lVaEVYEugSQDVAkBAQEMAQE?= =?us-ascii?q?tAgEBhEACF4JMIzYHDgEDAQEEAQECAQZthR4MhUsCAQMSER0BATcBDwIBCA4?= =?us-ascii?q?0AgICMCUCBA4ngwABgR1NAx0BAqAxAoE4iGBxgTKCeQEBBYJHgkIYghMJgTQ?= =?us-ascii?q?Bi14XgX+BOB+CTD6HTzKCJo54hH6WcQkCghmUDBuYCqUFAgQCBAUCDgEBBYF?= =?us-ascii?q?XATCBWHAVZQGCQYFLd4NxilNygSmOcQEB?= X-IronPort-AV: E=Sophos;i="5.64,295,1559520000"; d="scan'208,217";a="381853026" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jul 2019 17:09:56 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x6MH9u0h014022 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Jul 2019 17:09:56 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 22 Jul 2019 12:09:55 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 22 Jul 2019 12:09:55 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 22 Jul 2019 12:09:55 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BIvvajnRXKfZ2lQuqlVGD1LBlogYQFZXUH6wg5JbkqDCOG+cOpLja6NFCe4TiTurH1WkDlPrW6L6EWeJsBWZENYtyrfyjXRM8PRJuQ45q+7loI1xiove7kGjKo3Hzi0946gIdmJiptsHpPXIjliqJv18htdC2Y1d6Zd5e7jpLEryxPKlYqQjXC7e4fLup3EBAfkQWC4bTJq6x/jzFdYuDg9WA9uBltgIZPe2THaJXoqocuY7BrnO4NCE75t8rmWgEfVb3GNBt8O4jRmdu3PH36wgRMIzu28nVxMzwpAuWM/jcuPTTnCNstnNOGWTyZxC+tG5i13/fe9J2QRGP7mWyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zz1TqkY5V38KZNQAOeuW3+GIRLGudzo28Bef4A/G2/Y=; b=gGG4IMgwIG0ktWHK0vYl1wpWF53HEUd2OR5YrWxAvsm8t6lrTL2n+uK3QDfH6Ufw3QaRG41CrE0ozYpISspkC3P+jdJBn9fEqqoWQ8BVNZzpb+WI8CynTjrN2jArbyMc1YrxoQs3n2oypY4taCH5ZE5vyAEaysvUMY9AtXthtoUGMjwj/1/33P9K0pRPdDrWd1p4AbBpbVxOzSWgBiQuHT2DpQCOIYyPBdaMrjxuT0aQp9/29IV0mS/fnGtlg2OdPPlg9+8itFHQCwUw3az23rP0Gso83rIr5fDHMo4PiYzPvUn4Fp6YPyquOUAhk2+oIaBDzHYxRTs9zZBhcf7F9w== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zz1TqkY5V38KZNQAOeuW3+GIRLGudzo28Bef4A/G2/Y=; b=mO+EXlDDipJW9OBqBUwtDs672dNiutJlfg1GB1ucBD7wWKbjL/HTCbyoopOx8q0ttFXEgUJqTFCcZ5nUyPzxxX5Gg0lkifp8z1kpX+gO0q5G4LT3h0VzbpVTQjpTpU1sHYdQgTBTEyARuB1UDlQyeWgF7nHnMYrnB6zXQU+fZmY= Received: from BYAPR11MB3046.namprd11.prod.outlook.com (20.177.225.213) by BYAPR11MB2694.namprd11.prod.outlook.com (52.135.227.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Mon, 22 Jul 2019 17:09:53 +0000 Received: from BYAPR11MB3046.namprd11.prod.outlook.com ([fe80::c895:4d83:c5b8:b3d6]) by BYAPR11MB3046.namprd11.prod.outlook.com ([fe80::c895:4d83:c5b8:b3d6%6]) with mapi id 15.20.2073.012; Mon, 22 Jul 2019 17:09:53 +0000 From: "David Carrel (carrel)" To: Eric Rescorla CC: "secdispatch@ietf.org" Thread-Topic: [Secdispatch] Controller-IKE Thread-Index: AQHVPqG2qaTEIVD/zEy+2+Xv9S/jD6bWtyQA//+edACAAH29AP//mpwA Date: Mon, 22 Jul 2019 17:09:53 +0000 Message-ID: <23A860FA-61F4-4CD4-93DE-2FCE06984B9D@cisco.com> References: <698A5E01-5924-4D6C-9BD9-A8E87712086B@cisco.com> 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=carrel@cisco.com; x-originating-ip: [2001:420:c0c8:1008::132] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 64c066fe-687c-4c5b-1456-08d70ec76a16 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2694; x-ms-traffictypediagnostic: BYAPR11MB2694: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 01068D0A20 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(366004)(136003)(376002)(396003)(199004)(189003)(6116002)(256004)(71190400001)(7736002)(14444005)(71200400001)(14454004)(36756003)(2906002)(4326008)(6916009)(68736007)(6246003)(33656002)(99286004)(486006)(229853002)(478600001)(8676002)(25786009)(54896002)(2616005)(8936002)(102836004)(11346002)(86362001)(46003)(81166006)(76176011)(81156014)(6436002)(476003)(6306002)(64756008)(76116006)(6512007)(6486002)(5660300002)(446003)(66446008)(66556008)(53936002)(66946007)(316002)(186003)(6506007)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2694; H:BYAPR11MB3046.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: U7+MIEDEfc96ISXVHvlSd6VN8UQXB7GLOtrWl7KgPzbvzzYIWw6ZDkfbPcQM6uc9Iykg1MQlklHZveO0DvuoDPXcxVsnW7wL2EYSdXnz+jNH/r7DzdktyCsbFDgQBPzZMHn9BOm9nIania55zuYE7OWlwt4rsbbixJ+PuggrLhJWgMlw1lYYIHvHKFe5+sEHvGV0TJ9zzeavaHzcFmstg7a1FyyEBRGID0iCIDEqokKtIkOVLZqYucb3Ca++jXIu8Uuoi1nSQCvxPK6Pgu5qqcvcA8HUufNFvCLWD9Qkdfv/ieQ+c1LKy9/efNGPkIzDGJxgKsZL7ZoT8zswXgdvI69zBXy32tNaxiYStBvEmIlExQox/LWCRGLc8ymbDvrqnm5fyreaurBkPAG2rFtDdPsvUwhfiz3DZyTeIawo7Qw= Content-Type: multipart/alternative; boundary="_000_23A860FA61F44CD493DE2FCE06984B9Dciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 64c066fe-687c-4c5b-1456-08d70ec76a16 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2019 17:09:53.5578 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: carrel@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2694 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [Secdispatch] Controller-IKE X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 17:10:04 -0000 --_000_23A860FA61F44CD493DE2FCE06984B9Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCiogVGhlIFBGUyBzdG9yeSBoZXJlIHNlZW1zIHByZXR0eSBiYWQ6IEknbSBhc3N1bWluZyB0 aGF0IHBlb3BsZQ0KYXJlbid0IGdvaW5nIHRvIGNoYW5nZSB0aGVpciBESCBrZXlzIHZlcnkgb2Z0 ZW4gKGFzIGl0J3MgZXh0cmVtZWx5DQpleHBlbnNpdmUgZm9yIGV2ZXJ5b25lIGVsc2UpLg0KVHJ1 ZSwgdGhlIERIIGxvYWQgY2FuIGJlIGV4cGVuc2l2ZSwgYnV0IG5vIG1vcmUgc28gdGhhbiBhbiBl cXVpdmFsZW50IG1lc2ggb2YgdHJhZGl0aW9uYWwgSUtFLiAgV2Ugd291bGQgbm90IG5lZWQgdG8g cmUta2V5IGFueSBsZXNzIG9mdGVuLiAgSSBiZWxpZXZlIHRoaXMgbWFrZXMgdGhlIFBGUyBzdG9y eSBlcXVpdmFsZW50Lg0KVGhpcyBkb2Vzbid0IHNlZW0gY29ycmVjdCB0byBtZS4gQ29uc2lkZXIg dGhlIGNhc2Ugd2hlcmUgeW91IGRvIHBhaXJ3aXNlIElLRSBhbmQgdGhlbiBkZWxldGUgdGhlIFNB IGFuZCB0aGUgREggZXBoZW1lcmFscy4gQXQgdGhpcyBwb2ludCwgY29tcHJvbWlzZSBkb2Vzbid0 IGxlYWsgdGhlIHRyYWZmaWMga2V5cyBhdCBhbGwuIEJ5IGNvbnRyYXN0LCBpbiBDb250cm9sbGVy LUlLRSBiZWNhdXNlIEkgbmVlZCB0byBzdG9yZSBteSBESCBzaGFyZSBpbmRlZmluaXRlbHkgaW4g Y2FzZSBhIG5ldyBwZWVyIGNvbWVzIG9ubGluZSwgdGhlbiB0aGF0IHJlcHJlc2VudHMgYSBsb25n LXRlcm0gc291cmNlIG9mIGNvbXByb21pc2UuDQoNCk9LLCBJIHRoaW5rIHRoaXMgaXMgd2hlcmUg eW91IG1pc3VuZGVyc3Rvb2Qgc29tZXRoaW5nIG9yIHdlIGRpZG7igJl0IGV4cGxhaW4gd2VsbCBl bm91Z2guICBUaGVyZSBhcmUgbm8gbG9uZy10ZXJtIERIIGtleXMgaW4gQ29udHJvbGxlci1JS0Uu ICBBbGwgYXJlIGVwaGVtZXJhbC4gIEl0IGlzIHRydWUgdGhhdCBkdWUgdG8gc3luY2hyb25pemF0 aW9uLCB5b3Ugd2lsbCBsaWtlbHkga2VlcCB0aGVtIGEgbGl0dGxlIGxvbmdlciwgYnV0IG5ldmVy IG1vcmUgdGhhbiAyIGtleSBsaWZldGltZXMuICBJZiB5b3UgcmUta2V5IGV2ZXJ5IDIgaG91cnMs IHRoZW4gdGhlIHdvcnN0IGNhc2UgaXMgdGhhdCB5b3VyIERIIHZhbHVlcyBhcmUga2VwdCBmb3Ig NCBob3Vycy4NCg0KRGF2ZQ0KDQo= --_000_23A860FA61F44CD493DE2FCE06984B9Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <078E506F2EE2B44AB86C4FE3A283EF36@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjEuMGluIj4NCiogVGhlIFBGUyBzdG9yeSBoZXJlIHNl ZW1zIHByZXR0eSBiYWQ6IEknbSBhc3N1bWluZyB0aGF0IHBlb3BsZTxicj4NCmFyZW4ndCBnb2lu ZyB0byBjaGFuZ2UgdGhlaXIgREgga2V5cyB2ZXJ5IG9mdGVuIChhcyBpdCdzIGV4dHJlbWVseTxi cj4NCmV4cGVuc2l2ZSBmb3IgZXZlcnlvbmUgZWxzZSkuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+DQpUcnVlLCB0aGUgREggbG9hZCBjYW4gYmUgZXhw ZW5zaXZlLCBidXQgbm8gbW9yZSBzbyB0aGFuIGFuIGVxdWl2YWxlbnQgbWVzaCBvZiB0cmFkaXRp b25hbCBJS0UuJm5ic3A7IFdlIHdvdWxkIG5vdCBuZWVkIHRvIHJlLWtleSBhbnkgbGVzcyBvZnRl bi4mbmJzcDsgSSBiZWxpZXZlIHRoaXMgbWFrZXMgdGhlIFBGUyBzdG9yeSBlcXVpdmFsZW50Lg0K PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+VGhpcyBkb2Vzbid0IHNlZW0gY29ycmVjdCB0byBtZS4gQ29uc2lkZXIgdGhlIGNhc2Ugd2hl cmUgeW91IGRvIHBhaXJ3aXNlIElLRSBhbmQgdGhlbiBkZWxldGUgdGhlIFNBIGFuZCB0aGUgREgg ZXBoZW1lcmFscy4gQXQgdGhpcyBwb2ludCwgY29tcHJvbWlzZSBkb2Vzbid0IGxlYWsgdGhlIHRy YWZmaWMga2V5cyBhdCBhbGwuIEJ5IGNvbnRyYXN0LCBpbiBDb250cm9sbGVyLUlLRQ0KIGJlY2F1 c2UgSSBuZWVkIHRvIHN0b3JlIG15IERIIHNoYXJlIGluZGVmaW5pdGVseSBpbiBjYXNlIGEgbmV3 IHBlZXIgY29tZXMgb25saW5lLCB0aGVuIHRoYXQgcmVwcmVzZW50cyBhIGxvbmctdGVybSBzb3Vy Y2Ugb2YgY29tcHJvbWlzZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0ssIEkgdGhpbmsgdGhp cyBpcyB3aGVyZSB5b3UgbWlzdW5kZXJzdG9vZCBzb21ldGhpbmcgb3Igd2UgZGlkbuKAmXQgZXhw bGFpbiB3ZWxsIGVub3VnaC4mbmJzcDsgVGhlcmUgYXJlIG5vIGxvbmctdGVybSBESCBrZXlzIGlu IENvbnRyb2xsZXItSUtFLiZuYnNwOyBBbGwgYXJlIGVwaGVtZXJhbC4mbmJzcDsgSXQgaXMgdHJ1 ZSB0aGF0IGR1ZSB0byBzeW5jaHJvbml6YXRpb24sIHlvdSB3aWxsIGxpa2VseSBrZWVwIHRoZW0g YSBsaXR0bGUgbG9uZ2VyLA0KIGJ1dCBuZXZlciBtb3JlIHRoYW4gMiBrZXkgbGlmZXRpbWVzLiZu YnNwOyBJZiB5b3UgcmUta2V5IGV2ZXJ5IDIgaG91cnMsIHRoZW4gdGhlIHdvcnN0IGNhc2UgaXMg dGhhdCB5b3VyIERIIHZhbHVlcyBhcmUga2VwdCBmb3IgNCBob3Vycy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RGF2ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_23A860FA61F44CD493DE2FCE06984B9Dciscocom_-- From nobody Mon Jul 22 10:28:14 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF63F1202DE for ; Mon, 22 Jul 2019 10:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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_HELO_NONE=0.001, SPF_NONE=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=rtfm-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 TvqmSqN5AAhz for ; Mon, 22 Jul 2019 10:28:01 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 D363E120336 for ; Mon, 22 Jul 2019 10:27:59 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id k18so38378876ljc.11 for ; Mon, 22 Jul 2019 10:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aR18sGsrus4/kqfzLVEarkKXKZF91EZn2R5GK9KH7tQ=; b=jbgGlDHmEKr73XKxRy9Z8tXjPu1FCcG5zh9VwVRortw9ZwNW9JzSXWf4RHUMbfVEuv IGUgkzjOj9XQZ5ZqzkeIf3UzulZbohwcwcrx8dwyohg1CJJZ1h/IV+CTK4Gf8nmbNQBf Rqu//UBxOL8lfq0vBblb8Vk2IpdrwKcDf+uGQksL8k/cSkj7pHUfz5MpnBki+q9n8jf2 bRo91RlI2o/TUrUk2KSSPxMa7D46Ntjco0IJWFk0su+Z/LOTsiUCM/McPSzqTKjwlt9T Q53BtGIcciRI+WD4zHjE2DNWJMCy+2idLtCHWeqOtoZgL1lb/HYjtj1C28AGjXQREFKc Z/4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aR18sGsrus4/kqfzLVEarkKXKZF91EZn2R5GK9KH7tQ=; b=oXRRgbOnq04fe0IOvtZgznQAngZZwhS3tFZ1RlqIKsuY2YCiwuLVFCabBG/rsmtwwE Dw4OypTSv0thF577aOuk3TTI8uDVIgQXgHKScjQgFEcZS/6HnRNH6xNDDjccI5hr8Iqc ko/L7Il/MKkvPhNJtrRvsXs0vT3GF8Rr4jFHycchYTpmvUHd4BWjNnvcrpgvrr29fa+b HL/T8tYGWH+PmrWdx8QU5z3nE1b3xkRe6UTggmfGuA5X5sYDJmsdosq5xss2iHSWXBMV l4WM/jxTA9Kp4W36zmOy8YgxWHrHHq9/5i3jYufiB67U2b1vwDlu8i4qCWRE5G1GTVf6 tAww== X-Gm-Message-State: APjAAAXSeuzBd5W+YpVHJTkfmvaS/Qh4iqnszR7t/6pglJTIq/Nm/hRH 9sVsFpu202aos81farDRW8iRvcEoIIUEtLcsouRU4A== X-Google-Smtp-Source: APXvYqxE/3g4aqEj9q1B933kv/Vb6+aooutlRZFCnVXqVe5L99fTwEQHdL51KGYlZ3PPuys69H0MeF7mVtI4QF2N8os= X-Received: by 2002:a2e:b0e6:: with SMTP id h6mr35347862ljl.18.1563816477477; Mon, 22 Jul 2019 10:27:57 -0700 (PDT) MIME-Version: 1.0 References: <698A5E01-5924-4D6C-9BD9-A8E87712086B@cisco.com> <23A860FA-61F4-4CD4-93DE-2FCE06984B9D@cisco.com> In-Reply-To: <23A860FA-61F4-4CD4-93DE-2FCE06984B9D@cisco.com> From: Eric Rescorla Date: Mon, 22 Jul 2019 10:27:21 -0700 Message-ID: To: "David Carrel (carrel)" Cc: "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a260a7058e486569" Archived-At: Subject: Re: [Secdispatch] Controller-IKE X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 17:28:08 -0000 --000000000000a260a7058e486569 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for clarifying. With that said, it's possible to do better than this if you use a conventional AKE and time out associations somewhat aggressively. -Ekr On Mon, Jul 22, 2019 at 10:09 AM David Carrel (carrel) wrote: > > > > > * The PFS story here seems pretty bad: I'm assuming that people > aren't going to change their DH keys very often (as it's extremely > expensive for everyone else). > > True, the DH load can be expensive, but no more so than an equivalent mes= h > of traditional IKE. We would not need to re-key any less often. I belie= ve > this makes the PFS story equivalent. > > This doesn't seem correct to me. Consider the case where you do pairwise > IKE and then delete the SA and the DH ephemerals. At this point, compromi= se > doesn't leak the traffic keys at all. By contrast, in Controller-IKE > because I need to store my DH share indefinitely in case a new peer comes > online, then that represents a long-term source of compromise. > > > > OK, I think this is where you misunderstood something or we didn=E2=80=99= t explain > well enough. There are no long-term DH keys in Controller-IKE. All are > ephemeral. It is true that due to synchronization, you will likely keep > them a little longer, but never more than 2 key lifetimes. If you re-key > every 2 hours, then the worst case is that your DH values are kept for 4 > hours. > > > > Dave > > > --000000000000a260a7058e486569 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for clarifying. With that said, it's possi= ble to do better than this if you use a conventional AKE and time out assoc= iations somewhat aggressively.

-Ekr

=



On Mon, Jul 22, 2019 at 10:09 AM David = Carrel (carrel) <carrel@cisco.com> wrote:

=C2=A0

=C2=A0

* The PFS story here seems pretty bad: I'm assuming that people
aren't going to change their DH keys very often (as it's extremely<= br> expensive for everyone else).

True, the DH load can be expensive, but no more so than an equivalent mesh = of traditional IKE.=C2=A0 We would not need to re-key any less often.=C2=A0= I believe this makes the PFS story equivalent.

This doesn't seem co= rrect to me. Consider the case where you do pairwise IKE and then delete th= e SA and the DH ephemerals. At this point, compromise doesn't leak the = traffic keys at all. By contrast, in Controller-IKE because I need to store my DH share indefinitely in case a new peer comes = online, then that represents a long-term source of compromise.

=C2=A0

OK, I think this is where you misunderstood somethin= g or we didn=E2=80=99t explain well enough.=C2=A0 There are no long-term DH= keys in Controller-IKE.=C2=A0 All are ephemeral.=C2=A0 It is true that due= to synchronization, you will likely keep them a little longer, but never more than 2 key lifetimes.=C2=A0 If you re-key every 2 hours, th= en the worst case is that your DH values are kept for 4 hours.

=C2=A0

Dave

=C2=A0

--000000000000a260a7058e486569-- From nobody Mon Jul 22 11:14:05 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2371200F4 for ; Mon, 22 Jul 2019 11:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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_HELO_NONE=0.001, SPF_NONE=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=rtfm-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 S_RY2vXOMHln for ; Mon, 22 Jul 2019 11:14:02 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDA9C1200E3 for ; Mon, 22 Jul 2019 11:14:01 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id t28so38520102lje.9 for ; Mon, 22 Jul 2019 11:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zGBWNsVdoIOKVCVYV3pQF1+T8MdbUPGem1shPYv7rKs=; b=iiMcwWK83Azhc6dOPF2co8C+a8AN8mfTuYGImnEUULq40/oLxcXypUMFkzYzWGriIp ITQNLBh/nJ20qluvlP6XkggH7YJvMZ8+gTDllGa4kozFMao/Pd/2fK7deWNExSxwwg/p T4rfSRB5u+6qgEHikjYPPDQEBj0u0RDBLd6InKJ6K4G4Weu5imJ/kmKAFGW9DpZbuQ7e ewLvMw2RTFpauaPN9fEoKZbnZqJ+hFmpTcfvbYPL9gly0OghKeSpY71pudY1hixdob4d 72NIRIqvQk/T+QKagLyv2bfvwRzfhzfQw/o2sDzZVugrRn/BnrLOXZCyyI37k08xv7aQ hCYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zGBWNsVdoIOKVCVYV3pQF1+T8MdbUPGem1shPYv7rKs=; b=I+l6O/9O9OrpgORPGu35DrmA4VW0ZM0TxoBjrs/psG0bCtq5rZ64uyAsfrbyuV/C+8 ymXGavNhHovS/PYUNtb4LDtUsrkQR+QSHxe6GqtyTF0ksiBlhDyWTNY3AKfrnicmC//l gBgJqXQoF9nO5TfngklnPQeo3UAdoCRtg0Uv5qbn95A+D+x7CfzHA3jGTnxNuTpc7Jw0 2jQBRvkTBpekpWHDSs3p6t9hpt8l6H+pZHKN+LlXULtqPTKfdRwNIP3qpSHgct+2to2a +EkbUqPWuSbOnUmfSJeQcO3yufM3DmHj2S61cXhAUPk/eA4OPYZw/d28ss8HVEQf6S// 3T0Q== X-Gm-Message-State: APjAAAVvh0sbThex6fYkSta3hxADkC59c9LN6ZqAgwoodLy/zj08qkQG 0uQlnP7hnSwRJbniSy6F1wbtrpfebYPgWO36q7I= X-Google-Smtp-Source: APXvYqxb0N1LwU+MyV37LYF2B7lrpY9iux7l4B5ceiYEIIQL5pSqz8kWa3nlVM/5loS4kFPubh5klTmERV3qTlAoehM= X-Received: by 2002:a2e:8892:: with SMTP id k18mr37626749lji.239.1563819240057; Mon, 22 Jul 2019 11:14:00 -0700 (PDT) MIME-Version: 1.0 References: <698A5E01-5924-4D6C-9BD9-A8E87712086B@cisco.com> <23A860FA-61F4-4CD4-93DE-2FCE06984B9D@cisco.com> In-Reply-To: From: Eric Rescorla Date: Mon, 22 Jul 2019 11:13:24 -0700 Message-ID: To: "David Carrel (carrel)" Cc: "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004bfae0058e490a82" Archived-At: Subject: Re: [Secdispatch] Controller-IKE X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 18:14:04 -0000 --0000000000004bfae0058e490a82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable David, At the mic today, you said that C-IKE was 2N complexity rather than N^2 complexity in terms of messages. Here's what confuses me. Just for simplicity, imagine that we do this in two phases: everyone registers their key with the controller and then the controller disseminates them. At this point, the controller has N keys and it needs to send them to N endpoints. If you are able to broadcast to all the nodes at once, then the controller will send N keys, so the total overhead is 2N (N uploads + N downloads). However, if the controller has point to point links, then the controller has to send ~N^2 keys (N-1 keys down N links). So those might be bundled into a single message, but you still have to send N^2 keys. Or am I missing something? -Ekr On Mon, Jul 22, 2019 at 10:27 AM Eric Rescorla wrote: > Thanks for clarifying. With that said, it's possible to do better than > this if you use a conventional AKE and time out associations somewhat > aggressively. > > -Ekr > > > > > On Mon, Jul 22, 2019 at 10:09 AM David Carrel (carrel) > wrote: > >> >> >> >> >> * The PFS story here seems pretty bad: I'm assuming that people >> aren't going to change their DH keys very often (as it's extremely >> expensive for everyone else). >> >> True, the DH load can be expensive, but no more so than an equivalent >> mesh of traditional IKE. We would not need to re-key any less often. I >> believe this makes the PFS story equivalent. >> >> This doesn't seem correct to me. Consider the case where you do pairwise >> IKE and then delete the SA and the DH ephemerals. At this point, comprom= ise >> doesn't leak the traffic keys at all. By contrast, in Controller-IKE >> because I need to store my DH share indefinitely in case a new peer come= s >> online, then that represents a long-term source of compromise. >> >> >> >> OK, I think this is where you misunderstood something or we didn=E2=80= =99t >> explain well enough. There are no long-term DH keys in Controller-IKE. >> All are ephemeral. It is true that due to synchronization, you will lik= ely >> keep them a little longer, but never more than 2 key lifetimes. If you >> re-key every 2 hours, then the worst case is that your DH values are kep= t >> for 4 hours. >> >> >> >> Dave >> >> >> > --0000000000004bfae0058e490a82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
David,

At the mic today, you= said that C-IKE was 2N complexity rather than N^2 complexity in terms of m= essages. Here's what confuses me.

Just for sim= plicity, imagine that we do this in two phases: everyone registers their ke= y with the controller and then the controller disseminates them. At this po= int, the controller has N keys and it needs to send them to N endpoints. If= you are able to broadcast to all the nodes at once, then the controller wi= ll send N keys, so the total overhead is 2N (N uploads + N downloads). Howe= ver, if the controller has point to point links, then the controller has to= send ~N^2 keys (N-1 keys down N links). So those might be bundled into a s= ingle message, but you still have to send N^2 keys. Or am I missing somethi= ng?

-Ekr






On Mon, Jul 22, 2019 at 10:27 AM= Eric Rescorla <ekr@rtfm.com> wro= te:
Thanks for clarifying. With that said, it's possible to do be= tter than this if you use a conventional AKE and time out associations some= what aggressively.

-Ekr

<= br>


On Mon, Jul 22, 2019 at 10:09 AM David Carrel (carr= el) <carrel@cisco.= com> wrote:

=C2=A0

=C2=A0

* The PFS story here seems pretty bad: I'm assuming that people
aren't going to change their DH keys very often (as it's extremely<= br> expensive for everyone else).

True, the DH load can be expensive, but no more so than an equivalent mesh = of traditional IKE.=C2=A0 We would not need to re-key any less often.=C2=A0= I believe this makes the PFS story equivalent.

This doesn't seem co= rrect to me. Consider the case where you do pairwise IKE and then delete th= e SA and the DH ephemerals. At this point, compromise doesn't leak the = traffic keys at all. By contrast, in Controller-IKE because I need to store my DH share indefinitely in case a new peer comes = online, then that represents a long-term source of compromise.

=C2=A0

OK, I think this is where you misunderstood somethin= g or we didn=E2=80=99t explain well enough.=C2=A0 There are no long-term DH= keys in Controller-IKE.=C2=A0 All are ephemeral.=C2=A0 It is true that due= to synchronization, you will likely keep them a little longer, but never more than 2 key lifetimes.=C2=A0 If you re-key every 2 hours, th= en the worst case is that your DH values are kept for 4 hours.

=C2=A0

Dave

=C2=A0

--0000000000004bfae0058e490a82-- From nobody Mon Jul 22 11:19:09 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707CE1200CC for ; Mon, 22 Jul 2019 11:19:08 -0700 (PDT) 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_HELO_NONE=0.001, 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 5FRIBKRmyjFd for ; Mon, 22 Jul 2019 11:19:06 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 B4F41120089 for ; Mon, 22 Jul 2019 11:19:06 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6MIJ0U9000940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Jul 2019 14:19:02 -0400 Date: Mon, 22 Jul 2019 13:18:59 -0500 From: Benjamin Kaduk To: Eric Rescorla Cc: "David Carrel (carrel)" , "secdispatch@ietf.org" Message-ID: <20190722181859.GD99187@kduck.mit.edu> References: <698A5E01-5924-4D6C-9BD9-A8E87712086B@cisco.com> <23A860FA-61F4-4CD4-93DE-2FCE06984B9D@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Secdispatch] Controller-IKE X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 18:19:09 -0000 On Mon, Jul 22, 2019 at 11:13:24AM -0700, Eric Rescorla wrote: > David, > > At the mic today, you said that C-IKE was 2N complexity rather than N^2 > complexity in terms of messages. Here's what confuses me. > > Just for simplicity, imagine that we do this in two phases: everyone > registers their key with the controller and then the controller > disseminates them. At this point, the controller has N keys and it needs to > send them to N endpoints. If you are able to broadcast to all the nodes at > once, then the controller will send N keys, so the total overhead is 2N (N > uploads + N downloads). However, if the controller has point to point > links, then the controller has to send ~N^2 keys (N-1 keys down N links). > So those might be bundled into a single message, but you still have to send > N^2 keys. Or am I missing something? I'm p robably missing something too, but there's a couple potential differences from what you describe -- the flow down from the controller to the endpoints can be a P2MP flow, and also if the controller knows the overlay network, it knows that it only has to send each endpoint (a specific) 10 keys for that endpoint to talk to the other endpoints it needs to. That is, each endpoint may not need (or be able to!) store the keys for all N endpoints. -Ben From nobody Mon Jul 22 12:24:48 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44B2120125 for ; Mon, 22 Jul 2019 12:24:45 -0700 (PDT) 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 (1024-bit key) header.d=armh.onmicrosoft.com header.b=0lXNASPG; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=HPlA+XzL 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 QtZdulm1H7MM for ; Mon, 22 Jul 2019 12:24:41 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on062a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408EB12008C for ; Mon, 22 Jul 2019 12:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y9KeMnQR8t76yUSmQIV/PpKTiX/EX7y0mEvdDD/HV90=; b=0lXNASPGsOCCHpW0n8d1rvz33ngGwoQQ2q0O6Kl363Yw7gkDQrLUjbC+obUPrA8rkmHPphwjom49VHWy2MZXsGwLr4a62Q8nHbDlwEXfTB4PG8RhiQHc9xoIugUs4EWBftTT9tcUR1rYeZBRLqDnZ+nIcDkSPTDGqb0qZVsV23s= Received: from HE1PR0802CA0007.eurprd08.prod.outlook.com (2603:10a6:3:bd::17) by AM5PR0801MB1841.eurprd08.prod.outlook.com (2603:10a6:203:2e::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Mon, 22 Jul 2019 19:24:36 +0000 Received: from AM5EUR03FT046.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e08::209) by HE1PR0802CA0007.outlook.office365.com (2603:10a6:3:bd::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2094.12 via Frontend Transport; Mon, 22 Jul 2019 19:24:36 +0000 Authentication-Results: spf=temperror (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=temperror action=none header.from=arm.com; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of arm.com: DNS Timeout) Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT046.mail.protection.outlook.com (10.152.16.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.18 via Frontend Transport; Mon, 22 Jul 2019 19:24:35 +0000 Received: ("Tessian outbound 3dc70fbcc089:v24"); Mon, 22 Jul 2019 19:24:33 +0000 X-CR-MTA-TID: 64aa7808 Received: from 77f6474af692.1 (cr-mta-lb-1.cr-mta-net [104.47.10.52]) by 64aa7808-outbound-1.mta.getcheckrecipient.com id 9CAA279B-E6EC-442F-8DD6-712B327520D6.1; Mon, 22 Jul 2019 19:24:28 +0000 Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp2052.outbound.protection.outlook.com [104.47.10.52]) by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 77f6474af692.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 22 Jul 2019 19:24:28 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eAaNLAGaLySJe9xtB6o5xih3kadC3g+WPnvkAZf6UnvcU9NayHh0Toi3Hb2+5i6K13LxtNezBwtg06KSBeFjM2zcPDcgGICg/laMYayoxtiyuoqUAy6CB0dNLb3CI6HUn7h8E4cK+fDkEIxPLd+6qaozTxCmtMdt0iGUppADLkUrzF66s55NLgZiNkurc147OsO4AOnBcvYzWH+M2kdz/dqyBdg/5oy+21vlHwcaBedlRR7oSInK72TvGsOakJTyKPcqxiBUTQXKknOX+CvN36vqBKABn4zjyo43fI/MA/5n+pV5bib4MfcuMCHWKrQgg2JF4Tj4vXAzpf6CH4eTQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e0WBzmwfmaw8HURjt3EpoGQ4C+vrJkqddUmx3H1tUpU=; b=YiL/Sq7EE3RS+xleYA0IppiY6BHLgI3Pkz2HtrJhwsEf0ZynS04OhPgqX/NsSAovV+EUc0maCq7mqY+eEp+b2NXUU1LNg+8DO+NBAdZv3fFOx3ztjGRb0iIFhqs3HfwzTbXxbGG0MfpRz1NlTJZifxp9Cg/IsnDliRyiFDte9YlOg7udCMxtvTWBR7FnzlgqwzchqyYou5pHNZn2RBXG7D0pyPN+Xj8tHdxzcU0cq52r88yieaElkTom3DGZg56vI/fUY0maB/mwuZW6DHfJ3XplDRZjQ+WFB5zAowX2OJVai93sm+tjO2ITRa1vxBlPmckUU/+/Fm75UnSJvdTocw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=arm.com;dmarc=pass action=none header.from=arm.com;dkim=pass header.d=arm.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e0WBzmwfmaw8HURjt3EpoGQ4C+vrJkqddUmx3H1tUpU=; b=HPlA+XzL4CIfd3qaVHdn1yghm+LS4hxQVPXAnvxpExahfccL98K8a++vohxs/yDJhKAgAmAPD1s0faN4eg+UmIri2zz8WXSz1BftL6unALaBLc4wdHeatWOfvERRPSRqzqh6ol/k7OER9tIDZQJiic1A754czfmaspC4tK99sDY= Received: from AM0PR08MB5345.eurprd08.prod.outlook.com (52.132.212.135) by AM0PR08MB3187.eurprd08.prod.outlook.com (52.134.92.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.17; Mon, 22 Jul 2019 19:24:26 +0000 Received: from AM0PR08MB5345.eurprd08.prod.outlook.com ([fe80::79c6:adb9:1535:b47b]) by AM0PR08MB5345.eurprd08.prod.outlook.com ([fe80::79c6:adb9:1535:b47b%2]) with mapi id 15.20.2094.017; Mon, 22 Jul 2019 19:24:26 +0000 From: Hannes Tschofenig To: Eric Rescorla , "David Carrel (carrel)" CC: "secdispatch@ietf.org" Thread-Topic: [Secdispatch] Controller-IKE Thread-Index: AQHVPqG2qaTEIVD/zEy+2+Xv9S/jD6bWtyQA//+edACAAH29AP//mpwAgAB6O4CAAAzeAIAAE0DQ Date: Mon, 22 Jul 2019 19:24:26 +0000 Message-ID: References: <698A5E01-5924-4D6C-9BD9-A8E87712086B@cisco.com> <23A860FA-61F4-4CD4-93DE-2FCE06984B9D@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 3a147245-afa7-42a4-843a-1d1d64fa5043.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [31.133.138.73] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 98a999e9-4b55-447d-0292-08d70eda3b26 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam-Untrusted: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR08MB3187; X-MS-TrafficTypeDiagnostic: AM0PR08MB3187:|AM5PR0801MB1841: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 01068D0A20 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(376002)(39860400002)(136003)(396003)(199004)(189003)(110136005)(6436002)(4326008)(316002)(99286004)(86362001)(66066001)(2906002)(54896002)(9686003)(6306002)(68736007)(478600001)(236005)(66946007)(7736002)(76116006)(6246003)(66476007)(66556008)(66446008)(64756008)(33656002)(53936002)(55016002)(74316002)(5660300002)(8936002)(52536014)(229853002)(446003)(102836004)(25786009)(14444005)(186003)(256004)(8676002)(81156014)(26005)(81166006)(14454004)(476003)(76176011)(486006)(71190400001)(11346002)(71200400001)(6116002)(6506007)(7696005)(3846002)(790700001)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB3187; H:AM0PR08MB5345.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info-Original: B7GRGIRkC3pq+kp3gysLewuroMFefCkHgrl/U5To9dGi8UnLnc7bf84DcTk49BL0oSePN6qlRo35gjv09rSqNCljGYP2Q3kkbr5JPm0VikycG9pdNEWHX2e1dB97JzX+SUCwwzcuuPGEuCBxNmrBqvSNxdyyxkn8FNTJIw5POuYv70cbKtVuxsitWJ//llQxaxIsj5cCMXJCqbD8leIX3ByrE6nmg4Jjd1N9skTYv7pgblOUWDFHYHxWVas6LEeN+udOQEKtMKlyuX8x8ck3owjQwNWgBBXXfw86PzysTqihVNGxDbfj/xlihxiun5XmCSJNL74oaNBBxqc5j0jW+cORPez9KSyxJR31YPNeKDvfWRvWPjKn2u8fLD8aUq0y64cwLdRrAIOGmQres/bcoh3vFW5655nj8OSZtLKLlYY= Content-Type: multipart/alternative; boundary="_000_AM0PR08MB5345775700A3B8AE1E014D18FAC40AM0PR08MB5345eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3187 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT046.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(39860400002)(346002)(376002)(2980300002)(40434004)(199004)(189003)(66066001)(7736002)(74316002)(110136005)(2906002)(16586007)(61614004)(229853002)(53546011)(86362001)(76176011)(33964004)(102836004)(486006)(26005)(478600001)(99286004)(7696005)(476003)(316002)(26826003)(126002)(186003)(6506007)(25786009)(33656002)(356004)(11346002)(446003)(36906005)(14444005)(5024004)(790700001)(336012)(6116002)(63370400001)(8676002)(3846002)(55016002)(14454004)(8936002)(76130400001)(4326008)(63350400001)(70586007)(52536014)(70206006)(81156014)(81166006)(71190400001)(5660300002)(236005)(22756006)(54896002)(9686003)(6246003)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0801MB1841; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:TempError; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1; MX:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: 14855b9a-e325-4037-7a75-08d70eda35ea X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(710020)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:AM5PR0801MB1841; X-Forefront-PRVS: 01068D0A20 X-Microsoft-Antispam-Message-Info: 2yPC4Gtt9Mkn6TNuTQUku2yzSX13GJcJzAeHhhuPnkIjWKPVneRWAQ4W8WF/uAeNFZ8hUpLiEZY+rDBsj8t9ZsKqd8+J7VDIKqwEYdiPUcO3aNdbb/u3qLp5f937xuqrk48QrfJ4hRCPw2na6DKbPxDWqhA0fyXRmNXqaoRFVnP/OH86BfER8ozbL5Ahbh2QDLcY4IKgnEYxZs/bWBmSGfUj5fDhrJWYCYioEPhRyUYY7Nj71Pd8tGdW6FgEHwITpNJB+mI+iM7pz4IJUt+yEOpncUKbDPTQLC6k1EyNd2ZDKPQBCqTDRI/WhBIhhTs+6S4QtUCHLR8WZDj/a/wgaPyVcWaLlLoiQISLLettxFfH8biKBVHHPrkeS86IyvAtGB2OwfH3M1Rcr8K+IKKCBZiIwrJ+clsohLdDpJuOVD0= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jul 2019 19:24:35.3229 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 98a999e9-4b55-447d-0292-08d70eda3b26 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1841 Archived-At: Subject: Re: [Secdispatch] Controller-IKE X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 19:24:46 -0000 --_000_AM0PR08MB5345775700A3B8AE1E014D18FAC40AM0PR08MB5345eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWRkaXRpb25hbCBxdWVzdGlvbjogSWYgeW91IHVzZSBESCB5b3Ugb2Z0ZW4gd2FudCB0byB1c2Ug YW4gZXBoZW1lcmFsIERIIGtleSB3aXRoIGVhY2ggY29tbXVuaWNhdGlvbiBwYXJ0bmVyLiBJcyB0 aGlzIGFsc28gdGhlIGNhc2UgaW4geW91ciBkZXBsb3ltZW50Pw0KDQpGcm9tOiBTZWNkaXNwYXRj aCA8c2VjZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEVyaWMgUmVzY29y bGENClNlbnQ6IE1vbnRhZywgMjIuIEp1bGkgMjAxOSAxNDoxMw0KVG86IERhdmlkIENhcnJlbCAo Y2FycmVsKSA8Y2FycmVsQGNpc2NvLmNvbT4NCkNjOiBzZWNkaXNwYXRjaEBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtTZWNkaXNwYXRjaF0gQ29udHJvbGxlci1JS0UNCg0KRGF2aWQsDQoNCkF0IHRo ZSBtaWMgdG9kYXksIHlvdSBzYWlkIHRoYXQgQy1JS0Ugd2FzIDJOIGNvbXBsZXhpdHkgcmF0aGVy IHRoYW4gTl4yIGNvbXBsZXhpdHkgaW4gdGVybXMgb2YgbWVzc2FnZXMuIEhlcmUncyB3aGF0IGNv bmZ1c2VzIG1lLg0KDQpKdXN0IGZvciBzaW1wbGljaXR5LCBpbWFnaW5lIHRoYXQgd2UgZG8gdGhp cyBpbiB0d28gcGhhc2VzOiBldmVyeW9uZSByZWdpc3RlcnMgdGhlaXIga2V5IHdpdGggdGhlIGNv bnRyb2xsZXIgYW5kIHRoZW4gdGhlIGNvbnRyb2xsZXIgZGlzc2VtaW5hdGVzIHRoZW0uIEF0IHRo aXMgcG9pbnQsIHRoZSBjb250cm9sbGVyIGhhcyBOIGtleXMgYW5kIGl0IG5lZWRzIHRvIHNlbmQg dGhlbSB0byBOIGVuZHBvaW50cy4gSWYgeW91IGFyZSBhYmxlIHRvIGJyb2FkY2FzdCB0byBhbGwg dGhlIG5vZGVzIGF0IG9uY2UsIHRoZW4gdGhlIGNvbnRyb2xsZXIgd2lsbCBzZW5kIE4ga2V5cywg c28gdGhlIHRvdGFsIG92ZXJoZWFkIGlzIDJOIChOIHVwbG9hZHMgKyBOIGRvd25sb2FkcykuIEhv d2V2ZXIsIGlmIHRoZSBjb250cm9sbGVyIGhhcyBwb2ludCB0byBwb2ludCBsaW5rcywgdGhlbiB0 aGUgY29udHJvbGxlciBoYXMgdG8gc2VuZCB+Tl4yIGtleXMgKE4tMSBrZXlzIGRvd24gTiBsaW5r cykuIFNvIHRob3NlIG1pZ2h0IGJlIGJ1bmRsZWQgaW50byBhIHNpbmdsZSBtZXNzYWdlLCBidXQg eW91IHN0aWxsIGhhdmUgdG8gc2VuZCBOXjIga2V5cy4gT3IgYW0gSSBtaXNzaW5nIHNvbWV0aGlu Zz8NCg0KLUVrcg0KDQoNCg0KDQoNCg0KT24gTW9uLCBKdWwgMjIsIDIwMTkgYXQgMTA6MjcgQU0g RXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToN ClRoYW5rcyBmb3IgY2xhcmlmeWluZy4gV2l0aCB0aGF0IHNhaWQsIGl0J3MgcG9zc2libGUgdG8g ZG8gYmV0dGVyIHRoYW4gdGhpcyBpZiB5b3UgdXNlIGEgY29udmVudGlvbmFsIEFLRSBhbmQgdGlt ZSBvdXQgYXNzb2NpYXRpb25zIHNvbWV3aGF0IGFnZ3Jlc3NpdmVseS4NCg0KLUVrcg0KDQoNCg0K DQpPbiBNb24sIEp1bCAyMiwgMjAxOSBhdCAxMDowOSBBTSBEYXZpZCBDYXJyZWwgKGNhcnJlbCkg PGNhcnJlbEBjaXNjby5jb208bWFpbHRvOmNhcnJlbEBjaXNjby5jb20+PiB3cm90ZToNCg0KDQoq IFRoZSBQRlMgc3RvcnkgaGVyZSBzZWVtcyBwcmV0dHkgYmFkOiBJJ20gYXNzdW1pbmcgdGhhdCBw ZW9wbGUNCmFyZW4ndCBnb2luZyB0byBjaGFuZ2UgdGhlaXIgREgga2V5cyB2ZXJ5IG9mdGVuIChh cyBpdCdzIGV4dHJlbWVseQ0KZXhwZW5zaXZlIGZvciBldmVyeW9uZSBlbHNlKS4NClRydWUsIHRo ZSBESCBsb2FkIGNhbiBiZSBleHBlbnNpdmUsIGJ1dCBubyBtb3JlIHNvIHRoYW4gYW4gZXF1aXZh bGVudCBtZXNoIG9mIHRyYWRpdGlvbmFsIElLRS4gIFdlIHdvdWxkIG5vdCBuZWVkIHRvIHJlLWtl eSBhbnkgbGVzcyBvZnRlbi4gIEkgYmVsaWV2ZSB0aGlzIG1ha2VzIHRoZSBQRlMgc3RvcnkgZXF1 aXZhbGVudC4NClRoaXMgZG9lc24ndCBzZWVtIGNvcnJlY3QgdG8gbWUuIENvbnNpZGVyIHRoZSBj YXNlIHdoZXJlIHlvdSBkbyBwYWlyd2lzZSBJS0UgYW5kIHRoZW4gZGVsZXRlIHRoZSBTQSBhbmQg dGhlIERIIGVwaGVtZXJhbHMuIEF0IHRoaXMgcG9pbnQsIGNvbXByb21pc2UgZG9lc24ndCBsZWFr IHRoZSB0cmFmZmljIGtleXMgYXQgYWxsLiBCeSBjb250cmFzdCwgaW4gQ29udHJvbGxlci1JS0Ug YmVjYXVzZSBJIG5lZWQgdG8gc3RvcmUgbXkgREggc2hhcmUgaW5kZWZpbml0ZWx5IGluIGNhc2Ug YSBuZXcgcGVlciBjb21lcyBvbmxpbmUsIHRoZW4gdGhhdCByZXByZXNlbnRzIGEgbG9uZy10ZXJt IHNvdXJjZSBvZiBjb21wcm9taXNlLg0KDQpPSywgSSB0aGluayB0aGlzIGlzIHdoZXJlIHlvdSBt aXN1bmRlcnN0b29kIHNvbWV0aGluZyBvciB3ZSBkaWRu4oCZdCBleHBsYWluIHdlbGwgZW5vdWdo LiAgVGhlcmUgYXJlIG5vIGxvbmctdGVybSBESCBrZXlzIGluIENvbnRyb2xsZXItSUtFLiAgQWxs IGFyZSBlcGhlbWVyYWwuICBJdCBpcyB0cnVlIHRoYXQgZHVlIHRvIHN5bmNocm9uaXphdGlvbiwg eW91IHdpbGwgbGlrZWx5IGtlZXAgdGhlbSBhIGxpdHRsZSBsb25nZXIsIGJ1dCBuZXZlciBtb3Jl IHRoYW4gMiBrZXkgbGlmZXRpbWVzLiAgSWYgeW91IHJlLWtleSBldmVyeSAyIGhvdXJzLCB0aGVu IHRoZSB3b3JzdCBjYXNlIGlzIHRoYXQgeW91ciBESCB2YWx1ZXMgYXJlIGtlcHQgZm9yIDQgaG91 cnMuDQoNCkRhdmUNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1h aWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBw cml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29u dGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3Rv cmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K --_000_AM0PR08MB5345775700A3B8AE1E014D18FAC40AM0PR08MB5345eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWRkaXRpb25hbCBxdWVzdGlvbjog SWYgeW91IHVzZSBESCB5b3Ugb2Z0ZW4gd2FudCB0byB1c2UgYW4gZXBoZW1lcmFsIERIIGtleSB3 aXRoIGVhY2ggY29tbXVuaWNhdGlvbiBwYXJ0bmVyLiBJcyB0aGlzIGFsc28gdGhlIGNhc2UgaW4g eW91ciBkZXBsb3ltZW50Pw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBTZWNkaXNwYXRjaCAm bHQ7c2VjZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+ RXJpYyBSZXNjb3JsYTxicj4NCjxiPlNlbnQ6PC9iPiBNb250YWcsIDIyLiBKdWxpIDIwMTkgMTQ6 MTM8YnI+DQo8Yj5Ubzo8L2I+IERhdmlkIENhcnJlbCAoY2FycmVsKSAmbHQ7Y2FycmVsQGNpc2Nv LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHNlY2Rpc3BhdGNoQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbU2VjZGlzcGF0Y2hdIENvbnRyb2xsZXItSUtFPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdmlkLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BdCB0aGUgbWljIHRvZGF5LCB5b3Ug c2FpZCB0aGF0IEMtSUtFIHdhcyAyTiBjb21wbGV4aXR5IHJhdGhlciB0aGFuIE5eMiBjb21wbGV4 aXR5IGluIHRlcm1zIG9mIG1lc3NhZ2VzLiBIZXJlJ3Mgd2hhdCBjb25mdXNlcyBtZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBmb3Ig c2ltcGxpY2l0eSwgaW1hZ2luZSB0aGF0IHdlIGRvIHRoaXMgaW4gdHdvIHBoYXNlczogZXZlcnlv bmUgcmVnaXN0ZXJzIHRoZWlyIGtleSB3aXRoIHRoZSBjb250cm9sbGVyIGFuZCB0aGVuIHRoZSBj b250cm9sbGVyIGRpc3NlbWluYXRlcyB0aGVtLiBBdCB0aGlzIHBvaW50LCB0aGUgY29udHJvbGxl ciBoYXMgTiBrZXlzIGFuZCBpdCBuZWVkcyB0byBzZW5kIHRoZW0gdG8gTiBlbmRwb2ludHMuIElm DQogeW91IGFyZSBhYmxlIHRvIGJyb2FkY2FzdCB0byBhbGwgdGhlIG5vZGVzIGF0IG9uY2UsIHRo ZW4gdGhlIGNvbnRyb2xsZXIgd2lsbCBzZW5kIE4ga2V5cywgc28gdGhlIHRvdGFsIG92ZXJoZWFk IGlzIDJOIChOIHVwbG9hZHMgJiM0MzsgTiBkb3dubG9hZHMpLiBIb3dldmVyLCBpZiB0aGUgY29u dHJvbGxlciBoYXMgcG9pbnQgdG8gcG9pbnQgbGlua3MsIHRoZW4gdGhlIGNvbnRyb2xsZXIgaGFz IHRvIHNlbmQgfk5eMiBrZXlzIChOLTEga2V5cyBkb3duIE4NCiBsaW5rcykuIFNvIHRob3NlIG1p Z2h0IGJlIGJ1bmRsZWQgaW50byBhIHNpbmdsZSBtZXNzYWdlLCBidXQgeW91IHN0aWxsIGhhdmUg dG8gc2VuZCBOXjIga2V5cy4gT3IgYW0gSSBtaXNzaW5nIHNvbWV0aGluZz88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g TW9uLCBKdWwgMjIsIDIwMTkgYXQgMTA6MjcgQU0gRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmVrckBydGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcyBmb3IgY2xhcmlmeWluZy4gV2l0aCB0aGF0IHNhaWQsIGl0J3MgcG9zc2li bGUgdG8gZG8gYmV0dGVyIHRoYW4gdGhpcyBpZiB5b3UgdXNlIGEgY29udmVudGlvbmFsIEFLRSBh bmQgdGltZSBvdXQgYXNzb2NpYXRpb25zIHNvbWV3aGF0IGFnZ3Jlc3NpdmVseS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBN b24sIEp1bCAyMiwgMjAxOSBhdCAxMDowOSBBTSBEYXZpZCBDYXJyZWwgKGNhcnJlbCkgJmx0Ozxh IGhyZWY9Im1haWx0bzpjYXJyZWxAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2FycmVsQGNp c2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0 Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xv cjpjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciByZ2IoMjA0LDIwNCwyMDQp Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxzcGFuIGxh bmc9IkVOLVVTIj4qIFRoZSBQRlMgc3RvcnkgaGVyZSBzZWVtcyBwcmV0dHkgYmFkOiBJJ20gYXNz dW1pbmcgdGhhdCBwZW9wbGU8YnI+DQphcmVuJ3QgZ29pbmcgdG8gY2hhbmdlIHRoZWlyIERIIGtl eXMgdmVyeSBvZnRlbiAoYXMgaXQncyBleHRyZW1lbHk8YnI+DQpleHBlbnNpdmUgZm9yIGV2ZXJ5 b25lIGVsc2UpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4t bGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPlRydWUsIHRoZSBESCBsb2FkIGNhbiBi ZSBleHBlbnNpdmUsIGJ1dCBubyBtb3JlIHNvIHRoYW4gYW4gZXF1aXZhbGVudCBtZXNoIG9mIHRy YWRpdGlvbmFsIElLRS4mbmJzcDsgV2Ugd291bGQgbm90IG5lZWQgdG8gcmUta2V5IGFueSBsZXNz IG9mdGVuLiZuYnNwOyBJIGJlbGlldmUgdGhpcyBtYWtlcyB0aGUgUEZTIHN0b3J5IGVxdWl2YWxl bnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIGRvZXNuJ3Qgc2VlbSBjb3JyZWN0 IHRvIG1lLiBDb25zaWRlciB0aGUgY2FzZSB3aGVyZSB5b3UgZG8gcGFpcndpc2UgSUtFIGFuZCB0 aGVuIGRlbGV0ZSB0aGUgU0EgYW5kIHRoZSBESCBlcGhlbWVyYWxzLiBBdCB0aGlzIHBvaW50LCBj b21wcm9taXNlIGRvZXNuJ3QgbGVhayB0aGUgdHJhZmZpYyBrZXlzIGF0IGFsbC4gQnkgY29udHJh c3QsIGluIENvbnRyb2xsZXItSUtFIGJlY2F1c2UgSSBuZWVkIHRvIHN0b3JlDQogbXkgREggc2hh cmUgaW5kZWZpbml0ZWx5IGluIGNhc2UgYSBuZXcgcGVlciBjb21lcyBvbmxpbmUsIHRoZW4gdGhh dCByZXByZXNlbnRzIGEgbG9uZy10ZXJtIHNvdXJjZSBvZiBjb21wcm9taXNlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPk9LLCBJIHRoaW5rIHRoaXMgaXMgd2hlcmUgeW91IG1pc3VuZGVyc3Rvb2Qg c29tZXRoaW5nIG9yIHdlIGRpZG7igJl0IGV4cGxhaW4gd2VsbCBlbm91Z2guJm5ic3A7IFRoZXJl IGFyZSBubyBsb25nLXRlcm0gREgga2V5cyBpbiBDb250cm9sbGVyLUlLRS4mbmJzcDsgQWxsIGFy ZSBlcGhlbWVyYWwuJm5ic3A7DQogSXQgaXMgdHJ1ZSB0aGF0IGR1ZSB0byBzeW5jaHJvbml6YXRp b24sIHlvdSB3aWxsIGxpa2VseSBrZWVwIHRoZW0gYSBsaXR0bGUgbG9uZ2VyLCBidXQgbmV2ZXIg bW9yZSB0aGFuIDIga2V5IGxpZmV0aW1lcy4mbmJzcDsgSWYgeW91IHJlLWtleSBldmVyeSAyIGhv dXJzLCB0aGVuIHRoZSB3b3JzdCBjYXNlIGlzIHRoYXQgeW91ciBESCB2YWx1ZXMgYXJlIGtlcHQg Zm9yIDQgaG91cnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+RGF2ZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCklNUE9SVEFOVCBOT1RJ Q0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNv bmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVz ZSBpdCBmb3IgYW55IHB1cnBvc2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24g aW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM0PR08MB5345775700A3B8AE1E014D18FAC40AM0PR08MB5345eurp_-- From nobody Mon Jul 22 15:35:37 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E11120094 for ; Mon, 22 Jul 2019 15:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 3QENfRFZq_yA for ; Mon, 22 Jul 2019 15:35:33 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 D81E912006B for ; Mon, 22 Jul 2019 15:35:32 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x6MMZNti020160 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Jul 2019 01:35:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x6MMZMBI015494; Tue, 23 Jul 2019 01:35:22 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23862.14890.705851.475054@fireball.acr.fi> Date: Tue, 23 Jul 2019 01:35:22 +0300 From: Tero Kivinen To: Benjamin Kaduk Cc: Eric Rescorla , "secdispatch\@ietf.org" , "David Carrel \(carrel\)" In-Reply-To: <20190722181859.GD99187@kduck.mit.edu> References: <698A5E01-5924-4D6C-9BD9-A8E87712086B@cisco.com> <23A860FA-61F4-4CD4-93DE-2FCE06984B9D@cisco.com> <20190722181859.GD99187@kduck.mit.edu> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 16 min Archived-At: Subject: Re: [Secdispatch] Controller-IKE X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 22:35:36 -0000 Benjamin Kaduk writes: > On Mon, Jul 22, 2019 at 11:13:24AM -0700, Eric Rescorla wrote: > > David, > > > > At the mic today, you said that C-IKE was 2N complexity rather than N^2 > > complexity in terms of messages. Here's what confuses me. > > > > Just for simplicity, imagine that we do this in two phases: everyone > > registers their key with the controller and then the controller > > disseminates them. At this point, the controller has N keys and it needs to > > send them to N endpoints. If you are able to broadcast to all the nodes at > > once, then the controller will send N keys, so the total overhead is 2N (N > > uploads + N downloads). However, if the controller has point to point > > links, then the controller has to send ~N^2 keys (N-1 keys down N links). > > So those might be bundled into a single message, but you still have to send > > N^2 keys. Or am I missing something? I was pointing out that this is actually N^3 keys you need to transport if you you start building the network with one node at time. In the beginning there is only C (controller) and it has no keys. This was good, but then there was light. Key count over wire 0. Node 1 came up, sent its key to C and saw this is still good, as there is nobody for him to talk to. KCOW 1. Node 2 came up, sent its key to C and C saw that it needs to send the Node 2's key to Node 1, and Node 1's key to Node 2, it did so. KCOW += 1 + 2*1 = 4 Node 3 came up, sent its key to C, and C sent other keys it has to everybody else. KCOW += 1 + 3*2 = 11. Node n came up, sent its keys to C, and C sent other keys (n-1) it has to everybody else (n) KCOW += 1 + n*(n-1). The final count of key count over wire is n + n * (n-1) * (n-1)... Of course you could remember in C which keys you have already sent out, so in that case the key count over wire drops down to n + n * (n-1). When you compare this to the IKE case, where the node n coming up, it just needs to send diffie-hellman public keys out for 2 * m times, where m is the number of nodes it wants to talk. In general cases m << n. Also one node rekeying requires C to send its new key to every n-1 node in the network. In the IKE case rekeying just does sends keys out 2 * m times. It seems that you assumed that messages between the controller and node are free, but peer to peer messages between nodes are not. I do not belive in that. > I'm p robably missing something too, but there's a couple potential > differences from what you describe -- the flow down from the controller to > the endpoints can be a P2MP flow, and also if the controller knows the > overlay network, it knows that it only has to send each endpoint (a specific) > 10 keys for that endpoint to talk to the other endpoints it needs to. That > is, each endpoint may not need (or be able to!) store the keys for all N > endpoints. The whole idea in the controller IKE seemed to be that m == n-1, i.e., each node wants to talk to everybody else, otherwise normal IKE where nodes bring up SAs when they need it is much more efficient. -- kivinen@iki.fi From nobody Tue Jul 23 15:32:36 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B28120978 for ; Tue, 23 Jul 2019 15:32:32 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 (1024-bit key) header.d=ncsc.gov.uk 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 50TgBJ0Ap25U for ; Tue, 23 Jul 2019 15:32:23 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100128.outbound.protection.outlook.com [40.107.10.128]) (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 330E6120352 for ; Tue, 23 Jul 2019 15:32:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WQkNeC8rI2KP+8i+NyGsmkru92b2gMm8SGG23u/+mngBOFjS9XN3p/IhneYJvNnUpBzMIk/vlGtcTZUcWeRh99EYSZSAwLyI/Z7phSdCqgfgWK4BjlIAia/iDCXzRnY+TS4THrtncQcR2h+OW3O08iuOyJXqSsWuVX7s56jd6xr9dzSORKInIDNiNRuKm1jdtqAqUPplLPG4WVyznjqlBcPQfQXyy5wMiUEuYWCXN2Augou6IXw78HMFKd/S9Fgv709ZYjYgStEaWe943LMHtlAtPAIk8XZOJbVWd9LT7mbyoVYfbAOLq7meSmG1gurqoGjGmCIA/G6FU6HSYZwsgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2lMen621WF/oqoAv3aHIqwQck/8jcxXwVNptyygEMps=; b=eBoUWE47za2oTGN0FpWnGjVBi7onb3hjNq85Bk+zjYm9skiYLviYEz5fseufPe+zUiqMByipnGhRqf4EcFNhRCU8gzPyN8+u48wley5bOM8xVChTVQ9JjTYszCcY05d/QQ8ao+f1RJKuDsMye1m4Jmg8AaD9affj7FrXVLAIHMW8KQ+eI9A8zKwaY8QVJ1cJ0PUXfbd0YVym6nxMtAUY7y9b3oGpe0JggquDY3Ce3NU0NOLgfFiocKA3LlFM242c5FgMOXZeLb6Kjj7Ql9xCLwqUIV/h6i5x3qJIaUdB7O/tdLJAZnRxqBzDXPkNRi50i84hSLr80wqCNjgbI8g4KQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ncsc.gov.uk;dmarc=pass action=none header.from=ncsc.gov.uk;dkim=pass header.d=ncsc.gov.uk;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2lMen621WF/oqoAv3aHIqwQck/8jcxXwVNptyygEMps=; b=GasmMTz0FBd5Cx30FApbYZIsewPRVe0NK1bVvtKkRjB0/a94/33+0ri0NfTJlUAp0R+9KUFyRaf+FwMg7rjUrtfVCTMqhVjxT42ZyVVIw3kRxpS/v8tSw2UIBQeWlT3z8ujZEOPTt/QKd88txKjD95sJH1hqmDyQnTD+UHu6B9Q= Received: from LNXP123MB2570.GBRP123.PROD.OUTLOOK.COM (20.176.159.147) by LNXP123MB2250.GBRP123.PROD.OUTLOOK.COM (20.176.159.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Tue, 23 Jul 2019 22:32:20 +0000 Received: from LNXP123MB2570.GBRP123.PROD.OUTLOOK.COM ([fe80::36:e9a5:cb51:4859]) by LNXP123MB2570.GBRP123.PROD.OUTLOOK.COM ([fe80::36:e9a5:cb51:4859%5]) with mapi id 15.20.2094.013; Tue, 23 Jul 2019 22:32:20 +0000 From: Mark O To: "smart@irtf.org" , "secdispatch@ietf.org" Thread-Topic: Re: [Smart] [Secdispatch] New Version Notification for draft-lazanski-smart-users-internet-00.txt Thread-Index: AdVBpXaIHMgcNuHoTa6WtdnBmIdnnw== Date: Tue, 23 Jul 2019 22:32:20 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Mark.O@ncsc.gov.uk; x-originating-ip: [51.141.26.231] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b1729b0b-59a7-4433-30d7-08d70fbda01e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LNXP123MB2250; x-ms-traffictypediagnostic: LNXP123MB2250: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0107098B6C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(376002)(39850400004)(396003)(346002)(366004)(189003)(199004)(51444003)(54896002)(9686003)(6306002)(53936002)(55016002)(486006)(2420400007)(45080400002)(6116002)(66574012)(3846002)(33656002)(2906002)(478600001)(7736002)(8936002)(26005)(25786009)(74316002)(476003)(81156014)(790700001)(6436002)(15650500001)(71200400001)(8676002)(186003)(66066001)(7110500001)(102836004)(53546011)(71190400001)(55236004)(966005)(99286004)(316002)(110136005)(81166006)(6506007)(14454004)(575854001)(14444005)(256004)(2501003)(6246003)(229853002)(68736007)(30864003)(64756008)(52536014)(66946007)(86362001)(66446008)(66556008)(7696005)(66476007)(5660300002)(76116006); DIR:OUT; SFP:1102; SCL:1; SRVR:LNXP123MB2250; H:LNXP123MB2570.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: uuahvh1gd90dMCwie3n5JfLUl8j7avKSk5BRoI3CKCDfsmYYJ1ysvUxSaVgs/YQqz1u4lowFfJDaYYFTrc+oXdYt0QIga9AzGG8K1UqiHqxBhoc0zM2jfPB7EUKmW304s2VggFTyLED6SSnsSp1GtvaJxNOtRGHVWCni13P9Qkr0kwuTFiEhpsBhdscmtN7QNQjBWDfoh91Xwr8tGhISC15pvtWwTjukcf2bHFHO+TfFcmgUdNmJZSfW5vEkcHjQI4VBtxyVHJafsY2n9BYED2cbaikgjXdsfORdz3bYc4NEPBoJMbt8PX/3tbkgPxleB01YTxkCbaAdbo8hEcuLX9wD+DDCjctHUVUgCoSTcUsaKghWd0TiXbW6KVlIlzgVgUxs/n+2FgTkn5woeDvkAsPuBbNmXBzzEANmu2ZOfEg= Content-Type: multipart/alternative; boundary="_000_LNXP123MB257091D6FEE0D59AFD577BE1D3C70LNXP123MB2570GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: b1729b0b-59a7-4433-30d7-08d70fbda01e X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2019 22:32:20.5323 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Mark38706@ncsc.gov.uk X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB2250 Archived-At: Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 22:32:33 -0000 --_000_LNXP123MB257091D6FEE0D59AFD577BE1D3C70LNXP123MB2570GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Dominique, for bringing this draft to the list. It's not a complete= survey of all the threats facing users and systems on the Internet but it = does highlight some omissions from the current threat model. I attended the tutorial session on how to write security considerations on = 20 July. Something I heard Yoav say was that the IETF mostly focuses on Com= Sec issues, and as a result there's not usually any discussion in the secur= ity considerations of how to protect the host so that private information d= oesn't leak out; also that the security considerations all too often ignore= operational considerations. This reflects what I have seen in Internet dra= fts but does seem to be ignoring a class of attacks that arguably ought to = be in scope. Checking RFC 3552 to see what's actually in scope for the security consider= ations, it says (Section 2: The Goals of Security): We can loosely divide security goals into those related to protecting communications (COMMUNICATION SECURITY, also known as COMSEC) and those relating to protecting systems (ADMINISTRATIVE SECURITY or SYSTEM SECURITY). Since communications are carried out by systems and access to systems is through communications channels, these goals obviously interlock, but they can also be independently provided. So System Security and the protection of systems is apparently in scope. Se= ction 3 specifies the Internet threat model - and we can classify the attac= ks here according to whether they are Communications Security or System Sec= urity: 3.2.1 Confidentiality violation - COMSEC 3.2.2 Password sniffing - COMSEC 3.2.3 Offline cryptographic attacks - COMSEC (capturing challenge-response)= ; SYSTEM SECURITY (stealing password file) 3.3.1 Replay attacks - COMSEC 3.3.2 Message insertion - COMSEC 3.3.3 Message deletion - COMSEC 3.3.4 Message modification - COMSEC 3.3.5 Man-in-the-middle - COMSEC 3.5 On-path versus off-path - COMSEC 3.6 Link-local - COMSEC Then Section 5 describes the mandatory components of the security considera= tions: Authors MUST describe 1. which attacks are out of scope (and why!) 2. which attacks are in-scope 2.1 and the protocol is susceptible to 2.2 and the protocol protects against At least the following forms of attack MUST be considered: eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle. Potential denial of service attacks MUST be identified as well. So although System Security is recognised as a security goal, there's no sp= ecific guidance on what the threats to System Security are and no requireme= nt for them to be addressed in the security considerations section. This ma= y have contributed towards protocol design concentrating more on ComSec tha= n on other aspects of System security. The security considerations section = should at least call out the threats that result from the compromise of end= points, even if no mitigation is possible. I note that Jari Arkko's draft-arkko-arch-internet-threat-model-01 has been= updated and that this makes similar points regarding the need to address s= ecurity threats other than ComSec. I support the additions to the text of t= he draft, including this one: 7. Treat parties that your equipment connects to with suspicion, even if the communications are encrypted. The other endpoint may misuse any information or control opportunity in the communication. Similarly, even parties within your own system need to be treated with suspicision, as some nodes may become compromised. I also welcome that Stephen Farrell's draft-farrell-etm-03 recognises addit= ional categories of attacks including supply chain attacks and leaky bucket= s, as well as the kinds of breaches detailed in Dominique's draft. I do thi= nk however that Stephen's suggested change to the wording of RFC 3552: OLD: In general, we assume that the end-systems engaging in a protocol exchange have not themselves been compromised. NEW: In general, we assume that one of the protocol engines engaging in a protocol exchange has not been compromised at the run-time of the exchange. is restrictive. We use PFS to protect systems against compromises of the en= dpoint _after_ the protocol exchange has taken place. The Lazanski, Arkko and Farrell drafts could all make valuable contribution= s towards an improved Internet threat model. In response to Eric: * I'd like to try to explore this argument a bit. Specifically, it migh= t be the case that the IETF has just ignored non-comsec and that if we had spent more time on it, that would be better. Alternatively, it could be true that the IETF's focus on comsec has actively harmed other kinds of security. One gets the sense that this document wants to argue the latter point, but it doesn't really come out and say it, let alone substantiate it. That, rather than arguing about the completeness or appropriateness of RFC 3552, might be a better place to start. I agree. Research into the effects that the focus on ComSec has had on othe= r forms of security has not been brought to the IETF in a systematic way. -- Mark From: Smart On Behalf Of Eric Rescorla Sent: 14 July 2019 17:24 To: Stephen Farrell Cc: smart@irtf.org; Kathleen Moriarty ; D= ominique Lazanski ; IETF SecDispatch Subject: Re: [Smart] [Secdispatch] New Version Notification for draft-lazan= ski-smart-users-internet-00.txt I more or less agree with Stephen's position. First, I recognize that this focus on secure endpoints talking to each other is probably the part of 3552 that people are most unhappy about. As I was almost certainly the person who wrote that text, it might be helpful if I laid out some background. First, RFC 3552 isn't intended to say that endpoint threats aren't real, but merely that they are out of scope because they are hard to address. Here's the text in context: The Internet environment has a fairly well understood threat model. In general, we assume that the end-systems engaging in a protocol exchange have not themselves been compromised. Protecting against an attack when one of the end-systems has been compromised is extraordinarily difficult. It is, however, possible to design protocols which minimize the extent of the damage done under these circumstances. For a more narrow statement with a similar theme (but extended to the Web platform, see https://www.chromium.org/Home/chromium-security/secur= ity-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model- a= nd https://www.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t= -compromised-infected-machines-in-Chrome-s-threat-model-): This is essentially the same situation as with physically-local attacks. The attacker's code, when it runs as your user account on your machine, can do anything you can do. (See also Microsoft's Ten Immutable Laws Of Security.) However, RFC 3552 is primarily oriented towards what can be standardized and in particular towards protocols, and generally secure protocols require some sort of TCB to be effective. Obviously, as alluded to in 3552, to the extent to which protocols can be designed to minimize damage, and we routinely attempt to do so. Examples of this include the use of Forward Secure algorithms and trying to avoid or mitigate designs with single points of failure (as with Certificate Transparency). I know that PHB has some ideas along these lines; I haven't studied them enough to know what I think, but that sort of thing is generally in scope as well. This to some extent goes to Section 2 of draft-lazanski. I certainly agree that to the extent to which it is possible to design cryptographic solutions to prevent data breaches, it is useful to do so, and protocols for doing that would potentially be in scope for IETF. I say "potentially" because I'm not sure that (a) standards are necessary in this space beyond the kind of work we are already doing or (b) that we would have the community to define them, but I don't see an in principle barrier [0] I certainly would not expect 3552 to be deployed to preclude that kind of work. Similarly, I don't think that the kinds of botnet attacks described in Section 3 are out of scope for 3552, though I see how it could be read this way. However I think that the idea of a malicious counterparty is clearly in scope if we assume that the attacker controls the network. Here too, I wouldn't expect 3552 to be deployed to preclude that kind of work; we have done plenty of anti-DoS work in IETF (whether it is good enough is a different story). Turning now to the document itself, its language seems to be trying to stake out a very strong position, but I'm not quite sure what that position is. For instance: themselves. These assumptions have led to a focus on communications security and the development of protocols that place this kind of security above all else. Ironically - or coincidentally - as the development of these protocols have taken place over the last several decades, there has been and continues to be a sharp rise in cyber attacks. The Internet threat model in RFC 3552 does not even mention that the greatest threat to the Internet is the growing scale and variety of cyber attacks against all types of endpoints that is resulting in significant data breaches. This now needs to change. First, I'm not sure that I agree that cyber attacks on endpoints are the greatest threat to the Internet, but even assuming that's so, what are the implications of that for work in the IETF? It's one thing to change the words of 3552, but what work specifically would we do if those words were different. Second, I think it's quite likely true that the IETF has focused on communications security, and this document seems to be trying to argue that that's to the detriment of other kinds of security, both here and in other places: Internet security research and technical development must accept the reality of all the security issues in the Internet ecosystem. Decisions being made in the name of privacy are sometimes leading to larger inadvertent security and privacy losses. I'd like to try to explore this argument a bit. Specifically, it might be the case that the IETF has just ignored non-comsec and that if we had spent more time on it, that would be better. Alternatively, it could be true that the IETF's focus on comsec has actively harmed other kinds of security. One gets the sense that this document wants to argue the latter point, but it doesn't really come out and say it, let alone substantiate it. That, rather than arguing about the completeness or appropriateness of RFC 3552, might be a better place to start. -Ekr [0] Indeed, work like token binding is arguably a stab at some of this stuff. On Sun, Jul 14, 2019 at 3:26 AM Stephen Farrell = wrote: Hiya, On 14/07/2019 03:06, Kathleen Moriarty wrote: > It's a good start toward broadening > the conversation on the Internet threat model and I do agree that is > necessary. FWIW, I don't agree that this is a good start. ISTM that this draft is far too opinionated, for example claiming that "IETF attendees are privacy-focused", (how does the author know?), claiming it "unthinkable" that something isn't done, and that "Internet security research and technical development must accept the reality of all the security issues in the Internet ecosystem" (though I'm not sure I can parse that last quote at all). Towards the end we get: "Endpoints have changed over the last 10 years, but assumptions about endpoints in the IETF hasn't changed in that time" - I don't know how the author knows what assumptions may or may not be made by IETF participants (not "attendees" of course). And perhaps most oddly, this bold assertion: "Further, it is imperative that new conclusions and recommendations from a revisited threat model are backed up by research, case studies and experience - rather than bold assertions." ;-) The list of breaches and botnets is fine, but not much use without any analysis of how those happened. We need a good bit more work to figure out whether any changes to protocols or protocol design are actually warranted or useful in the face of these kinds of incident. (Hence the oddity of the bold assertion above.) Lastly, ISTM important, if any discussion here is to be worthwhile, to recognise from the start that existing IETF consensus positions in this space are not likely to be discarded - those were arrived at after a lot iterations of a lot of debate by well-informed IETF participants. (Despite what some may claim;-) So I reckon the right discussion to have is about how to extend and not discard the 3552 threat model. Any other attempted changes would seem to me to require a shift in deployments from 2-party to multi-party protocols, which is unrealistic, or to require magical trust in middleboxes, which would be plain silly and seems highly unlikely to be something for which IETF consensus would be established. > Also - is this a request to present at SecDispatch? I hope not. This draft is IMO clearly not ready for that. An initial discussion about threat models and how to approach this kind of work at saag may be worthwhile (and I think Jari has asked the sec ADs for such a slot). Cheers, S. _______________________________________________ Secdispatch mailing list Secdispatch@ietf.org https://www.ietf.org/mailman/listinfo/secdispatch This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright (c) --_000_LNXP123MB257091D6FEE0D59AFD577BE1D3C70LNXP123MB2570GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

&nbs= p;

Thanks, Dominique, fo= r bringing this draft to the list. It’s not a complete survey of all = the threats facing users and systems on the Internet but it does highlight = some omissions from the current threat model.

 

I attended the tutori= al session on how to write security considerations on 20 July. Something I = heard Yoav say was that the IETF mostly focuses on ComSec issues, and as a = result there’s not usually any discussion in the security considerations of how to protect the host so that private = information doesn’t leak out; also that the security considerations a= ll too often ignore operational considerations. This reflects what I have s= een in Internet drafts but does seem to be ignoring a class of attacks that arguably ought to be in scope.

 

Checking RFC 3552 to = see what’s actually in scope for the security considerations, it says= (Section 2: The Goals of Security):

 

   We can loosely divide securit=
y goals into those related to protecting
   communications (COMMUNICATION=
 SECURITY, also known as COMSEC) and
   those relating to protecting =
systems (ADMINISTRATIVE SECURITY or
   SYSTEM SECURITY).  Since=
 communications are carried out by systems
   and access to systems is thro=
ugh communications channels, these goals
   obviously interlock, but they=
 can also be independently provided.
 
So System Security and the protection of systems is app=
arently in scope. Section 3 specifies the Internet threat model – and=
 we can classify the attacks here according to whether they are Communicati=
ons Security or System Security:<=
/o:p>

 

3.2.1 Confidentiality= violation – COMSEC

3.2.2 Password sniffi= ng – COMSEC

3.2.3 Offline cryptog= raphic attacks – COMSEC (capturing challenge-response); SYSTEM SECURI= TY (stealing password file)

3.3.1 Replay attacks = – COMSEC

3.3.2 Message inserti= on – COMSEC

3.3.3 Message deletio= n – COMSEC

3.3.4 Message modific= ation – COMSEC

3.3.5 Man-in-the-midd= le – COMSEC

3.5 On-path versus of= f-path – COMSEC

3.6 Link-local –= ; COMSEC

 

Then Section 5 descri= bes the mandatory components of the security considerations:

 

   Authors MUST describe

 

      1.  = which attacks are out of scope (and why!)

      2.  = which attacks are in-scope=

      2.1  and = the protocol is susceptible to

      2.2  and = the protocol protects against

 

   At least the following forms of = attack MUST be considered:<= /span>

   eavesdropping, replay, message i= nsertion, deletion, modification, and<= o:p>

   man-in-the-middle.  Potenti= al denial of service attacks MUST be

   identified as well.

 

So although System Se= curity is recognised as a security goal, there’s no specific guidance= on what the threats to System Security are and no requirement for them to = be addressed in the security considerations section. This may have contributed towards protocol design concentrating m= ore on ComSec than on other aspects of System security. The security consid= erations section should at least call out the threats that result from the = compromise of endpoints, even if no mitigation is possible.

 

I note that Jari Arkk= o’s draft-arkko-arch-internet-threat-model-01 has been updated and th= at this makes similar points regarding the need to address security threats= other than ComSec. I support the additions to the text of the draft, including this one:

 

   7.  Treat parties that your= equipment connects to with suspicion,=

       even if = the communications are encrypted.  The other endpoint may

       misuse a= ny information or control opportunity in the

       communic= ation.  Similarly, even parties within your own system

       need to = be treated with suspicision, as some nodes may become

       compromi= sed.

 

I also welcome that S= tephen Farrell’s draft-farrell-etm-03 recognises additional categorie= s of attacks including supply chain attacks and leaky buckets, as well as t= he kinds of breaches detailed in Dominique’s draft. I do think however that Stephen’s suggested change to the wor= ding of RFC 3552:

 

   OLD: In general, we assume that = the end-systems engaging in a

   protocol exchange have not thems= elves been compromised.

 

   NEW:

 

   In general, we assume that one o= f the protocol engines engaging in a

   protocol exchange has not been c= ompromised at the run-time of the=

   exchange.

 

is restrictive. We us= e PFS to protect systems against compromises of the endpoint _after_= the protocol exchange has taken place.

 

The Lazanski, Arkko a= nd Farrell drafts could all make valuable contributions towards an improved= Internet threat model.

 

In response to Eric:<= o:p>

  • I'd like to try to explore this argument a bit. Specifically, it might
    be the case that the IETF has just ignored non-comsec and that if we
    had spent more time on it, that would be better. Alternatively, it
    could be true that the IETF's focus on comsec has actively harmed
    other kinds of security. One gets the sense that this document wants
    to argue the latter point, but it doesn't really come out and say it,
    let alone substantiate it. That, rather than arguing about the completeness=
    or appropriateness of RFC 3552, might be a better place to start.

 

I agree. Research int= o the effects that the focus on ComSec has had on other forms of security h= as not been brought to the IETF in a systematic way.

 

-- Mark

 

 

 

 

Fro= m: Smart <smart-= bounces@irtf.org>On Behalf Of Eric Rescorla
Sent: 14 July 2019 17:24
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: smart@irtf.org; Kathleen Moriarty <kathleen.moriarty.ietf@gma= il.com>; Dominique Lazanski <dml@lastpresslabel.com>; IETF SecDisp= atch <Secdispatch@ietf.org>
Subject: Re: [Smart] [Secdispatch] New Version Notification for draf= t-lazanski-smart-users-internet-00.txt=

 

I more or less agree = with Stephen's position.

First, I recognize that this focus on secure endpoints talking to each
other is probably the part of 3552 that people are most unhappy
about. As I was almost certainly the person who wrote that text, it might be helpful if I laid out some background.

First, RFC 3552 isn't intended to say that endpoint threats aren't
real, but merely that they are out of scope because they are hard
to address. Here's the text in context:

   The Internet environment has a fairly well understood threat m= odel.
   In general, we assume that the end-systems engaging in a proto= col
   exchange have not themselves been compromised.  Protectin= g against an
   attack when one of the end-systems has been compromised is
   extraordinarily difficult.  It is, however, possible to d= esign
   protocols which minimize the extent of the damage done under t= hese
   circumstances.

For a more narrow statement with a similar theme (but extended to
the Web platform, see https://www.chromium.org/Home/chromium-security/secur= ity-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model- a= nd
https://www.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t= -compromised-infected-machines-in-Chrome-s-threat-model-):

   This is essentially the same situation as with physically-loca= l
   attacks. The attacker's code, when it runs as your user accoun= t on
   your machine, can do anything you can do. (See also Microsoft'= s Ten
   Immutable Laws Of Security.)

However, RFC 3552 is primarily oriented towards what can be
standardized and in particular towards protocols, and generally secure
protocols require some sort of TCB to be effective. Obviously, as
alluded to in 3552, to the extent to which protocols can be designed
to minimize damage, and we routinely attempt to do so. Examples of
this include the use of Forward Secure algorithms and trying to avoid
or mitigate designs with single points of failure (as with Certificate
Transparency).  I know that PHB has some ideas along these lines; I haven't studied them enough to know what I think, but that sort of
thing is generally in scope as well.

This to some extent goes to Section 2 of draft-lazanski. I certainly
agree that to the extent to which it is possible to design
cryptographic solutions to prevent data breaches, it is useful to do
so, and protocols for doing that would potentially be in scope for
IETF. I say "potentially" because I'm not sure that (a) standards= are
necessary in this space beyond the kind of work we are already doing
or (b) that we would have the community to define them, but I don't
see an in principle barrier [0] I certainly would not expect 3552 to
be deployed to preclude that kind of work.

Similarly, I don't think that the kinds of botnet attacks described
in Section 3 are out of scope for 3552, though I see how it could
be read this way. However I think that the idea of a malicious
counterparty is clearly in scope if we assume that the attacker
controls the network. Here too, I wouldn't expect 3552 to be deployed
to preclude that kind of work; we have done plenty of anti-DoS work
in IETF (whether it is good enough is a different story).


Turning now to the document itself, its language seems to be trying
to stake out a very strong position, but I'm not quite sure what that
position is. For instance:

   themselves. These assumptions have led to a focus on communica= tions
   security and the development of protocols that place this kind= of
   security above all else. Ironically - or coincidentally - as t= he
   development of these protocols have taken place over the last<= br>    several decades, there has been and continues to be a sharp ri= se in
   cyber attacks. The Internet threat model in RFC 3552 does not = even
   mention that the greatest threat to the Internet is the growin= g
   scale and variety of cyber attacks against all types of endpoi= nts
   that is resulting in significant data breaches. This now needs= to
   change.

First, I'm not sure that I agree that cyber attacks on endpoints are
the greatest threat to the Internet, but even assuming that's so,
what are the implications of that for work in the IETF? It's one thing
to change the words of 3552, but what work specifically would we
do if those words were different.

Second, I think it's quite likely true that the IETF has focused
on communications security, and this document seems to be trying
to argue that that's to the detriment of other kinds of security,
both here and in other places:

   Internet security research and technical development must acce= pt the
   reality of all the security issues in the Internet ecosystem.<= br>    Decisions being made in the name of privacy are sometimes lead= ing to
   larger inadvertent security and privacy losses.

I'd like to try to explore this argument a bit. Specifically, it might
be the case that the IETF has just ignored non-comsec and that if we
had spent more time on it, that would be better. Alternatively, it
could be true that the IETF's focus on comsec has actively harmed
other kinds of security. One gets the sense that this document wants
to argue the latter point, but it doesn't really come out and say it,
let alone substantiate it. That, rather than arguing about the completeness=
or appropriateness of RFC 3552, might be a better place to start.

-Ekr


[0] Indeed, work like token binding is arguably a stab at some of this
stuff.

 

On Sun, Jul 14, 2019 = at 3:26 AM Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


Hiya,

On 14/07/2019 03:06, Kathleen Moriarty wrote:
> It's a good start toward broadening
> the conversation on the Internet threat model and I do agree that is > necessary.

FWIW, I don't agree that this is a good start.

ISTM that this draft is far too opinionated, for example
claiming that "IETF attendees are privacy-focused", (how
does the author know?), claiming it "unthinkable" that
something isn't done, and that "Internet security research
and technical development must accept the reality of all
the security issues in the Internet ecosystem" (though
I'm not sure I can parse that last quote at all).

Towards the end we get: "Endpoints have changed over the
last 10 years, but assumptions about endpoints in the IETF
hasn't changed in that time" - I don't know how the
author knows what assumptions may or may not be made
by IETF participants (not "attendees" of course).

And perhaps most oddly, this bold assertion: "Further, it
is imperative that new conclusions and recommendations
from a revisited threat model are backed up by research, case
studies and experience - rather than bold assertions." ;-)

The list of breaches and botnets is fine, but not much
use without any analysis of how those happened. We need a
good bit more work to figure out whether any changes to
protocols or protocol design are actually warranted or
useful in the face of these kinds of incident. (Hence
the oddity of the bold assertion above.)

Lastly, ISTM important, if any discussion here is to
be worthwhile, to recognise from the start that existing
IETF consensus positions in this space are not likely to
be discarded - those were arrived at after a lot iterations
of a lot of debate by well-informed IETF participants.
(Despite what some may claim;-) So I reckon the right
discussion to have is about how to extend and not discard
the 3552 threat model. Any other attempted changes would
seem to me to require a shift in deployments from 2-party
to multi-party protocols, which is unrealistic, or to
require magical trust in middleboxes, which would be plain
silly and seems highly unlikely to be something for which
IETF consensus would be established.

> Also - is this a request to present at SecDispatch?

I hope not. This draft is IMO clearly not ready for that.
An initial discussion about threat models and how to
approach this kind of work at saag may be worthwhile (and
I think Jari has asked the sec ADs for such a slot).

Cheers,
S.
_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch

 

This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright ©= ; --_000_LNXP123MB257091D6FEE0D59AFD577BE1D3C70LNXP123MB2570GBRP_--