From nobody Fri Jan 15 09:21:33 2021 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCA53A0E80; Fri, 15 Jan 2021 09:21:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: hipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: hipsec@ietf.org Message-ID: <161073128706.32631.3273156262439422867@ietfa.amsl.com> Date: Fri, 15 Jan 2021 09:21:27 -0800 Archived-At: Subject: [Hipsec] I-D Action: draft-ietf-hip-dex-23.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 17:21:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol WG of the IETF. Title : HIP Diet EXchange (DEX) Authors : Robert Moskowitz Rene Hummen Miika Komu Filename : draft-ietf-hip-dex-23.txt Pages : 64 Date : 2021-01-15 Abstract: This document specifies the Host Identity Protocol Diet EXchange (HIP DEX), a variant of the Host Identity Protocol Version 2 (HIPv2) and specifically developed for use on low end processors. The HIP DEX protocol design aims at reducing the overhead of the employed cryptographic primitives by omitting public-key signatures and cryptographic hash functions. The HIP DEX protocol is primarily designed for computation or memory- constrained sensor/actuator devices. Like HIPv2, it is expected to be used together with a suitable security protocol such as the Encapsulated Security Payload (ESP) for the protection of upper layer protocol data. Unlike HIPv2, HIP DEX does not support Forward Secrecy (FS), and MUST only be used on devices where FS is prohibitively expensive. In addition, HIP DEX can also be used as a keying mechanism for security primitives at the MAC layer, e.g., for IEEE 802.15.4 networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-hip-dex-23.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 15 10:32:51 2021 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2871B3A0FC9 for ; Fri, 15 Jan 2021 10:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RabpNd3Ga7bA for ; Fri, 15 Jan 2021 10:32:45 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 870B43A107F for ; Fri, 15 Jan 2021 10:32:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 8B04162745 for ; Fri, 15 Jan 2021 13:32:43 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JLrpWwDXmW1V for ; Fri, 15 Jan 2021 13:32:38 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 52FAC626FC for ; Fri, 15 Jan 2021 13:32:38 -0500 (EST) To: hipsec@ietf.org References: <161073128706.32631.3273156262439422867@ietfa.amsl.com> From: Robert Moskowitz Message-ID: Date: Fri, 15 Jan 2021 13:32:32 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <161073128706.32631.3273156262439422867@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-dex-23.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 18:32:50 -0000 I added some more performance information thanks to some digging by Miika and Mohit. Also some more on FOLD thanks to work by Adam Wiethuechter. Please take a look.  I am in one conversation about DEX.  Don't know where it is going to go, but you never know... On 1/15/21 12:21 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Host Identity Protocol WG of the IETF. > > Title : HIP Diet EXchange (DEX) > Authors : Robert Moskowitz > Rene Hummen > Miika Komu > Filename : draft-ietf-hip-dex-23.txt > Pages : 64 > Date : 2021-01-15 > > Abstract: > This document specifies the Host Identity Protocol Diet EXchange (HIP > DEX), a variant of the Host Identity Protocol Version 2 (HIPv2) and > specifically developed for use on low end processors. The HIP DEX > protocol design aims at reducing the overhead of the employed > cryptographic primitives by omitting public-key signatures and > cryptographic hash functions. > > The HIP DEX protocol is primarily designed for computation or memory- > constrained sensor/actuator devices. Like HIPv2, it is expected to > be used together with a suitable security protocol such as the > Encapsulated Security Payload (ESP) for the protection of upper layer > protocol data. Unlike HIPv2, HIP DEX does not support Forward > Secrecy (FS), and MUST only be used on devices where FS is > prohibitively expensive. In addition, HIP DEX can also be used as a > keying mechanism for security primitives at the MAC layer, e.g., for > IEEE 802.15.4 networks. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-hip-dex-23.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From nobody Tue Jan 19 12:24:36 2021 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8283A111A; Tue, 12 Jan 2021 03:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.618 X-Spam-Level: X-Spam-Status: No, score=-9.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=lcAnlk0V; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dI27iGH2 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 qlVStq6U36-N; Tue, 12 Jan 2021 03:19:27 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415CA3A1116; Tue, 12 Jan 2021 03:19:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15983; q=dns/txt; s=iport; t=1610450367; x=1611659967; h=from:to:cc:subject:date:message-id:mime-version; bh=zYgZZZ4QK4IJKHEqXoI4Si7fSQH2Q/UArCQwRfjrCxg=; b=lcAnlk0VLYcnTy5G3qOdZO9Yz9AmxTwwhYc8wfOEXRcYDxCTtiDDotTK V5osOG7smonG2Kt/gaX96JppIV1kxGPyuI27z0FupQSxv9q+y7yjrMAhb Yi/eRdte04tfx80LG6aLovYllyn30NQZfBTGgf6DNUX2VnaelmJ4FVm2I 8=; X-IPAS-Result: =?us-ascii?q?A0AaCAAYhf1f/4kNJK1GHB0BAQEBCQESAQUFAYIPgSMwK?= =?us-ascii?q?SgHdlsvLoQ/g0gDjXUDihyKA4RzgUKBEQNUCwEBAQ0BASMKAgQBAYRKGYFaA?= =?us-ascii?q?iU4EwIDAQEBAwIDAQEBAQUBAQECAQYEcYVhDIVzAQYjHQEBNwERAQgRAwECK?= =?us-ascii?q?wIEHxEdCgQBDQWDJgGBflcDLgEOQKMYAooldoEygwQBAQaBR0GDFQ0LghADB?= =?us-ascii?q?oE4gnWDfQGGPiYbgUE/gREnHIJWPoEEAYEWQgICAQEVgQwFARIBQQ2CazSCL?= =?us-ascii?q?IJIFRE6AQNTIAINgSw4FgdAj1OCWwE/hzGdGFgKgneJK40XhR0DH6JgJJNui?= =?us-ascii?q?xaCeI59AYQ0AgQCBAUCDgEBBoFtIxJVcHAVZQGCCgEzUBcCDVeNSgwMCxRuA?= =?us-ascii?q?QGCSoUUhUR0AjUCBgEJAQEDCXyMXwEB?= IronPort-PHdr: =?us-ascii?q?9a23=3A+eQpnBQHXuQwnjt70YGZIS3e5tpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQB9mJ5/dNkeGQsq38VyoH+5nS+HwBcZkZUR?= =?us-ascii?q?gDhI1WmgE7G8eKBAX9K+KidC01GslOFToHt3G2OERYAoDyMlvVpHDh4TsbAB?= =?us-ascii?q?65NAdpKKLyAIGBx8iy3vq5rpvUZQgAjTGhYLR0eROxqwiZtsQfjYZ4bKgrzR?= =?us-ascii?q?6cqXpTcOMQzmRtdl8=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,341,1602547200"; d="scan'208,217";a="623986085" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Jan 2021 11:19:26 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 10CBJQB5009338 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Jan 2021 11:19:26 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 12 Jan 2021 05:19:25 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 12 Jan 2021 06:19:24 -0500 Received: from NAM12-DM6-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.1497.2 via Frontend Transport; Tue, 12 Jan 2021 05:19:24 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gG7cVkJsYWNL7TZy39xZ3NgLiSIsUSorOVELOk9QL04PBGxo2a47lCUsno+JiFjWaSA8IU+0rW/vqHdvW2uav8fGexQa3g20+JSoJ5+WiiRKtY0CJ3S7cbcaKhCd99HjVaBOnCOtkhLSXKctcj5IA+7yTAhXk+6IKpyI/ClaImQRDV3rAZAfYRHNEhr4pp98riCNcTtDQI245jtso0t7EPVYEotc/kzJnJ1X8f5GlzUn6pvtM5LGQ23xa0ItlrV4usLdYTm8pfZUl1P1Mq1hd4RtnpdkH9jCcJAnP3xV6dZo3OottFGV0FhfU2eDMjJfoQ3ScKpR/l0urf7tAJ7XtQ== 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=zYgZZZ4QK4IJKHEqXoI4Si7fSQH2Q/UArCQwRfjrCxg=; b=ezMB5RqRm3/qheyegTh3Uu9xCfcSeBlMk2Dui6Y8VM33EqwpDIUncBFu3Ftwi0G/lHfz1yggtQPiY4i170uDoVP6D5mUQ5aeWyzdEbZFGtV/fGxQ+bGAGNJMhU2N6LxcL1/oW+OUmu+rAT3xw0DAvhCGpRaXQw/3t8ZXPzPmEKi7MW1/L+7m87IJL5KuuKtM+ZAmudCyyXTkC1KVumx2Wu+vOkGVtHlNMGlk+7qKZ4heoMeasBHg2lzxHBNyzRdG7R2q4ixiIh1e6mHf5U3Itp/1ZuE/Q0tuyIzZVXSZ8dNEs8uIbZqhd7cRr1bWTpgEtB1bCVk0GFTGYQnp/csGkw== 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=zYgZZZ4QK4IJKHEqXoI4Si7fSQH2Q/UArCQwRfjrCxg=; b=dI27iGH2KFJEQJGU4O0ASxo0iSMzmHctBSXfthn+cKWPiPb4hFU/fCLn3zK4TBoeBzAlNe2mKdLcaNqH30uw84rk2U9Z46DJWE/+gIuXG/4NrOqRddrXPGc37IglLi7t4laq9e9IOAN9t+fGZFvjyGhXgc1fiE3/QIdEH16mupc= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5062.namprd11.prod.outlook.com (2603:10b6:510:3e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Tue, 12 Jan 2021 11:19:23 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b%3]) with mapi id 15.20.3742.012; Tue, 12 Jan 2021 11:19:23 +0000 From: "Eric Vyncke (evyncke)" To: "Eric Vyncke (evyncke)" , "hipsec@ietf.org" , "draft-ietf-hip-dex@ietf.org" , Robert Moskowitz , Miika Komu CC: Roman Danyliw , Eric Rescorla , "Gonzalo Camarillo" , "rene.hummen@belden.com" , Benjamin Kaduk , Erik Kline Thread-Topic: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13... Thread-Index: AQHW6NTHTbdGMBvqzUu6+PzV6Jo22w== Date: Tue, 12 Jan 2021 11:19:23 +0000 Message-ID: <68AF0368-8CB8-4DF3-A33E-0AA28E61B5F5@cisco.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.44.20121301 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:d478:1721:a34a:e1b1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 88d65967-dfde-4a9f-ce52-08d8b6ebea2e x-ms-traffictypediagnostic: PH0PR11MB5062: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PMjKzO67zaXJwicUs7pq950ZEjZUyd9yqtBqIC+ySUdNTdCHP/RSPDqZ8NT1tBjSCLkwWm7T4bV5KXV05hC2rydcO63IU1vEpvjnRqymV1HDnRrelCmhPPhkprm8kY/AeqsEoyL7qvkilLqR8JpIDZK9fH5y2RVUIwHoxqNOcI0Q0i1LzL4hDNc0mWo//FHAaRXPEoPI9X3sYRfTYIPdp3c+merCWYDmnRutjiGAyqF+n+uy9IVZJLgB45YjzdavUgQovB0lMX9oMhkOEzLnqLxqmSfjZi5+IvpXFP54h7zWri4grFhsX5DVSEOUYogM4p2etPH2lPPqNZcMyH8YzqF5w3KsLwqnjea1Q7HK9QRxZzy6iTvFRy6xJEmSj4mb9MxuT70Z/3QFWZMFVZ6EB2VR7uTRCwipCP/j5tZOOalZ2qsNigwqfO41V66RawmeyJnD47mU1liqGbPK4N3UIv+Y7uUSJrf7iMOEANxKQCqG/zYAWl478wpQpB499Ndg+GBW1dzlYN0uhad8pBo8Nw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(396003)(376002)(346002)(366004)(6506007)(16799955002)(6486002)(478600001)(71200400001)(83380400001)(86362001)(8676002)(8936002)(66476007)(36756003)(2906002)(66556008)(4326008)(91956017)(316002)(76116006)(54906003)(33656002)(53546011)(64756008)(166002)(110136005)(5660300002)(66446008)(186003)(7416002)(6512007)(966005)(2616005)(66946007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?SG8zMGVXWWJjSXRsTGlVYWhwVTJMUmhEaUpmK2lVUFhSWjZQNTlQd3RPc1dM?= =?utf-8?B?THpGZW11NTRIREllQVVvSUl4eUlnaWYxcFF4OVlzWHU3WlptaXdqdU9mR2FO?= =?utf-8?B?TURLV1lCcGkySEtJaHVLZmE3VFNTNjdmc3RxMjVjcmZ2QjZYU3VlbEdsY0dW?= =?utf-8?B?OFIwRFhJUkVYWnFteWJobGpxa2FuOEpuY3pmbTVsV3I4R2I1dDlxaTdUNThk?= =?utf-8?B?b2ErR0puNmxOZnVWL3M5bSsyVWg3Z1YrL2I3Ym9UWENJN0RKcldTZHgwSXJW?= =?utf-8?B?U2RjU2pvYk1KQTBGd05PSVhhelZFRWFpVUNVSS9qaWdDTEhITlViRTUwdndn?= =?utf-8?B?ajEwVDIxbFFTSGFWdEx3QWgzemFEZm1LNVRLc0IzTEVBZU9CSWRmYmRSaEdl?= =?utf-8?B?QVNYMVhleGZxNWxtUlMvOVJ5WGNpaGhVMnZGMUlhK1N4eDFna1l6SXBqNHln?= =?utf-8?B?MUFldEVoQzlyeVBocERTOUNlWlFBN3ROOFliMDNNWjZQblVrZ2NRSStkOXhJ?= =?utf-8?B?OGVsN3dGaCtWY0Z6VmxEaVlDbWFJbVFacVlmbXl0L3F4RnVpcERNRVpzaTRw?= =?utf-8?B?OUtDZHFqV2JzOGZQTGNmOG56eWwwRk5MSGJOZmdZODRWTXRQUlVvTGFwUERi?= =?utf-8?B?YW5YSG4rSUFMcEdKUFk3Y203NkVmbWs4V1VXeUJ0WFpUMkZtek1BbENSSkRX?= =?utf-8?B?U2FSVTIvd2puaEhaSUxyZU14L2ZEdGlIQnRXdENSN3ZKTGRoT3dTSHVibVJH?= =?utf-8?B?N0hlMTBKU1VZMHlySVNTaFdMTGM0TWw2anZRak5OV3pBd0xuMkFvY1E1a2hq?= =?utf-8?B?L0hWSnB4NkQ1NVZ5U1gvWEFsT2NYL052VHVGdS9XcnVYU0xJUDNnYmU0alYw?= =?utf-8?B?N3RnQ0U2bERxTERFWVNzTGpITzZxL1N0czBGQU92N05Xb3orLzJ0VFl5WkFH?= =?utf-8?B?MGtHWXBHTlNqMTFLOG1XWTFkUXdIOHd2MDk4a0VOZzkxY2NlNWZBUFRqNzhM?= =?utf-8?B?VmNKbnp2LzN4cEFjTHFJTjFHbXRoVHRmYVR1QXA4cEVuckdxWDNaYjF5ODRI?= =?utf-8?B?M1cwN2oyZXBzV0psaHk4MmxsNVp1ZlZVbm1vQXd0eC82UW02OWNXRVh0UmxZ?= =?utf-8?B?OXZVWHFlOVVvVU9Ja3hQUWM0bC9nR3pLQkZVdjI0dlZ2Y2pKTGd4N2F3Z3Bt?= =?utf-8?B?SGIrTWxBUG5VZTMrTGt2Ynh1THBpdmh6OHJFUDlBeXZmSVlvU0NPb1JoZi9J?= =?utf-8?B?Tjd5UkNUS21PcEg0NkZ2QnNlNnRsUzlyNEE2TE85MmlrY3RzcW9STGZuRGNJ?= =?utf-8?B?RW9Ob3N3K000RForQm5qOThPK2Z0amMvS1BiSXpLZERXdHZwckdtRko4SmVs?= =?utf-8?B?WUZrRjZJcHo0YW1WYW5ONjdiaGVrcVdyM1IwUGd1N0k3WkRBUkRKSXpLcTJn?= =?utf-8?Q?hdX+8MmJ?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_68AF03688CB84DF3A33E0AA28E61B5F5ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 88d65967-dfde-4a9f-ce52-08d8b6ebea2e X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2021 11:19:23.4076 (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: Jt8NluR/LkUZj13suDpPenovFRAAGY3Klv0E5uMTzgHYMjhanJo6ytB5dz1hahn+rztdqCyq7GtVGzUZITnO6w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5062 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: X-Mailman-Approved-At: Tue, 19 Jan 2021 12:24:34 -0800 Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13... X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 11:19:31 -0000 --_000_68AF03688CB84DF3A33E0AA28E61B5F5ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VHdvIG1vbnRocyBhZnRlciB0aGUgZW1haWwgYmVsb3csIEkgc2VuZGluZyBhIGtpbmQgcmVtaW5k ZXIgdG8gYXV0aG9ycyBhbmQgV0cuDQoNCldpdGggdGhlIC0yMiwgYSBsb3Qgb2YgKGlmIG5vdCBh bGwgKSBTRUMgQURz4oCZIERJU0NVU1MgcG9pbnRzIHNob3VsZCBoYXZlIGJlZW4gYWRkcmVzc2Vk Lg0KDQpBcyBmYXIgYXMgSSBjYW4gdGVsbCwgdGhlIG90aGVyIHJlbWFpbmluZyBpc3N1ZSB3YXMg RWty4oCZcyBvbmUgYWJvdXQgd2h5IGZvcmZlaXRpbmcgRlMgd2hlbiBzb21lIGFsZ29yaXRobSBj b3VsZCBkbyBpdCBpbiBhIHJlYXNvbmFibGUgdGltZS4gSW4gYW4gZW1haWwgdG8gYXV0aG9ycyBh bmQgQURzLCBFcmljIFIuIHdyb3RlIOKAnGl0IGRlZmluZXMgYSBzZXQgb2YgcGFyYW1ldGVycyAo dGhlIE5JU1QgY3VydmVzKSB3aGljaCBhcmUgc2xvd2VyIHcvbyBGUyB0aGFuIG90aGVyIHBhcmFt ZXRlcnMgKFgyNTUxOSkgYXJlIHcvIEZTLiBUaGlzIGZhY3QgY2FsbHMgaW50byBxdWVzdGlvbiB0 aGUgbmVlZCB0byBkaXNwZW5zZSB3aXRoIEZTLuKAnQ0KDQpXaGlsZSAyIG1vbnRocyBhZ28gSSBw dXQgYSBkZWFkbGluZSBmb3IgdG9tb3Jyb3csIEkgKGFzIHRoZSByZXNwb25zaWJsZSBBRCkgYW0g ZmxleGlibGUgb2YgY291cnNlIGJ1dCB3ZSBjYW5ub3QgbGluZ2VyIGFueW1vcmUuIEkga25vdyB0 aGF0IGEgLTIzIGlzIGluIHRoZSB3b3JrIGZvciB3ZWVrcyA9PiBsZXTigJlzIHB1Ymxpc2ggaXQg aW4gdGhlIGNvbWluZyBkYXlzLg0KDQpFbHNlLCBuZXh0IHdlZWsgd2Ugd2lsbCBuZWVkIHRvIGVp dGhlciBjaGFuZ2UgdGhlIGludGVuZGVkIHN0YXR1cyB0byBleHBlcmltZW50YWwgb3IgZGVjbGFy ZSB0aGUgZG9jdW1lbnQgZGVhZCBieSBsYWNrIG9mIGVuZXJneS4gVGhlIGxhdHRlciBkb2VzIG5v dCBoYXZlIG15IHByZWZlcmVuY2Ugb2J2aW91c2x5Lg0KDQpSZWdhcmRzDQoNCi3DqXJpYw0KDQoN CkZyb206IEhpcHNlYyA8aGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiAiRXJp YyBWeW5ja2UgKGV2eW5ja2UpIiA8ZXZ5bmNrZT00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4N CkRhdGU6IEZyaWRheSwgMTMgTm92ZW1iZXIgMjAyMCBhdCAxNTozMg0KVG86ICJoaXBzZWNAaWV0 Zi5vcmciIDxoaXBzZWNAaWV0Zi5vcmc+LCAiZHJhZnQtaWV0Zi1oaXAtZGV4QGlldGYub3JnIiA8 ZHJhZnQtaWV0Zi1oaXAtZGV4QGlldGYub3JnPiwgUm9iZXJ0IE1vc2tvd2l0eiA8cmdtQGxhYnMu aHR0LWNvbnN1bHQuY29tPiwgTWlpa2EgS29tdSA8bWlpa2Eua29tdUBlcmljc3Nvbi5jb20+DQpD YzogUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPiwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0u Y29tPiwgR29uemFsbyBDYW1hcmlsbG8gPGdvbnphbG8uY2FtYXJpbGxvQGVyaWNzc29uLmNvbT4s ICJyZW5lLmh1bW1lbkBiZWxkZW4uY29tIiA8cmVuZS5odW1tZW5AYmVsZGVuLmNvbT4sIEJlbmph bWluIEthZHVrIDxrYWR1a0BtaXQuZWR1PiwgRXJpayBLbGluZSA8ZWsuaWV0ZkBnbWFpbC5jb20+ DQpTdWJqZWN0OiBbSGlwc2VjXSBOZWVkIHRvIGNsb3NlIGFsbCBkcmFmdC1pZXRmLWhpcC1kZXgt MjEgcGVuZGluZyBpc3N1ZXMuLi4gYmVmb3JlIDIwMjEtSmFuLTEzLi4uDQoNCkRlYXIgSElQLCBk ZWFyIGF1dGhvcnMsDQoNClRoaXMgZG9jdW1lbnQgd2FzIHJlcXVlc3RlZCBmb3IgcHVibGljYXRp b24gWzFdIGluIEZlYnJ1YXJ5IDIwMTggKDIuNSB5ZWFycyBhZ28pLCB0aGVuIGl0cyBJRVNHIGV2 YWx1YXRpb24gaGFzIGJlZW4gZGVmZXJyZWQsIHRoZW4gSSB0b29rIG92ZXIgdGhpcyBkb2N1bWVu dCBmcm9tIFRlcnJ5IE1hbmRlcnNvbiBpbiBNYXJjaCAyMDE5LCB0aGVuIGl0IHdlbnQgYWdhaW4g dGhyb3VnaCBJRVNHIGV2YWx1YXRpb24gaW4gSnVseSAyMDIwIGFuZCB0aGVyZSBhcmUgc3RpbGwg RElTQ1VTUyBwb2ludHMgdG8gYmUgYWRkcmVzc2VkIGV2ZW4gYWZ0ZXIgYSBjb3VwbGUgb2YgcmV2 aXNlZCBJLUQuLi4NCg0KRGlmZmljdWx0IG5vdCB0byBvYnNlcnZlIHRoYXQgdGhpcyBkb2N1bWVu dCBkb2VzIG5vdCBwcm9ncmVzcyB2ZXJ5IGZhc3QuDQoNCk1vcmVvdmVyLCB0aGlzIGRvY3VtZW50 IGlzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSBmb3IgcmZjNDQyMy1iaXMgd2FpdGluZyBpbiB0aGUg UkZDIGVkaXRvciBxdWV1ZSBzaW5jZSBNYXJjaCAyMDE5Li4uIFNvLCBhbHNvIGJsb2NraW5nIHRo ZSBISVAtTkFUIGRvY3VtZW50IFsyXS4NCg0KQWZ0ZXIgZGlzY3Vzc2lvbiB3aXRoIHRoZSBISVAg Y2hhaXIsIEdvbnphbG8gaW4gY2MsIHdlIGhhdmUgdGFrZW4gdGhlIGZvbGxvd2luZyBkZWNpc2lv bjogaWYgYSByZXZpc2VkIEktRCBhZGRyZXNzaW5nIHJlbWFpbmluZyBESVNDVVNTIHBvaW50cyAr IEVrcuKAmXMgb25lcyBpcyBub3QgdXBsb2FkZWQgd2l0aGluIDIgbW9udGhzICgxM3RoIG9mIEph bnVhcnkgMjAyMSksIHRoZW4gSSB3aWxsIHJlcXVlc3QgdGhlIEhJUCBXRyB0byBhY2NlcHQgdGhl IGNvbXBsZXRlIHJlbW92YWwgb2Ygc2VjdGlvbiBBLjMuMyBvZiB0aGUgcmZjNDQyMy1iaXMgZG9j dW1lbnQgKDEgcGFnZSBhYm91dCBISVAtREVYIGluIHRoZSBhcHBlbmRpeCkgKyB0aGUgcmVmZXJl bmNlIHRvIHRoZSBISVAtREVYIGRvY3VtZW50IFszXS4gVGhpcyB3aWxsIGFsbG93IHRoZSBpbW1l ZGlhdGUgcHVibGljYXRpb24gb2YgdGhlIHJmYzQ0MjMtYmlzIGFuZCBISVAtTkFUIGRvY3VtZW50 cy4NCg0KVGhlIEhJUCBERVggYXV0aG9ycyBtYXkgYWxzbyBzZWxlY3QgdG8gY2hhbmdlIHRoZSBp bnRlbmRlZCBzdGF0dXMgb2YgdGhlIGRvY3VtZW50IHRvIOKAmGV4cGVyaW1lbnRhbOKAmSAoaWYg dGhlIEhJUCBXRyBhZ3JlZXMpIGFzIHRoaXMgbWF5IHJlZHVjZSB0aGUgc2VjdXJpdHkgcmVxdWly ZW1lbnRzIGJ5IHRoZSBTRUMgQUQgYW5kIEVrci4NCg0KR29uemFsbyBhbmQgSSBhcmUgc3RpbGwg aG9waW5nIHRvIGdldCBhIHJldmlzZWQgSElQLURFWCBzaG9ydGx5LA0KDQpSZWdhcmRzDQoNCi3D qXJpYw0KDQpbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1o aXAtZGV4L2hpc3RvcnkvDQpbMl0gaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvY2x1c3Rlcl9p bmZvLnBocD9jaWQ9QzM4Ng0KWzNdIGFuZCBwb3NzaWJseSBJIHdpbGwgc2V0IHRoZSBzdGF0ZSBv ZiBISVAtREVYIGFzIOKAmGRlYWTigJkgb24gdGhlIGRhdGF0cmFja2VyDQoNCg== --_000_68AF03688CB84DF3A33E0AA28E61B5F5ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJlbi1CRSIgbGluaz0iIzA1NjNDMSIgdmxpbms9 InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VHdvIG1v bnRocyBhZnRlciB0aGUgZW1haWwgYmVsb3csIEkgc2VuZGluZyBhIGtpbmQgcmVtaW5kZXIgdG8g YXV0aG9ycyBhbmQgV0cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XaXRoIHRoZSAtMjIsIGEgbG90IG9m IChpZiBub3QgYWxsICkgU0VDIEFEc+KAmSBESVNDVVNTIHBvaW50cyBzaG91bGQgaGF2ZSBiZWVu IGFkZHJlc3NlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIGZhciBhcyBJIGNhbiB0ZWxsLCB0aGUg b3RoZXIgcmVtYWluaW5nIGlzc3VlIHdhcyBFa3LigJlzIG9uZSBhYm91dCB3aHkgZm9yZmVpdGlu ZyBGUyB3aGVuIHNvbWUgYWxnb3JpdGhtIGNvdWxkIGRvIGl0IGluIGEgcmVhc29uYWJsZSB0aW1l LiBJbiBhbiBlbWFpbCB0byBhdXRob3JzIGFuZCBBRHMsIEVyaWMgUi4gd3JvdGUg4oCcaXQgZGVm aW5lcyBhIHNldCBvZiBwYXJhbWV0ZXJzDQogKHRoZSBOSVNUIGN1cnZlcykgd2hpY2ggYXJlIHNs b3dlciB3L28gRlMgdGhhbiBvdGhlciBwYXJhbWV0ZXJzIChYMjU1MTkpIGFyZSB3LyBGUy4gVGhp cyBmYWN0IGNhbGxzIGludG8gcXVlc3Rpb24gdGhlIG5lZWQgdG8gZGlzcGVuc2Ugd2l0aCBGUy7i gJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPldoaWxlIDIgbW9udGhzIGFnbyBJIHB1dCBhIGRlYWRsaW5l IGZvciB0b21vcnJvdywgSSAoYXMgdGhlIHJlc3BvbnNpYmxlIEFEKSBhbSBmbGV4aWJsZSBvZiBj b3Vyc2UgYnV0IHdlIGNhbm5vdCBsaW5nZXIgYW55bW9yZS4gSSBrbm93IHRoYXQgYSAtMjMgaXMg aW4gdGhlIHdvcmsgZm9yIHdlZWtzID0mZ3Q7IGxldOKAmXMgcHVibGlzaCBpdCBpbiB0aGUgY29t aW5nIGRheXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5FbHNlLCBuZXh0IHdlZWsgd2Ugd2lsbCBuZWVk IHRvIGVpdGhlciBjaGFuZ2UgdGhlIGludGVuZGVkIHN0YXR1cyB0byBleHBlcmltZW50YWwgb3Ig ZGVjbGFyZSB0aGUgZG9jdW1lbnQgZGVhZCBieSBsYWNrIG9mIGVuZXJneS4gVGhlIGxhdHRlciBk b2VzIG5vdCBoYXZlIG15IHByZWZlcmVuY2Ugb2J2aW91c2x5LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LcOpcmljPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+SGlwc2VjICZsdDtoaXBzZWMtYm91bmNlc0BpZXRmLm9yZyZndDsg b24gYmVoYWxmIG9mICZxdW90O0VyaWMgVnluY2tlIChldnluY2tlKSZxdW90OyAmbHQ7ZXZ5bmNr ZT00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5 LCAxMyBOb3ZlbWJlciAyMDIwIGF0IDE1OjMyPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtoaXBzZWNA aWV0Zi5vcmcmcXVvdDsgJmx0O2hpcHNlY0BpZXRmLm9yZyZndDssICZxdW90O2RyYWZ0LWlldGYt aGlwLWRleEBpZXRmLm9yZyZxdW90OyAmbHQ7ZHJhZnQtaWV0Zi1oaXAtZGV4QGlldGYub3JnJmd0 OywgUm9iZXJ0IE1vc2tvd2l0eiAmbHQ7cmdtQGxhYnMuaHR0LWNvbnN1bHQuY29tJmd0OywgTWlp a2EgS29tdSAmbHQ7bWlpa2Eua29tdUBlcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5S b21hbiBEYW55bGl3ICZsdDtyZGRAY2VydC5vcmcmZ3Q7LCBFcmljIFJlc2NvcmxhICZsdDtla3JA cnRmbS5jb20mZ3Q7LCBHb256YWxvIENhbWFyaWxsbyAmbHQ7Z29uemFsby5jYW1hcmlsbG9AZXJp Y3Nzb24uY29tJmd0OywgJnF1b3Q7cmVuZS5odW1tZW5AYmVsZGVuLmNvbSZxdW90OyAmbHQ7cmVu ZS5odW1tZW5AYmVsZGVuLmNvbSZndDssIEJlbmphbWluIEthZHVrICZsdDtrYWR1a0BtaXQuZWR1 Jmd0OywgRXJpayBLbGluZSAmbHQ7ZWsuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVj dDogPC9iPltIaXBzZWNdIE5lZWQgdG8gY2xvc2UgYWxsIGRyYWZ0LWlldGYtaGlwLWRleC0yMSBw ZW5kaW5nIGlzc3Vlcy4uLiBiZWZvcmUgMjAyMS1KYW4tMTMuLi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRlYXIg SElQLCBkZWFyIGF1dGhvcnMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+VGhpcyBkb2N1bWVudCB3YXMgcmVxdWVzdGVkIGZvciBwdWJsaWNhdGlvbiBbMV0g aW4gRmVicnVhcnkgMjAxOCAoMi41IHllYXJzIGFnbyksIHRoZW4gaXRzIElFU0cgZXZhbHVhdGlv biBoYXMgYmVlbiBkZWZlcnJlZCwgdGhlbiBJIHRvb2sgb3ZlciB0aGlzIGRvY3VtZW50IGZyb20g VGVycnkgTWFuZGVyc29uIGluIE1hcmNoIDIwMTksDQogdGhlbiBpdCB3ZW50IGFnYWluIHRocm91 Z2ggSUVTRyBldmFsdWF0aW9uIGluIEp1bHkgMjAyMCBhbmQgdGhlcmUgYXJlIHN0aWxsIERJU0NV U1MgcG9pbnRzIHRvIGJlIGFkZHJlc3NlZCBldmVuIGFmdGVyIGEgY291cGxlIG9mIHJldmlzZWQg SS1ELi4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5EaWZmaWN1bHQgbm90IHRvIG9ic2VydmUgdGhhdCB0aGlz IGRvY3VtZW50IGRvZXMgbm90IHByb2dyZXNzIHZlcnkgZmFzdC48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPk1v cmVvdmVyLCB0aGlzIGRvY3VtZW50IGlzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSBmb3IgcmZjNDQy My1iaXMgd2FpdGluZyBpbiB0aGUgUkZDIGVkaXRvciBxdWV1ZSBzaW5jZSBNYXJjaCAyMDE5Li4u IFNvLCBhbHNvIGJsb2NraW5nIHRoZSBISVAtTkFUIGRvY3VtZW50IFsyXS48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPkFmdGVyIGRpc2N1c3Npb24gd2l0aCB0aGUgSElQIGNoYWlyLCBHb256YWxvIGluIGNjLCB3 ZSBoYXZlIHRha2VuIHRoZSBmb2xsb3dpbmcgZGVjaXNpb246IGlmIGEgcmV2aXNlZCBJLUQgYWRk cmVzc2luZyByZW1haW5pbmcgRElTQ1VTUyBwb2ludHMgKyBFa3LigJlzIG9uZXMgaXMgbm90IHVw bG9hZGVkIHdpdGhpbiAyIG1vbnRocyAoMTM8c3VwPnRoPC9zdXA+DQogb2YgSmFudWFyeSAyMDIx KSwgdGhlbiBJIHdpbGwgcmVxdWVzdCB0aGUgSElQIFdHIHRvIGFjY2VwdCB0aGUgY29tcGxldGUg cmVtb3ZhbCBvZiBzZWN0aW9uIEEuMy4zIG9mIHRoZSByZmM0NDIzLWJpcyBkb2N1bWVudCAoMSBw YWdlIGFib3V0IEhJUC1ERVggaW4gdGhlIGFwcGVuZGl4KSArIHRoZSByZWZlcmVuY2UgdG8gdGhl IEhJUC1ERVggZG9jdW1lbnQgWzNdLiBUaGlzIHdpbGwgYWxsb3cgdGhlIGltbWVkaWF0ZSBwdWJs aWNhdGlvbiBvZiB0aGUNCiByZmM0NDIzLWJpcyBhbmQgSElQLU5BVCBkb2N1bWVudHMuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGUgSElQIERFWCBhdXRob3JzIG1heSBhbHNvIHNlbGVjdCB0byBjaGFuZ2Ug dGhlIGludGVuZGVkIHN0YXR1cyBvZiB0aGUgZG9jdW1lbnQgdG8g4oCYZXhwZXJpbWVudGFs4oCZ IChpZiB0aGUgSElQIFdHIGFncmVlcykgYXMgdGhpcyBtYXkgcmVkdWNlIHRoZSBzZWN1cml0eSBy ZXF1aXJlbWVudHMgYnkgdGhlIFNFQyBBRCBhbmQgRWtyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+R29uemFs byBhbmQgSSBhcmUgc3RpbGwgaG9waW5nIHRvIGdldCBhIHJldmlzZWQgSElQLURFWCBzaG9ydGx5 LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LcOpcmljPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj5bMV0gPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1oaXAtZGV4L2hpc3RvcnkvIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtaGlwLWRleC9oaXN0b3J5LzwvYT4gPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPlsyXSA8YSBocmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9jbHVz dGVyX2luZm8ucGhwP2NpZD1DMzg2Ij4NCmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2NsdXN0 ZXJfaW5mby5waHA/Y2lkPUMzODY8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi PlszXSBhbmQgcG9zc2libHkgSSB3aWxsIHNldCB0aGUgc3RhdGUgb2YgSElQLURFWCBhcyDigJhk ZWFk4oCZIG9uIHRoZSBkYXRhdHJhY2tlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_68AF03688CB84DF3A33E0AA28E61B5F5ciscocom_-- From nobody Tue Jan 19 12:24:41 2021 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA943A1542; Thu, 14 Jan 2021 07:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, 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 U_vKnNyAkecr; Thu, 14 Jan 2021 07:07:38 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 D09973A1484; Thu, 14 Jan 2021 07:07:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id DDE00626FC; Thu, 14 Jan 2021 10:07:31 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RfteQ3-N5eMw; Thu, 14 Jan 2021 10:07:19 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id A7BB5622C2; Thu, 14 Jan 2021 10:07:18 -0500 (EST) To: "Eric Vyncke (evyncke)" , "Eric Vyncke (evyncke)" , "hipsec@ietf.org" , "draft-ietf-hip-dex@ietf.org" , Miika Komu Cc: Roman Danyliw , Eric Rescorla , Gonzalo Camarillo , "rene.hummen@belden.com" , Benjamin Kaduk , Erik Kline References: <68AF0368-8CB8-4DF3-A33E-0AA28E61B5F5@cisco.com> From: Robert Moskowitz Message-ID: <45191baf-ee46-89b8-fe84-742c5c17aadc@labs.htt-consult.com> Date: Thu, 14 Jan 2021 10:07:09 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <68AF0368-8CB8-4DF3-A33E-0AA28E61B5F5@cisco.com> Content-Type: multipart/alternative; boundary="------------6B155D0C911F05C831FC9912" Content-Language: en-US Archived-At: X-Mailman-Approved-At: Tue, 19 Jan 2021 12:24:35 -0800 Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13... X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 15:07:41 -0000 This is a multi-part message in MIME format. --------------6B155D0C911F05C831FC9912 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I had hoped to get -23 out end of last week, and missed my cutoff. I am now in IACR's Real World Crypto, where I have gotten a couple pointers for DRIP work. I was waiting for two analyzes that I got Jan 4, and incorporating them in.  I believe these SHOULD address much of EKR's questions. I will have a run of 1M DEX random HIs to HITs generated with no duplicates that I add in an Appendix along with the Python code. I am adding a BEX/DEX crypto cost into 1.2, probably 1.2.1: For an Initiator, BEX is: 2 PK sig varifications. 1 PK sig generation. 1 DH keypair generation. 1 DH secret derivation. DEX is: 1 DH secret derivation. I have cycles for these and a paper to reference, except ECDH keypair generation, on an 8 bit process and the numbers are big. But I think that part belongs in an Appendix. So unlikely Friday.  But early the following week. On 1/12/21 6:19 AM, Eric Vyncke (evyncke) wrote: > > Two months after the email below, I sending a kind reminder to authors > and WG. > > With the -22, a lot of (if not all ) SEC ADs’ DISCUSS points should > have been addressed. > > As far as I can tell, the other remaining issue was Ekr’s one about > why forfeiting FS when some algorithm could do it in a reasonable > time. In an email to authors and ADs, Eric R. wrote “it defines a set > of parameters (the NIST curves) which are slower w/o FS than other > parameters (X25519) are w/ FS. This fact calls into question the need > to dispense with FS.” > > While 2 months ago I put a deadline for tomorrow, I (as the > responsible AD) am flexible of course but we cannot linger anymore. I > know that a -23 is in the work for weeks => let’s publish it in the > coming days. > > Else, next week we will need to either change the intended status to > experimental or declare the document dead by lack of energy. The > latter does not have my preference obviously. > > Regards > > -éric > > *From: *Hipsec on behalf of "Eric Vyncke > (evyncke)" > *Date: *Friday, 13 November 2020 at 15:32 > *To: *"hipsec@ietf.org" , > "draft-ietf-hip-dex@ietf.org" , Robert > Moskowitz , Miika Komu > *Cc: *Roman Danyliw , Eric Rescorla , > Gonzalo Camarillo , > "rene.hummen@belden.com" , Benjamin Kaduk > , Erik Kline > *Subject: *[Hipsec] Need to close all draft-ietf-hip-dex-21 pending > issues... before 2021-Jan-13... > > Dear HIP, dear authors, > > This document was requested for publication [1] in February 2018 (2.5 > years ago), then its IESG evaluation has been deferred, then I took > over this document from Terry Manderson in March 2019, then it went > again through IESG evaluation in July 2020 and there are still DISCUSS > points to be addressed even after a couple of revised I-D... > > Difficult not to observe that this document does not progress very fast. > > Moreover, this document is a normative reference for rfc4423-bis > waiting in the RFC editor queue since March 2019... So, also blocking > the HIP-NAT document [2]. > > After discussion with the HIP chair, Gonzalo in cc, we have taken the > following decision: if a revised I-D addressing remaining DISCUSS > points + Ekr’s ones is not uploaded within 2 months (13^th of January > 2021), then I will request the HIP WG to accept the complete removal > of section A.3.3 of the rfc4423-bis document (1 page about HIP-DEX in > the appendix) + the reference to the HIP-DEX document [3]. This will > allow the immediate publication of the rfc4423-bis and HIP-NAT documents. > > The HIP DEX authors may also select to change the intended status of > the document to ‘experimental’ (if the HIP WG agrees) as this may > reduce the security requirements by the SEC AD and Ekr. > > Gonzalo and I are still hoping to get a revised HIP-DEX shortly, > > Regards > > -éric > > [1] https://datatracker.ietf.org/doc/draft-ietf-hip-dex/history/ > > > [2] https://www.rfc-editor.org/cluster_info.php?cid=C386 > > > [3] and possibly I will set the state of HIP-DEX as ‘dead’ on the > datatracker > -- Standard Robert Moskowitz Owner HTT Consulting C:248-219-2059 F:248-968-2824 E:rgm@labs.htt-consult.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------6B155D0C911F05C831FC9912 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I had hoped to get -23 out end of last week, and missed my cutoff.  I am now in IACR's Real World Crypto, where I have gotten a couple pointers for DRIP work.

I was waiting for two analyzes that I got Jan 4, and incorporating them in.  I believe these SHOULD address much of EKR's questions.

I will have a run of 1M DEX random HIs to HITs generated with no duplicates that I add in an Appendix along with the Python code.

I am adding a BEX/DEX crypto cost into 1.2, probably 1.2.1:

For an Initiator, BEX is:

2 PK sig varifications.
1 PK sig generation.
1 DH keypair generation.
1 DH secret derivation.

DEX is:

1 DH secret derivation.

I have cycles for these and a paper to reference, except ECDH keypair generation, on an 8 bit process and the numbers are big.  But I think that part belongs in an Appendix.

So unlikely Friday.  But early the following week.






On 1/12/21 6:19 AM, Eric Vyncke (evyncke) wrote:

Two months after the email below, I sending a kind reminder to authors and WG.

 

With the -22, a lot of (if not all ) SEC ADs’ DISCUSS points should have been addressed.

 

As far as I can tell, the other remaining issue was Ekr’s one about why forfeiting FS when some algorithm could do it in a reasonable time. In an email to authors and ADs, Eric R. wrote “it defines a set of parameters (the NIST curves) which are slower w/o FS than other parameters (X25519) are w/ FS. This fact calls into question the need to dispense with FS.”

 

While 2 months ago I put a deadline for tomorrow, I (as the responsible AD) am flexible of course but we cannot linger anymore. I know that a -23 is in the work for weeks => let’s publish it in the coming days.

 

Else, next week we will need to either change the intended status to experimental or declare the document dead by lack of energy. The latter does not have my preference obviously.

 

Regards

 

-éric

 

 

From: Hipsec <hipsec-bounces@ietf.org> on behalf of "Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>
Date: Friday, 13 November 2020 at 15:32
To: "hipsec@ietf.org" <hipsec@ietf.org>, "draft-ietf-hip-dex@ietf.org" <draft-ietf-hip-dex@ietf.org>, Robert Moskowitz <rgm@labs.htt-consult.com>, Miika Komu <miika.komu@ericsson.com>
Cc: Roman Danyliw <rdd@cert.org>, Eric Rescorla <ekr@rtfm.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "rene.hummen@belden.com" <rene.hummen@belden.com>, Benjamin Kaduk <kaduk@mit.edu>, Erik Kline <ek.ietf@gmail.com>
Subject: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...

 

Dear HIP, dear authors,

 

This document was requested for publication [1] in February 2018 (2.5 years ago), then its IESG evaluation has been deferred, then I took over this document from Terry Manderson in March 2019, then it went again through IESG evaluation in July 2020 and there are still DISCUSS points to be addressed even after a couple of revised I-D...

 

Difficult not to observe that this document does not progress very fast.

 

Moreover, this document is a normative reference for rfc4423-bis waiting in the RFC editor queue since March 2019... So, also blocking the HIP-NAT document [2].

 

After discussion with the HIP chair, Gonzalo in cc, we have taken the following decision: if a revised I-D addressing remaining DISCUSS points + Ekr’s ones is not uploaded within 2 months (13th of January 2021), then I will request the HIP WG to accept the complete removal of section A.3.3 of the rfc4423-bis document (1 page about HIP-DEX in the appendix) + the reference to the HIP-DEX document [3]. This will allow the immediate publication of the rfc4423-bis and HIP-NAT documents.

 

The HIP DEX authors may also select to change the intended status of the document to ‘experimental’ (if the HIP WG agrees) as this may reduce the security requirements by the SEC AD and Ekr.

 

Gonzalo and I are still hoping to get a revised HIP-DEX shortly,

 

Regards

 

-éric

 

[1] https://datatracker.ietf.org/doc/draft-ietf-hip-dex/history/

[2] https://www.rfc-editor.org/cluster_info.php?cid=C386

[3] and possibly I will set the state of HIP-DEX as ‘dead’ on the datatracker

 


--
Standard Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      rgm@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------6B155D0C911F05C831FC9912-- From nobody Tue Jan 19 12:24:45 2021 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26C63A13B6; Mon, 18 Jan 2021 06:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=RhWRZJcL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dEJv2A9+ 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 eebyhOtrePgW; Mon, 18 Jan 2021 06:12:29 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7B13A13A1; Mon, 18 Jan 2021 06:12:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40931; q=dns/txt; s=iport; t=1610979148; x=1612188748; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FgNZL42L2db0L+KSTkbuPBT0Cr7IQQAbssQgS/7jzMo=; b=RhWRZJcLnVyeMVFQo5rW3FB+azxOZChpkQ+Ja0xGuvMSqH4+86oz/6jz a0rDkz5N16QabmJF/BPoBGYBh99K9HtJCFkTY0R+eJg28hqOC6guh8WTA F39PRa2c9bSNttpkIztfZCkDvepTbRt26yoDYKbJ5FDHAGIeV9TEhkJN/ Y=; X-IPAS-Result: =?us-ascii?q?A0A/AABilgVgmIUNJK1GGQMaAQEBAQEBAQEBAQMBAQEBE?= =?us-ascii?q?gEBAQECAgEBAQGCD4EjMCkofVsvL4Q/g0gDjWAlA4ocjneBQoERA1QLAQEBD?= =?us-ascii?q?QEBJQgCBAEBhEoCF4FYAiU4EwIDAQEBAwIDAQEBAQUBAQECAQYEFAEBAQEBA?= =?us-ascii?q?QEBhjYMhXMBAQEEIx0BATcBDwIBBgIOAwECAQIhAQYDAgICHxEUAwYIAgQBD?= =?us-ascii?q?QWDJgGBflcDLgEOQJJrkGsCiiV2gTKDBQEBBoE3Ag5BgwUNC4IRAwaBOIJ2h?= =?us-ascii?q?AABgQqEF4EfJhuBQT+BEScMEIJWPoEEAYEWQgICAQEVgQwFAQwGATgJAQwag?= =?us-ascii?q?lI0giyBWAEQWQYVEToBA1MgAg0hIyUEJggRAQUaBAISEQUHBzmPWYJbAT+HN?= =?us-ascii?q?Iw4kGdYCoJ3iS+GfoYdhR4DH4MqkBCJQIVwJJN3ixyCeo8DAYQ1AgICAgQFA?= =?us-ascii?q?g4BAQaBbSEUVXBwFWUBggoBM1AXAg1XjUoMDAIJFG4BAYJKhRSFRHQCNQIGA?= =?us-ascii?q?QkBAQMJfIlbgWZfAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AnwqkjBbqzUeTTQxcPT7SgBX/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QSZD4HS4ekCi/bK9qvnX3cd5YrHu3cHI9RAVB?= =?us-ascii?q?4A3MMRmQFoQMuIElbyI/OiaSsmVN9DW1lo8zDeUwBVFc/yakeUrii06jgfSR?= =?us-ascii?q?H2PxEzJvjpX4XVid+q0/z08JrWME1EgTOnauZ0KxO75QzaqsgRh95kLaA8r3?= =?us-ascii?q?mBonZBd+lMg21yIlfGlBfn7cD295lmoCk=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,356,1602547200"; d="scan'208,217";a="653341955" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Jan 2021 14:12:27 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 10IECQbu013670 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Jan 2021 14:12:27 GMT Received: from xfe-rcd-004.cisco.com (173.37.227.252) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 18 Jan 2021 08:12:26 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Mon, 18 Jan 2021 08:12:26 -0600 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 18 Jan 2021 08:12:26 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VbGqLYCYCd70mG0QX/5JoVKNOZKC+ZVN9EZcAubHLuMAUlUGrL6q/jICEtXk+uV+OD6hMZ9URSUSLekvQCUGmEl1+O0D3+rSzGiz2gLfbKb3ct0kKOYOzQbqoNevVyzIIxz46/dBTWFI3+O/pWFnN5HBbRp9n8y6lsLpFZ2UdGp9db2PRGutq53t9hl1qUlQiErcI00vNFSgsZNXLWQmSL2+enSwix1nA0vitHFHLH5HnOnHcP4lcQ+hUKI01A4/EHQ3Td9rTt2Q7JX+AfSDGe2RCuI/LXSrwgNyBxnafj93ls8hA7GVW6b4dk4EZMiU7PwXLsDHCA/I4W+eEsEddw== 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=FgNZL42L2db0L+KSTkbuPBT0Cr7IQQAbssQgS/7jzMo=; b=hlgyoRnvySr+s/PqZvocttDnyBKr9eJ5nFPVv+mlAcmdfAznnFgSaOqrqxeW7gWmtgcqUOeLWt7vJiLL6WPDOqDmQ7RHB1GLi23ooDaeiSG5fXVaK25rLJQifxLYR/0LuBD94hr5bj/PUuFGpH8Dh6Xi2oQId7KP+Kh2wGvPtrtyoyzsr5ZsQ3qAoZYlJZtCzDlOa4EKWXxq06kCjOG549RN8gIoCF0OG0K/PyAq7tuWlaTG9i66OKPl4z/nDFGdcgjLVAO+RibH+/1EzNVkDape7YDhMUtvjlr1bdTbKIDaOLBC/08m6k5bnQF0SAiMIavxmUlcTx33kUlwU2RRFw== 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=FgNZL42L2db0L+KSTkbuPBT0Cr7IQQAbssQgS/7jzMo=; b=dEJv2A9+6OQdY/datQrBs37Thtr7/3AS/IcZAhHfE3FAJT9m+UINAR57zsYL5AhBn0fVS5ISSUTSH3WheF4OlZKIrK1NmqNMUieKW/gPIND582Fsj0bi96lddjkFoScHD+SSCcHXjlk0zNmMUrbvUlVb3vfBfNa2s9mkJWc6vKI= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5015.namprd11.prod.outlook.com (2603:10b6:510:39::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.9; Mon, 18 Jan 2021 14:12:24 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b%3]) with mapi id 15.20.3763.014; Mon, 18 Jan 2021 14:12:24 +0000 From: "Eric Vyncke (evyncke)" To: Robert Moskowitz , "hipsec@ietf.org" , "draft-ietf-hip-dex@ietf.org" , Miika Komu CC: Roman Danyliw , Eric Rescorla , "Gonzalo Camarillo" , "rene.hummen@belden.com" , Benjamin Kaduk , Erik Kline , Adam Wiethuechter Thread-Topic: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13... Thread-Index: AQHW6ocQR6j818zXLUeYvsVAsj8W+6otg5gA Date: Mon, 18 Jan 2021 14:12:24 +0000 Message-ID: <41AFBFEA-7119-451B-BC54-46CBB41274CA@cisco.com> References: <68AF0368-8CB8-4DF3-A33E-0AA28E61B5F5@cisco.com> <45191baf-ee46-89b8-fe84-742c5c17aadc@labs.htt-consult.com> In-Reply-To: <45191baf-ee46-89b8-fe84-742c5c17aadc@labs.htt-consult.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.45.21011103 authentication-results: labs.htt-consult.com; dkim=none (message not signed) header.d=none;labs.htt-consult.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:7056:700a:2adb:f6f4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 56be328d-980b-4cef-cbd3-08d8bbbb1467 x-ms-traffictypediagnostic: PH0PR11MB5015: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: x4Wyb05LvPZgaH/nGUPcjeMew7X398w2oY92wFySM61De26vI4fSs/zOseeMqCWVvghvNg6SA3qRBxPpqSfq1fLA+zTwGW/aRFWjGIt2ql7Ao7JsZ+W2DNkma/kM8cvZ3GZeTugsLpAAn4WL7a1FAVrD8D1OaOsxUAFWBmOSx0EIX/dJP4pk0GQaWcJusX2oV+Fh9EgiIx37KkECWSj+xkDSkhxSjoh7jHZN+APt73TlVtnjeF/6fDBGyN5X2QFbCEMbQruKNsmPZ5nOM6vQE9paVZ1uKImRJ27p8BjSCRMycZgA9H2P3dh8rdFTkpC+4nEpVIdL96Tx+bkc5Qj3bKbeJD/xl+3iCvylbpsmMnHD4+NUQjwMWSc0Gi1WN/X6l+PRDTUeWEQBFRwL4g/bEeq/7+Ww19kzX/72oNja7dn6qVZHwwdKaNCRXuYUb5OUOsr9nWrn0xcle7kOXXV2EKDfEcw5s1tXXt8GsaqqE7XCFabUcz2TzF/m7CILm7TyzPt/UF8COygZzRHWeoShYA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(39860400002)(136003)(366004)(346002)(376002)(7416002)(8676002)(166002)(64756008)(6486002)(316002)(8936002)(2906002)(6512007)(478600001)(83380400001)(66476007)(36756003)(2616005)(53546011)(66946007)(186003)(66556008)(110136005)(86362001)(76116006)(16799955002)(5660300002)(4326008)(6506007)(54906003)(71200400001)(966005)(91956017)(66446008)(33656002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?WHVQclJ6RjNwNWtJaElocHRKaDZ0SWk5UmFwdWxjdWZGRWs0YVhkRWVrZGRv?= =?utf-8?B?N3RqZUUxMzlJeE51L3M0N2tmaEtJTUxNQ3lWckltSVBOTXVnV1F5YmExdHIv?= =?utf-8?B?dlJ0S1dNd1pqM1NNOVJmY3ZKejBiZ0dZcC91eWJPamFReS9oSkpSSHpEUlh0?= =?utf-8?B?SlVkNWltSVROYW5FLzdZakQ1MDBrNUhhaDdZazBaMGtZbUVKWm5lTjhqUDJy?= =?utf-8?B?OWd2WG1nYTN0R3ZDVS80bzNvTU01MzBRcnBBYklqWHQ0bGl1NElCb2p5YjRS?= =?utf-8?B?by8wL1ZEZkh1TGsyMVRKWFRvdUtBbjhadWpFMS9UTkwrSHlMQ0pmRzlROW1x?= =?utf-8?B?aEhlQU9VLzkwWWhROEpFSlIxRlJmSmFTc2N3K3l0YVhNcDlpSGpORXROTVVX?= =?utf-8?B?VXYzSUpwSFc1OVgrc3NEcjVnd2YxMFN0eDkvVlNhY1V4UkRubWk2dk1CODM3?= =?utf-8?B?YldrRUkrQ0ZiZjRZMk1hdmFNNFo0Tm12Wis1cFlERk5hSERxL3pCVG9Wbi9O?= =?utf-8?B?WkJDYjlJZkQwRmZ1M3hSSi9VOGZFSnlZRE5JY0I4K2JBSEhFVDJPZTQwT1Vn?= =?utf-8?B?cGZoclh5SlNlSFdFY1YwdWpBZWZRcEZ4WkoxYUxpdDBDN1VwVmtHYVJiUGND?= =?utf-8?B?MzlhUTBvVXpiSVdLNnl0Z3ZVWEw0dzNnSVpNM0Q0VFFoQlJ6eTRaUmRKT2xE?= =?utf-8?B?ZVIzdWEwT0pGaVkrK0Z2NC8ycTl1TnZDUkdHMjVTQmRpWkNHVUFvY0JTbmM3?= =?utf-8?B?NTNnRlpRYnJOTW9tNENXUzlMTWlQT21VTGpjS3BSVE96SklQVHRJUmh1dXhP?= =?utf-8?B?bVY5ZkpLTFZTWERFTzZ5R2NQV21wZFZTaERWc1h5K28zeTh3MkVUeG9RejFz?= =?utf-8?B?QVFCSE02alZLajdGV2hiS3VIbVltRmRrQy8xZVBMWVFpazY4T1FJREVmSHJL?= =?utf-8?B?dDRxWmNOTzNuMVlKd2QxUkV6Qmt3YXBhYVduZWMzSjBGTzk1UW8wYnBMQ0Qr?= =?utf-8?B?d0c5SlNreDU3dzF2ODRLR3VuckRpSzhaUGJLUGxpL21zbWVsNG55RVhZMCtJ?= =?utf-8?B?UmwwM0M1aDZ1bHZQZ1Jwd20vK0Y1cE1uNVR5OXpGRzExc3dST3l3WXpTY25U?= =?utf-8?B?ek10bm9jK3QzUGpnckJUb0NWWXY0SVd1RGE2bU5vd0ZLazREc3FwRkhhVFFT?= =?utf-8?B?YmpydlBZblhSTVhiQmpFeGxIanIvQzhZQ0FyeFZ0UVdGb2RkakFLSnhqdnpO?= =?utf-8?B?L3g4TURFNEVhRE9yNUx3NUhOdXVLVHIwVlVUM2NhUGNZdW5xait4cXlvY0Rs?= =?utf-8?B?VmJKeFlzcVR6cDRPbnhETWozODluSHJ3TWJ4RGxlMFFBZWl2UnJtMFBuVUhv?= =?utf-8?B?eVJYN2ZsS29iUG1KL3oyUndQODhWdDQ5Ulk1T2JQVzFMTE9WTkZhUndPMWZ1?= =?utf-8?Q?qyBRcIZl?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_41AFBFEA7119451BBC5446CBB41274CAciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 56be328d-980b-4cef-cbd3-08d8bbbb1467 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2021 14:12:24.7485 (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: +ASEwNkx9G8dvfpPuIxnrvD67SS4gnbSheiBMAzlTsCtwMYqSogVH8aHzeqU9bbt4YInnm39JYq2T2BKIrQUcg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5015 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: X-Mailman-Approved-At: Tue, 19 Jan 2021 12:24:34 -0800 Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13... X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 14:12:36 -0000 --_000_41AFBFEA7119451BBC5446CBB41274CAciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VEQgO0xSIDogbW9yZSB3b3JrIHRvIGJlIGRvbmUsIGRlYWRsaW5lIHRoaXMgVGh1cnNkYXkgMjFz dA0KDQoNCg0KQm9iLA0KDQoNCg0KVGhhbmsgeW91IGZvciB0aGUgLTIzIChhbmQgQWRhbSBXIGZv ciB0aGUgZm9vdHdvcmspIGFuZCBJIHVuZGVyc3RhbmQgdGhhdCB5b3UgYXJlIHF1aXRlIGJ1c3ku DQoNCg0KDQpIZXJlIGlzIHRoZSBsaW5rIHRvIHRoZSBkaWZmIGJldHdlZW4gLTIxIGFuZCAtMjM6 IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWhpcC1kZXgtMjMm dXJsMT1kcmFmdC1pZXRmLWhpcC1kZXgtMjEgKGkuZS4sIHRoZSBvbmUgdXNlZCBieSBKdWx5IDIw MjAgSUVTRyBldmFsdWF0aW9uIGFuZCB0aGUgbGF0ZXN0IG9uZSkNCg0KDQoNCkFmdGVyIHRoZSBK dWx5IDIwMjAgSUVTRyBldmFsdWF0aW9uIGJhc2VkIG9uIC0yMSwgdGhlcmUgd2VyZSBhIGNvdXBs ZSBvZiBwb2ludHMgdG8gYmUgYWRkcmVzc2VkICh3aXRoIHNvbWUgY29tbWVudHMgb2YgbWluZSBh cyBFVlk+KToNCg0KICAqICAgUm9tYW46IOKAnFNlY3Rpb24gNi4zLiAgUGVyIHRoZSBkZWZpbml0 aW9uIG9mIElLTSwgd2hlbiBzaG91bGQgdGhlc2UgdHdvIGRpZmZlcmVudCBkZXJpdmF0aW9ucyBi ZSB1c2VkPyAiDQogICAgICogICBFVlk+IGluZGVlZCwgSUtNbSBhbmQgSUtNcCBhcmUgYm90aCBk ZWZpbmVkIGJ1dCBub3RoaW5nIGlzIHNhaWQgd2hpY2ggb25lIHRvIHVzZSBpbiB3aGljaCBjYXNl Lg0KICAqICAgUm9tYW4gImRpc2N1c3MtZGlzY3VzcyIgKHJlYWQgdGhpcyBhcyByZXF1ZXN0IGZv ciByZXBseSBhbmQgbm9uLWJsb2NraW5nKSBhYm91dCAiIGZ1cnRoZXIgaW1wbGVtZW50YXRpb24g ZXhwZXJpZW5jZSBwcm92aWRlcyBiZXR0ZXIgZ3VpZGFuY2UiIGluIHNlY3Rpb25zIDYgYW5kIDku DQogICAgICogICBFVlk+IHRoaXMgcmVhbGx5IHBsZWFkcyBmb3IgZXhwZXJpbWVudGFsIHN0YXR1 cw0KICAqICAgQmVuamFtaW4gb24gRk9MRCBjb2xsaXNpb25zDQogICAgICogICBFVlk+IElNSE8g YWRkcmVzc2VkIGluIHRoZSBuZXcgc2VjdGlvbiAzLjIuMQ0KICAqICAgQmVuamFtaW4gb24gQUNM IHRvIGNvdW50ZXIgRk9MRCBjb2xsaXNpb25zIGluIHNlY3Rpb24gMy4yLjENCiAgICAgKiAgIEVW WT4gc3RpbGwgbGlnaHQgb24gdGhlIEFDTCBidXQgdGhlIGFib3ZlIHNob3VsZCBjbGVhciBpdA0K ICAqICAgQmVuamFtaW4gImhvdyBpcyBpdCBrbm93biB0aGF0IHRoZSBwZWVyIHNob3VsZCBiZSB1 c2luZyBERVggdnMuIEJFWCINCiAgICAgKiAgIEVWWT4gcGFydGlhbGx5IGFkZHJlc3NlZCBpbiBz ZWN0aW9uIDEuMiBidXQgc2hvdWxkIGJlIHJlcGVhdGVkIGluIHRoZSBzZWN1cml0eSBzZWN0aW9u DQogICogICBCZW5qYW1pbiBsYWNrIG9mIGRpc2N1c3Npb24gb24gdGhlIHNlY3VyaXR5IGNvbnNl cXVlbmNlcyBvZiBpbmFkdmVydGVudCBjb3VudGVyIHJldXNlIGluIEFFUy1DVFINCiAgKiAgIEJl bmphbWluICJwcmVzZW5jZSBvZiBhIENTUFJORyBpbiBvcmRlciB0byBvYnRhaW4gc2VjdXJlIHNl c3Npb24ga2V5cyINCiAgKiAgIEJlbmphbWluICJ1c2FnZSBvZiBDTUFDIGluc3RlYWQgb2YgSE1B QyIgYWJvdXQgS0VZTUFUIGFsZ29yaXRobQ0KICAgICAqICAgRVZZPiBuZXcgcmVmZXJlbmNlIHRv IE5JU1QgcGFwZXJzIHNlZW1zIHRvIGFkZHJlc3MgdGhpcyBjb25jZXJuDQogICogICBFa3LigJlz IG9uZSBhYm91dCB3aHkgZm9yZmVpdGluZyBGUyB3aGVuIHNvbWUgYWxnb3JpdGhtIGNvdWxkIGRv IGl0IGluIGEgcmVhc29uYWJsZSB0aW1lLiBJbiBhbiBlbWFpbCB0byBhdXRob3JzIGFuZCBBRHMs IEVyaWMgUi4gd3JvdGUg4oCcaXQgZGVmaW5lcyBhIHNldCBvZiBwYXJhbWV0ZXJzICh0aGUgTklT VCBjdXJ2ZXMpIHdoaWNoIGFyZSBzbG93ZXIgdy9vIEZTIHRoYW4gb3RoZXIgcGFyYW1ldGVycyAo WDI1NTE5KSBhcmUgdy8gRlMuIFRoaXMgZmFjdCBjYWxscyBpbnRvIHF1ZXN0aW9uIHRoZSBuZWVk IHRvIGRpc3BlbnNlIHdpdGggRlMu4oCdDQogICAgICogICBFVlk+IHRoZSBhZGRpdGlvbmFsIHNl Y3Rpb24gMS4yLjEgYW5kIHRoZSByZWZlcmVuY2UgdG8gYSBwYXl3YWxsIEVmZmljaWVudEVDQyBy ZWZlcmVuY2UgZG8gbm90IG9mZmVyIGEgY29uY2x1c2l2ZSBtb3RpdmF0aW9uIGZvciBhbiBJRVRG IHN0YW5kYXJkcyB3L28gRlMuDQoNCg0KDQoqKipCb3R0b20gbGluZSwgdGhlIGRvY3VtZW50IGlz IG5vdCB5ZXQgcmVhZHkgdG8gYmUgYXBwcm92ZWQuKioqIChldmVuIGlmIGJpZyBwcm9ncmVzcyBo YXMgYmVlbiBtYWRlKQ0KDQoNCg0KQXMgd3JpdHRlbiBpbiBOb3ZlbWJlciAoc2VlIGJlbG93KSwg dGhlIHNpdHVhdGlvbiBoYXMgbGluZ2VyZWQgZm9yIHRvbyBsb25nIGFuZCBpcyBibG9ja2luZyB0 aGUgSElQLU5BVCBhbmQgcmZjNDQyMy1iaXMgZG9jdW1lbnRzLg0KDQoNCg0KKioqIFRoZXJlZm9y ZSwgSSByZXF1ZXN0IHRoZSBhdXRob3JzIGZvciBhIHJldmlzZWQgSS1EIGFkZHJlc3NpbmcgdGhl IGFib3ZlIChhbmQgbm90aW5nIGFnYWluIHRoYXQgYSBjaGFuZ2UgdG8g4oCYZXhwZXJpbWVudGFs 4oCZIOKAkyBhcyB0aGVyZSBhcmUgbm8gZGVwbG95ZWQgaW1wbGVtZW50YXRpb25zIOKAkyBjb3Vs ZCBwcm9iYWJseSBmaXggYWxsIG9mIHRoZW0pIGJlZm9yZSBUaHVyc2RheSAyMXN0IG9mIEphbnVh cnkgbWlkbmlnaHQgVVRDIGVsc2UgSSB3aWxsIGFzayB0aGUgSElQU0VDIFdHIHRvIGFncmVlIHJl bW92aW5nIHRoZSBISVAtREVYIHNlY3Rpb24gZnJvbSB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50 LiAqKioNCg0KDQoNCkFsbCBpbiBhbGwsIHRoZXJlIGhhdmUgYmVlbiBhIGNvdXBsZSBvZiBzaWdu aWZpY2FudCBjaGFuZ2VzIChJX05PTkNFLCBzb21lIGRlbGV0ZWQgY2lwaGVycykgc2luY2UgdGhl IElFVEYgbGFzdCBjYWxsIChzZWUgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtaGlwLWRleC0yMyZ1cmwxPWRyYWZ0LWlldGYtaGlwLWRleC0yMSApLCBzbywgYW5v dGhlciBJRVRGIExhc3QgQ2FsbCBpcyByZXF1aXJlZCBidXQgc2hvdWxkIG5vdCBiZSBhIHJlYWwg cHJvYmxlbS4NCg0KDQoNCg0KDQotw6lyaWMNCg0KDQoNCg0KDQoNCg0KRnJvbTogUm9iZXJ0IE1v c2tvd2l0eiA8cmdtQGxhYnMuaHR0LWNvbnN1bHQuY29tPg0KDQpEYXRlOiBUaHVyc2RheSwgMTQg SmFudWFyeSAyMDIxIGF0IDE2OjA4DQoNClRvOiBFcmljIFZ5bmNrZSA8ZXZ5bmNrZUBjaXNjby5j b20+LCAiRXJpYyBWeW5ja2UgKGV2eW5ja2UpIiA8ZXZ5bmNrZT00MGNpc2NvLmNvbUBkbWFyYy5p ZXRmLm9yZz4sICJoaXBzZWNAaWV0Zi5vcmciIDxoaXBzZWNAaWV0Zi5vcmc+LCAiZHJhZnQtaWV0 Zi1oaXAtZGV4QGlldGYub3JnIiA8ZHJhZnQtaWV0Zi1oaXAtZGV4QGlldGYub3JnPiwgTWlpa2Eg S29tdSA8bWlpa2Eua29tdUBlcmljc3Nvbi5jb20+DQoNCkNjOiBSb21hbiBEYW55bGl3IDxyZGRA Y2VydC5vcmc+LCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+LCBHb256YWxvIENhbWFyaWxs byA8Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tPiwgInJlbmUuaHVtbWVuQGJlbGRlbi5j b20iIDxyZW5lLmh1bW1lbkBiZWxkZW4uY29tPiwgQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5l ZHU+LCBFcmlrIEtsaW5lIDxlay5pZXRmQGdtYWlsLmNvbT4NCg0KU3ViamVjdDogUmU6IFtIaXBz ZWNdIE5lZWQgdG8gY2xvc2UgYWxsIGRyYWZ0LWlldGYtaGlwLWRleC0yMSBwZW5kaW5nIGlzc3Vl cy4uLiBiZWZvcmUgMjAyMS1KYW4tMTMuLi4NCg0KDQoNCkkgaGFkIGhvcGVkIHRvIGdldCAtMjMg b3V0IGVuZCBvZiBsYXN0IHdlZWssIGFuZCBtaXNzZWQgbXkgY3V0b2ZmLiAgSSBhbSBub3cgaW4g SUFDUidzIFJlYWwgV29ybGQgQ3J5cHRvLCB3aGVyZSBJIGhhdmUgZ290dGVuIGEgY291cGxlIHBv aW50ZXJzIGZvciBEUklQIHdvcmsuDQoNCg0KDQpJIHdhcyB3YWl0aW5nIGZvciB0d28gYW5hbHl6 ZXMgdGhhdCBJIGdvdCBKYW4gNCwgYW5kIGluY29ycG9yYXRpbmcgdGhlbSBpbi4gIEkgYmVsaWV2 ZSB0aGVzZSBTSE9VTEQgYWRkcmVzcyBtdWNoIG9mIEVLUidzIHF1ZXN0aW9ucy4NCg0KDQoNCkkg d2lsbCBoYXZlIGEgcnVuIG9mIDFNIERFWCByYW5kb20gSElzIHRvIEhJVHMgZ2VuZXJhdGVkIHdp dGggbm8gZHVwbGljYXRlcyB0aGF0IEkgYWRkIGluIGFuIEFwcGVuZGl4IGFsb25nIHdpdGggdGhl IFB5dGhvbiBjb2RlLg0KDQoNCg0KSSBhbSBhZGRpbmcgYSBCRVgvREVYIGNyeXB0byBjb3N0IGlu dG8gMS4yLCBwcm9iYWJseSAxLjIuMToNCg0KDQoNCkZvciBhbiBJbml0aWF0b3IsIEJFWCBpczoN Cg0KDQoNCjIgUEsgc2lnIHZhcmlmaWNhdGlvbnMuDQoNCjEgUEsgc2lnIGdlbmVyYXRpb24uDQoN CjEgREgga2V5cGFpciBnZW5lcmF0aW9uLg0KDQoxIERIIHNlY3JldCBkZXJpdmF0aW9uLg0KDQoN Cg0KREVYIGlzOg0KDQoNCg0KMSBESCBzZWNyZXQgZGVyaXZhdGlvbi4NCg0KDQoNCkkgaGF2ZSBj eWNsZXMgZm9yIHRoZXNlIGFuZCBhIHBhcGVyIHRvIHJlZmVyZW5jZSwgZXhjZXB0IEVDREgga2V5 cGFpciBnZW5lcmF0aW9uLCBvbiBhbiA4IGJpdCBwcm9jZXNzIGFuZCB0aGUgbnVtYmVycyBhcmUg YmlnLiAgQnV0IEkgdGhpbmsgdGhhdCBwYXJ0IGJlbG9uZ3MgaW4gYW4gQXBwZW5kaXguDQoNCg0K DQpTbyB1bmxpa2VseSBGcmlkYXkuICBCdXQgZWFybHkgdGhlIGZvbGxvd2luZyB3ZWVrLg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCk9uIDEvMTIvMjEgNjoxOSBBTSwgRXJpYyBWeW5ja2UgKGV2eW5j a2UpIHdyb3RlOg0KDQpUd28gbW9udGhzIGFmdGVyIHRoZSBlbWFpbCBiZWxvdywgSSBzZW5kaW5n IGEga2luZCByZW1pbmRlciB0byBhdXRob3JzIGFuZCBXRy4NCg0KDQoNCldpdGggdGhlIC0yMiwg YSBsb3Qgb2YgKGlmIG5vdCBhbGwgKSBTRUMgQURz4oCZIERJU0NVU1MgcG9pbnRzIHNob3VsZCBo YXZlIGJlZW4gYWRkcmVzc2VkLg0KDQoNCg0KQXMgZmFyIGFzIEkgY2FuIHRlbGwsIHRoZSBvdGhl ciByZW1haW5pbmcgaXNzdWUgd2FzIEVrcuKAmXMgb25lIGFib3V0IHdoeSBmb3JmZWl0aW5nIEZT IHdoZW4gc29tZSBhbGdvcml0aG0gY291bGQgZG8gaXQgaW4gYSByZWFzb25hYmxlIHRpbWUuIElu IGFuIGVtYWlsIHRvIGF1dGhvcnMgYW5kIEFEcywgRXJpYyBSLiB3cm90ZSDigJxpdCBkZWZpbmVz IGEgc2V0IG9mIHBhcmFtZXRlcnMgKHRoZSBOSVNUIGN1cnZlcykgd2hpY2ggYXJlIHNsb3dlciB3 L28gRlMgdGhhbiBvdGhlciBwYXJhbWV0ZXJzIChYMjU1MTkpIGFyZSB3LyBGUy4gVGhpcyBmYWN0 IGNhbGxzIGludG8gcXVlc3Rpb24gdGhlIG5lZWQgdG8gZGlzcGVuc2Ugd2l0aCBGUy7igJ0NCg0K DQoNCldoaWxlIDIgbW9udGhzIGFnbyBJIHB1dCBhIGRlYWRsaW5lIGZvciB0b21vcnJvdywgSSAo YXMgdGhlIHJlc3BvbnNpYmxlIEFEKSBhbSBmbGV4aWJsZSBvZiBjb3Vyc2UgYnV0IHdlIGNhbm5v dCBsaW5nZXIgYW55bW9yZS4gSSBrbm93IHRoYXQgYSAtMjMgaXMgaW4gdGhlIHdvcmsgZm9yIHdl ZWtzID0+IGxldOKAmXMgcHVibGlzaCBpdCBpbiB0aGUgY29taW5nIGRheXMuDQoNCg0KDQpFbHNl LCBuZXh0IHdlZWsgd2Ugd2lsbCBuZWVkIHRvIGVpdGhlciBjaGFuZ2UgdGhlIGludGVuZGVkIHN0 YXR1cyB0byBleHBlcmltZW50YWwgb3IgZGVjbGFyZSB0aGUgZG9jdW1lbnQgZGVhZCBieSBsYWNr IG9mIGVuZXJneS4gVGhlIGxhdHRlciBkb2VzIG5vdCBoYXZlIG15IHByZWZlcmVuY2Ugb2J2aW91 c2x5Lg0KDQoNCg0KUmVnYXJkcw0KDQoNCg0KLcOpcmljDQoNCg0KDQoNCg0KRnJvbTogSGlwc2Vj IG1haWx0bzpoaXBzZWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgIkVyaWMgVnluY2tl IChldnluY2tlKSIgbWFpbHRvOmV2eW5ja2U9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmcNCg0K RGF0ZTogRnJpZGF5LCAxMyBOb3ZlbWJlciAyMDIwIGF0IDE1OjMyDQoNClRvOiBtYWlsdG86aGlw c2VjQGlldGYub3JnIG1haWx0bzpoaXBzZWNAaWV0Zi5vcmcsIG1haWx0bzpkcmFmdC1pZXRmLWhp cC1kZXhAaWV0Zi5vcmcgbWFpbHRvOmRyYWZ0LWlldGYtaGlwLWRleEBpZXRmLm9yZywgUm9iZXJ0 IE1vc2tvd2l0eiBtYWlsdG86cmdtQGxhYnMuaHR0LWNvbnN1bHQuY29tLCBNaWlrYSBLb211IG1h aWx0bzptaWlrYS5rb211QGVyaWNzc29uLmNvbQ0KDQpDYzogUm9tYW4gRGFueWxpdyBtYWlsdG86 cmRkQGNlcnQub3JnLCBFcmljIFJlc2NvcmxhIG1haWx0bzpla3JAcnRmbS5jb20sIEdvbnphbG8g Q2FtYXJpbGxvIG1haWx0bzpnb256YWxvLmNhbWFyaWxsb0Blcmljc3Nvbi5jb20sIG1haWx0bzpy ZW5lLmh1bW1lbkBiZWxkZW4uY29tIG1haWx0bzpyZW5lLmh1bW1lbkBiZWxkZW4uY29tLCBCZW5q YW1pbiBLYWR1ayBtYWlsdG86a2FkdWtAbWl0LmVkdSwgRXJpayBLbGluZSBtYWlsdG86ZWsuaWV0 ZkBnbWFpbC5jb20NCg0KU3ViamVjdDogW0hpcHNlY10gTmVlZCB0byBjbG9zZSBhbGwgZHJhZnQt aWV0Zi1oaXAtZGV4LTIxIHBlbmRpbmcgaXNzdWVzLi4uIGJlZm9yZSAyMDIxLUphbi0xMy4uLg0K DQoNCg0KRGVhciBISVAsIGRlYXIgYXV0aG9ycywNCg0KDQoNClRoaXMgZG9jdW1lbnQgd2FzIHJl cXVlc3RlZCBmb3IgcHVibGljYXRpb24gWzFdIGluIEZlYnJ1YXJ5IDIwMTggKDIuNSB5ZWFycyBh Z28pLCB0aGVuIGl0cyBJRVNHIGV2YWx1YXRpb24gaGFzIGJlZW4gZGVmZXJyZWQsIHRoZW4gSSB0 b29rIG92ZXIgdGhpcyBkb2N1bWVudCBmcm9tIFRlcnJ5IE1hbmRlcnNvbiBpbiBNYXJjaCAyMDE5 LCB0aGVuIGl0IHdlbnQgYWdhaW4gdGhyb3VnaCBJRVNHIGV2YWx1YXRpb24gaW4gSnVseSAyMDIw IGFuZCB0aGVyZSBhcmUgc3RpbGwgRElTQ1VTUyBwb2ludHMgdG8gYmUgYWRkcmVzc2VkIGV2ZW4g YWZ0ZXIgYSBjb3VwbGUgb2YgcmV2aXNlZCBJLUQuLi4NCg0KDQoNCkRpZmZpY3VsdCBub3QgdG8g b2JzZXJ2ZSB0aGF0IHRoaXMgZG9jdW1lbnQgZG9lcyBub3QgcHJvZ3Jlc3MgdmVyeSBmYXN0Lg0K DQoNCg0KTW9yZW92ZXIsIHRoaXMgZG9jdW1lbnQgaXMgYSBub3JtYXRpdmUgcmVmZXJlbmNlIGZv ciByZmM0NDIzLWJpcyB3YWl0aW5nIGluIHRoZSBSRkMgZWRpdG9yIHF1ZXVlIHNpbmNlIE1hcmNo IDIwMTkuLi4gU28sIGFsc28gYmxvY2tpbmcgdGhlIEhJUC1OQVQgZG9jdW1lbnQgWzJdLg0KDQoN Cg0KQWZ0ZXIgZGlzY3Vzc2lvbiB3aXRoIHRoZSBISVAgY2hhaXIsIEdvbnphbG8gaW4gY2MsIHdl IGhhdmUgdGFrZW4gdGhlIGZvbGxvd2luZyBkZWNpc2lvbjogaWYgYSByZXZpc2VkIEktRCBhZGRy ZXNzaW5nIHJlbWFpbmluZyBESVNDVVNTIHBvaW50cyArIEVrcuKAmXMgb25lcyBpcyBub3QgdXBs b2FkZWQgd2l0aGluIDIgbW9udGhzICgxM3RoIG9mIEphbnVhcnkgMjAyMSksIHRoZW4gSSB3aWxs IHJlcXVlc3QgdGhlIEhJUCBXRyB0byBhY2NlcHQgdGhlIGNvbXBsZXRlIHJlbW92YWwgb2Ygc2Vj dGlvbiBBLjMuMyBvZiB0aGUgcmZjNDQyMy1iaXMgZG9jdW1lbnQgKDEgcGFnZSBhYm91dCBISVAt REVYIGluIHRoZSBhcHBlbmRpeCkgKyB0aGUgcmVmZXJlbmNlIHRvIHRoZSBISVAtREVYIGRvY3Vt ZW50IFszXS4gVGhpcyB3aWxsIGFsbG93IHRoZSBpbW1lZGlhdGUgcHVibGljYXRpb24gb2YgdGhl IHJmYzQ0MjMtYmlzIGFuZCBISVAtTkFUIGRvY3VtZW50cy4NCg0KDQoNClRoZSBISVAgREVYIGF1 dGhvcnMgbWF5IGFsc28gc2VsZWN0IHRvIGNoYW5nZSB0aGUgaW50ZW5kZWQgc3RhdHVzIG9mIHRo ZSBkb2N1bWVudCB0byDigJhleHBlcmltZW50YWzigJkgKGlmIHRoZSBISVAgV0cgYWdyZWVzKSBh cyB0aGlzIG1heSByZWR1Y2UgdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBieSB0aGUgU0VDIEFE IGFuZCBFa3IuDQoNCg0KDQpHb256YWxvIGFuZCBJIGFyZSBzdGlsbCBob3BpbmcgdG8gZ2V0IGEg cmV2aXNlZCBISVAtREVYIHNob3J0bHksDQoNCg0KDQpSZWdhcmRzDQoNCg0KDQotw6lyaWMNCg0K DQoNClsxXSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWhpcC1k ZXgvaGlzdG9yeS8NCg0KWzJdIGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2NsdXN0ZXJfaW5m by5waHA/Y2lkPUMzODYNCg0KWzNdIGFuZCBwb3NzaWJseSBJIHdpbGwgc2V0IHRoZSBzdGF0ZSBv ZiBISVAtREVYIGFzIOKAmGRlYWTigJkgb24gdGhlIGRhdGF0cmFja2VyDQoNCg0KDQoNCg0KLS0N Cg0KUm9iZXJ0IE1vc2tvd2l0eg0KDQpPd25lcg0KDQpIVFQgQ29uc3VsdGluZw0KDQpDOiAgICAg IDI0OC0yMTktMjA1OQ0KDQpGOiAgICAgIDI0OC05NjgtMjgyNA0KDQpFOiAgICAgIG1haWx0bzpy Z21AbGFicy5odHQtY29uc3VsdC5jb20NCg0KDQoNClRoZXJlJ3Mgbm8gbGltaXQgdG8gd2hhdCBj YW4gYmUgYWNjb21wbGlzaGVkIGlmIGl0IGRvZXNuJ3QgbWF0dGVyIHdobyBnZXRzIHRoZSBjcmVk aXQNCg== --_000_41AFBFEA7119451BBC5446CBB41274CAciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <2225BB728B79994A878F1E5215DA57A7@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8dGl0bGU+U3RhbmRhcmQ8L3RpdGxlPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQg RGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBh bm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi Q2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29Q bGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFp biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi UGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt c28tbGlzdC1pZDozMDQ1MDQwNzE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi03ODU4ODAxMjIgLTM5MDcxNjEwNiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlz dCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE2ODcyOTQ0NTY7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE5MjQzNDkxMCAtMzkwNzE2MTA2 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6 MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwxOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9ImVuLUJFIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13 cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5URCZuYnNwOztMUiZuYnNwOzogbW9yZSB3 b3JrIHRvIGJlIGRvbmUsIGRlYWRsaW5lIHRoaXMgVGh1cnNkYXkgMjFzdDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Cb2IsIDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VDwvc3Bhbj5o YW5rIHlvdSBmb3IgdGhlIC0yMyAoYW5kIEFkYW0gVyBmb3IgdGhlIGZvb3R3b3JrKTxzcGFuIGxh bmc9IkVOLVVTIj4gYW5kIEkgdW5kZXJzdGFuZCB0aGF0IHlvdSBhcmUgcXVpdGUgYnVzeS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhlcmUgaXMgdGhlIGxpbmsgdG8gdGhl IGRpZmYgYmV0d2VlbiAtMjEgYW5kIC0yMzogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtaGlwLWRleC0yMyZhbXA7dXJsMT1kcmFmdC1pZXRmLWhp cC1kZXgtMjEiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYt aGlwLWRleC0yMyZhbXA7dXJsMT1kcmFmdC1pZXRmLWhpcC1kZXgtMjE8L2E+DQo8c3BhbiBsYW5n PSJFTi1VUyI+KGkuZS4sIHRoZSBvbmUgdXNlZCBieSBKdWx5IDIwMjAgSUVTRyBldmFsdWF0aW9u IGFuZCB0aGUgbGF0ZXN0IG9uZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PkFmdGVyIHRoZSBKdWx5IDIwMjAgSUVTRyBldmFsdWF0aW9uIDxzcGFuIGxhbmc9IkVOLVVTIj5i YXNlZA0KPC9zcGFuPm9uIC08c3BhbiBsYW5nPSJFTi1VUyI+MjE8L3NwYW4+LCB0aGVyZSB3ZXJl IGEgY291cGxlIG9mIHBvaW50cyB0byBiZSBhZGRyZXNzZWQ8c3BhbiBsYW5nPSJFTi1VUyI+ICh3 aXRoIHNvbWUgY29tbWVudHMgb2YgbWluZSBhcyBFVlkmZ3Q7KTwvc3Bhbj46PG86cD48L286cD48 L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPlJvbWFuOiDigJxT ZWN0aW9uIDYuMy4mbmJzcDsgUGVyIHRoZSBkZWZpbml0aW9uIG9mIElLTSwgd2hlbiBzaG91bGQg dGhlc2UgdHdvIGRpZmZlcmVudCBkZXJpdmF0aW9ucyBiZSB1c2VkPw0KPHNwYW4gbGFuZz0iRU4t VVMiPiZxdW90OyA8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjx1bCBzdHlsZT0ibWFyZ2luLXRvcDow Y20iIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1zby1s aXN0OmwxIGxldmVsMiBsZm8yIj48c3BhbiBsYW5nPSJFTi1VUyI+RVZZJmd0OyBpbmRlZWQsIElL TW0gYW5kIElLTXAgYXJlIGJvdGggZGVmaW5lZCBidXQgbm90aGluZyBpcyBzYWlkIHdoaWNoIG9u ZSB0byB1c2UgaW4gd2hpY2ggY2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8bGkg Y2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8yIj48c3Bh biBsYW5nPSJFTi1VUyI+Um9tYW4gJnF1b3Q7ZGlzY3Vzcy1kaXNjdXNzJnF1b3Q7IChyZWFkIHRo aXMgYXMgcmVxdWVzdCBmb3IgcmVwbHkgYW5kIG5vbi1ibG9ja2luZykgYWJvdXQgJnF1b3Q7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ZnVydGhl ciBpbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlIHByb3ZpZGVzIGJldHRlciBndWlkYW5jZSZxdW90 OyBpbiBzZWN0aW9ucyA2IGFuZCA5LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PHVsIHN0eWxlPSJt YXJnaW4tdG9wOjBjbSIgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzIiPjxzcGFuIGxhbmc9IkVOLVVTIj5FVlkmZ3Q7 IHRoaXMgcmVhbGx5IHBsZWFkcyBmb3IgZXhwZXJpbWVudGFsIHN0YXR1czxvOnA+PC9vOnA+PC9z cGFuPjwvbGk+PC91bD4NCjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzIiPjxzcGFuIGxhbmc9IkVOLVVTIj5CZW5qYW1pbiBvbiBGT0xEIGNvbGxp c2lvbnMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIg dHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibXNvLWxpc3Q6 bDEgbGV2ZWwyIGxmbzIiPjxzcGFuIGxhbmc9IkVOLVVTIj5FVlkmZ3Q7IElNSE8gYWRkcmVzc2Vk IGluIHRoZSBuZXcgc2VjdGlvbiAzLjIuMTxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxs aSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjxz cGFuIGxhbmc9IkVOLVVTIj5CZW5qYW1pbiBvbiBBQ0wgdG8gY291bnRlciBGT0xEIGNvbGxpc2lv bnMgaW4gc2VjdGlvbiAzLjIuMTxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PHVsIHN0eWxlPSJtYXJn aW4tdG9wOjBjbSIgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls ZT0ibXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzIiPjxzcGFuIGxhbmc9IkVOLVVTIj5FVlkmZ3Q7IHN0 aWxsIGxpZ2h0IG9uIHRoZSBBQ0wgYnV0IHRoZSBhYm92ZSBzaG91bGQgY2xlYXIgaXQ8bzpwPjwv bzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8bGkgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1z by1saXN0OmwxIGxldmVsMSBsZm8yIj48c3BhbiBsYW5nPSJFTi1VUyI+QmVuamFtaW4gJnF1b3Q7 aG93IGlzIGl0IGtub3duIHRoYXQgdGhlIHBlZXIgc2hvdWxkIGJlIHVzaW5nIERFWCB2cy4gQkVY JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9saT48dWwgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiB0 eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtc28tbGlzdDps MSBsZXZlbDIgbGZvMiI+PHNwYW4gbGFuZz0iRU4tVVMiPkVWWSZndDsgcGFydGlhbGx5IGFkZHJl c3NlZCBpbiBzZWN0aW9uIDEuMiBidXQgc2hvdWxkIGJlIHJlcGVhdGVkIGluIHRoZSBzZWN1cml0 eSBzZWN0aW9uPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPGxpIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PHNwYW4gbGFuZz0iRU4tVVMi PkJlbmphbWluIGxhY2sgb2YgZGlzY3Vzc2lvbiBvbiB0aGUgc2VjdXJpdHkgY29uc2VxdWVuY2Vz IG9mIGluYWR2ZXJ0ZW50IGNvdW50ZXIgcmV1c2UgaW4gQUVTLUNUUjxvOnA+PC9vOnA+PC9zcGFu PjwvbGk+PGxpIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDEg bGZvMiI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlbmphbWluICZxdW90O3ByZXNlbmNlIG9mIGEgQ1NQ Uk5HIGluIG9yZGVyIHRvIG9idGFpbiBzZWN1cmUgc2Vzc2lvbiBrZXlzJnF1b3Q7PG86cD48L286 cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1zby1saXN0Omwx IGxldmVsMSBsZm8yIj48c3BhbiBsYW5nPSJFTi1VUyI+QmVuamFtaW4gJnF1b3Q7dXNhZ2Ugb2Yg Q01BQyBpbnN0ZWFkIG9mIEhNQUMmcXVvdDsgYWJvdXQgS0VZTUFUIGFsZ29yaXRobTxvOnA+PC9v OnA+PC9zcGFuPjwvbGk+PHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0iY2lyY2xlIj4N CjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzIi PjxzcGFuIGxhbmc9IkVOLVVTIj5FVlkmZ3Q7IG5ldyByZWZlcmVuY2UgdG8gTklTVCBwYXBlcnMg c2VlbXMgdG8gYWRkcmVzcyB0aGlzIGNvbmNlcm48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+ DQo8bGkgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8y Ij5Fa3LigJlzIG9uZSBhYm91dCB3aHkgZm9yZmVpdGluZyBGUyB3aGVuIHNvbWUgYWxnb3JpdGht IGNvdWxkIGRvIGl0IGluIGEgcmVhc29uYWJsZSB0aW1lLiBJbiBhbiBlbWFpbCB0byBhdXRob3Jz IGFuZCBBRHMsIEVyaWMgUi4gd3JvdGUg4oCcaXQgZGVmaW5lcyBhIHNldCBvZiBwYXJhbWV0ZXJz ICh0aGUgTklTVCBjdXJ2ZXMpIHdoaWNoIGFyZSBzbG93ZXINCiB3L28gRlMgdGhhbiBvdGhlciBw YXJhbWV0ZXJzIChYMjU1MTkpIGFyZSB3LyBGUy4gVGhpcyBmYWN0IGNhbGxzIGludG8gcXVlc3Rp b24gdGhlIG5lZWQgdG8gZGlzcGVuc2Ugd2l0aCBGUy7igJ08bzpwPjwvbzpwPjwvbGk+PHVsIHN0 eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzIiPjxzcGFuIGxhbmc9IkVOLVVTIj5F VlkmZ3Q7IHRoZSBhZGRpdGlvbmFsIHNlY3Rpb24gMS4yLjEgYW5kIHRoZSByZWZlcmVuY2UgdG8g YSBwYXl3YWxsIEVmZmljaWVudEVDQyByZWZlcmVuY2UgZG8gbm90IG9mZmVyIGEgY29uY2x1c2l2 ZSBtb3RpdmF0aW9uIGZvciBhbiBJRVRGIHN0YW5kYXJkcyB3L28gRlMuPC9zcGFuPjxvOnA+PC9v OnA+PC9saT48L3VsPg0KPC91bD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPioq KkJvdHRvbSBsaW5lLCB0aGUgZG9jdW1lbnQgaXMgbm90IHlldCByZWFkeSB0byBiZSBhcHByb3Zl ZC4qKiogKGV2ZW4gaWYgYmlnIHByb2dyZXNzIGhhcyBiZWVuIG1hZGUpPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5BcyB3cml0dGVuIGluIE5vdmVtYmVyIChzZWUgYmVsb3cpLCB0aGUgc2l0dWF0 aW9uIGhhcyBsaW5nZXJlZCBmb3IgdG9vIGxvbmcgYW5kIGlzIGJsb2NraW5nIHRoZSBISVAtTkFU IGFuZCByZmM0NDIzLWJpcyBkb2N1bWVudHMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPioq KiBUaGVyZWZvcmUsIEkgcmVxdWVzdCB0aGUgYXV0aG9ycyBmb3IgYSByZXZpc2VkIEktRCBhZGRy ZXNzaW5nIHRoZSBhYm92ZSAoYW5kIG5vdGluZyBhZ2FpbiB0aGF0IGEgY2hhbmdlIHRvIOKAmGV4 cGVyaW1lbnRhbOKAmSDigJMgYXMgdGhlcmUgYXJlIG5vIGRlcGxveWVkIGltcGxlbWVudGF0aW9u cyDigJMgY291bGQgcHJvYmFibHkgZml4IGFsbCBvZiB0aGVtKSBiZWZvcmUgVGh1cnNkYXkNCiAy MXN0IG9mIEphbnVhcnkgbWlkbmlnaHQgVVRDIGVsc2UgSSB3aWxsIGFzayB0aGUgSElQU0VDIFdH IHRvIGFncmVlIHJlbW92aW5nIHRoZSBISVAtREVYIHNlY3Rpb24gZnJvbSB0aGUgYXJjaGl0ZWN0 dXJlIGRvY3VtZW50LiAqKio8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFsbCBpbiBhbGwsIHRo ZXJlIGhhdmUgYmVlbiBhIGNvdXBsZSBvZiBzaWduaWZpY2FudCBjaGFuZ2VzIChJX05PTkNFLCBz b21lIGRlbGV0ZWQgY2lwaGVycykgc2luY2UgdGhlIElFVEYgbGFzdCBjYWxsIChzZWUNCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWhpcC1kZXgt MjMmYW1wO3VybDE9ZHJhZnQtaWV0Zi1oaXAtZGV4LTIxIj4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWhpcC1kZXgtMjMmYW1wO3VybDE9ZHJhZnQtaWV0Zi1o aXAtZGV4LTIxPC9hPiApLCBzbywgYW5vdGhlciBJRVRGIExhc3QgQ2FsbCBpcyByZXF1aXJlZCBi dXQgc2hvdWxkIG5vdCBiZSBhIHJlYWwgcHJvYmxlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj4tw6lyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RnJvbTogUm9iZXJ0IE1vc2tvd2l0 eiAmbHQ7cmdtQGxhYnMuaHR0LWNvbnN1bHQuY29tJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+RGF0ZTogVGh1cnNkYXksIDE0IEphbnVhcnkgMjAyMSBhdCAxNjow ODxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VG86IEVyaWMgVnluY2tl ICZsdDtldnluY2tlQGNpc2NvLmNvbSZndDssICZxdW90O0VyaWMgVnluY2tlIChldnluY2tlKSZx dW90OyAmbHQ7ZXZ5bmNrZT00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZyZndDssICZxdW90O2hp cHNlY0BpZXRmLm9yZyZxdW90OyAmbHQ7aGlwc2VjQGlldGYub3JnJmd0OywgJnF1b3Q7ZHJhZnQt aWV0Zi1oaXAtZGV4QGlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC1pZXRmLWhpcC1kZXhAaWV0Zi5v cmcmZ3Q7LCBNaWlrYSBLb211ICZsdDttaWlrYS5rb211QGVyaWNzc29uLmNvbSZndDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkNjOiBSb21hbiBEYW55bGl3ICZsdDty ZGRAY2VydC5vcmcmZ3Q7LCBFcmljIFJlc2NvcmxhICZsdDtla3JAcnRmbS5jb20mZ3Q7LCBHb256 YWxvIENhbWFyaWxsbyAmbHQ7Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tJmd0OywgJnF1 b3Q7cmVuZS5odW1tZW5AYmVsZGVuLmNvbSZxdW90OyAmbHQ7cmVuZS5odW1tZW5AYmVsZGVuLmNv bSZndDssIEJlbmphbWluIEthZHVrICZsdDtrYWR1a0BtaXQuZWR1Jmd0OywgRXJpayBLbGluZSAm bHQ7ZWsuaWV0ZkBnbWFpbC5jb20mZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5TdWJqZWN0OiBSZTogW0hpcHNlY10gTmVlZCB0byBjbG9zZSBhbGwgZHJhZnQtaWV0 Zi1oaXAtZGV4LTIxIHBlbmRpbmcgaXNzdWVzLi4uIGJlZm9yZSAyMDIxLUphbi0xMy4uLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIGhhZCBob3BlZCB0byBnZXQgLTIzIG91dCBlbmQg b2YgbGFzdCB3ZWVrLCBhbmQgbWlzc2VkIG15IGN1dG9mZi4mbmJzcDsgSSBhbSBub3cgaW4gSUFD UidzIFJlYWwgV29ybGQgQ3J5cHRvLCB3aGVyZSBJIGhhdmUgZ290dGVuIGEgY291cGxlIHBvaW50 ZXJzIGZvciBEUklQIHdvcmsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgd2FzIHdh aXRpbmcgZm9yIHR3byBhbmFseXplcyB0aGF0IEkgZ290IEphbiA0LCBhbmQgaW5jb3Jwb3JhdGlu ZyB0aGVtIGluLiZuYnNwOyBJIGJlbGlldmUgdGhlc2UgU0hPVUxEIGFkZHJlc3MgbXVjaCBvZiBF S1IncyBxdWVzdGlvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgd2lsbCBoYXZl IGEgcnVuIG9mIDFNIERFWCByYW5kb20gSElzIHRvIEhJVHMgZ2VuZXJhdGVkIHdpdGggbm8gZHVw bGljYXRlcyB0aGF0IEkgYWRkIGluIGFuIEFwcGVuZGl4IGFsb25nIHdpdGggdGhlIFB5dGhvbiBj b2RlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIGFtIGFkZGluZyBhIEJFWC9ERVgg Y3J5cHRvIGNvc3QgaW50byAxLjIsIHByb2JhYmx5IDEuMi4xOjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5Gb3IgYW4gSW5pdGlhdG9yLCBCRVggaXM6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjIgUEsgc2lnIHZhcmlmaWNhdGlvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4xIFBLIHNpZyBnZW5lcmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+MSBESCBrZXlwYWlyIGdlbmVyYXRpb24uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4xIERIIHNlY3JldCBkZXJpdmF0aW9uLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5ERVggaXM6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjEgREggc2VjcmV0IGRlcml2YXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPkkgaGF2ZSBjeWNsZXMgZm9yIHRoZXNlIGFuZCBhIHBhcGVyIHRvIHJlZmVyZW5jZSwgZXhj ZXB0IEVDREgga2V5cGFpciBnZW5lcmF0aW9uLCBvbiBhbiA4IGJpdCBwcm9jZXNzIGFuZCB0aGUg bnVtYmVycyBhcmUgYmlnLiZuYnNwOyBCdXQgSSB0aGluayB0aGF0IHBhcnQgYmVsb25ncyBpbiBh biBBcHBlbmRpeC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U28gdW5saWtlbHkgRnJp ZGF5LiZuYnNwOyBCdXQgZWFybHkgdGhlIGZvbGxvd2luZyB3ZWVrLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk9uIDEvMTIvMjEgNjoxOSBBTSwgRXJpYyBW eW5ja2UgKGV2eW5ja2UpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+VHdvIG1vbnRocyBhZnRlciB0aGUgZW1haWwgYmVsb3csIEkgc2VuZGluZyBhIGtpbmQg cmVtaW5kZXIgdG8gYXV0aG9ycyBhbmQgV0cuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PldpdGggdGhlIC0yMiwgYSBsb3Qgb2YgKGlmIG5vdCBhbGwgKSBTRUMgQURz4oCZIERJU0NVU1Mg cG9pbnRzIHNob3VsZCBoYXZlIGJlZW4gYWRkcmVzc2VkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5BcyBmYXIgYXMgSSBjYW4gdGVsbCwgdGhlIG90aGVyIHJlbWFpbmluZyBpc3N1ZSB3 YXMgRWty4oCZcyBvbmUgYWJvdXQgd2h5IGZvcmZlaXRpbmcgRlMgd2hlbiBzb21lIGFsZ29yaXRo bSBjb3VsZCBkbyBpdCBpbiBhIHJlYXNvbmFibGUgdGltZS4gSW4gYW4gZW1haWwgdG8gYXV0aG9y cyBhbmQgQURzLCBFcmljIFIuIHdyb3RlIOKAnGl0IGRlZmluZXMgYSBzZXQgb2YgcGFyYW1ldGVy cyAodGhlIE5JU1QgY3VydmVzKQ0KIHdoaWNoIGFyZSBzbG93ZXIgdy9vIEZTIHRoYW4gb3RoZXIg cGFyYW1ldGVycyAoWDI1NTE5KSBhcmUgdy8gRlMuIFRoaXMgZmFjdCBjYWxscyBpbnRvIHF1ZXN0 aW9uIHRoZSBuZWVkIHRvIGRpc3BlbnNlIHdpdGggRlMu4oCdPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPldoaWxlIDIgbW9udGhzIGFnbyBJIHB1dCBhIGRlYWRsaW5lIGZvciB0b21vcnJv dywgSSAoYXMgdGhlIHJlc3BvbnNpYmxlIEFEKSBhbSBmbGV4aWJsZSBvZiBjb3Vyc2UgYnV0IHdl IGNhbm5vdCBsaW5nZXIgYW55bW9yZS4gSSBrbm93IHRoYXQgYSAtMjMgaXMgaW4gdGhlIHdvcmsg Zm9yIHdlZWtzID0mZ3Q7IGxldOKAmXMgcHVibGlzaCBpdCBpbiB0aGUgY29taW5nIGRheXMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkVsc2UsIG5leHQgd2VlayB3ZSB3aWxsIG5lZWQg dG8gZWl0aGVyIGNoYW5nZSB0aGUgaW50ZW5kZWQgc3RhdHVzIHRvIGV4cGVyaW1lbnRhbCBvciBk ZWNsYXJlIHRoZSBkb2N1bWVudCBkZWFkIGJ5IGxhY2sgb2YgZW5lcmd5LiBUaGUgbGF0dGVyIGRv ZXMgbm90IGhhdmUgbXkgcHJlZmVyZW5jZSBvYnZpb3VzbHkuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LcOpcmljPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+RnJvbTogSGlwc2VjIG1haWx0bzpoaXBzZWMtYm91bmNlc0BpZXRm Lm9yZyBvbiBiZWhhbGYgb2YgJnF1b3Q7RXJpYyBWeW5ja2UgKGV2eW5ja2UpJnF1b3Q7IG1haWx0 bzpldnluY2tlPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5EYXRlOiBGcmlkYXksIDEzIE5vdmVtYmVyIDIwMjAgYXQgMTU6 MzI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRvOiBtYWlsdG86aGlw c2VjQGlldGYub3JnIG1haWx0bzpoaXBzZWNAaWV0Zi5vcmcsIG1haWx0bzpkcmFmdC1pZXRmLWhp cC1kZXhAaWV0Zi5vcmcgbWFpbHRvOmRyYWZ0LWlldGYtaGlwLWRleEBpZXRmLm9yZywgUm9iZXJ0 IE1vc2tvd2l0eiBtYWlsdG86cmdtQGxhYnMuaHR0LWNvbnN1bHQuY29tLCBNaWlrYSBLb211IG1h aWx0bzptaWlrYS5rb211QGVyaWNzc29uLmNvbTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Q2M6IFJvbWFuIERhbnlsaXcgbWFpbHRvOnJkZEBjZXJ0Lm9yZywgRXJpYyBS ZXNjb3JsYSBtYWlsdG86ZWtyQHJ0Zm0uY29tLCBHb256YWxvIENhbWFyaWxsbyBtYWlsdG86Z29u emFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tLCBtYWlsdG86cmVuZS5odW1tZW5AYmVsZGVuLmNv bSBtYWlsdG86cmVuZS5odW1tZW5AYmVsZGVuLmNvbSwgQmVuamFtaW4gS2FkdWsgbWFpbHRvOmth ZHVrQG1pdC5lZHUsIEVyaWsNCiBLbGluZSBtYWlsdG86ZWsuaWV0ZkBnbWFpbC5jb208bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlN1YmplY3Q6IFtIaXBzZWNdIE5lZWQg dG8gY2xvc2UgYWxsIGRyYWZ0LWlldGYtaGlwLWRleC0yMSBwZW5kaW5nIGlzc3Vlcy4uLiBiZWZv cmUgMjAyMS1KYW4tMTMuLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RGVhciBISVAs IGRlYXIgYXV0aG9ycyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhpcyBkb2N1bWVu dCB3YXMgcmVxdWVzdGVkIGZvciBwdWJsaWNhdGlvbiBbMV0gaW4gRmVicnVhcnkgMjAxOCAoMi41 IHllYXJzIGFnbyksIHRoZW4gaXRzIElFU0cgZXZhbHVhdGlvbiBoYXMgYmVlbiBkZWZlcnJlZCwg dGhlbiBJIHRvb2sgb3ZlciB0aGlzIGRvY3VtZW50IGZyb20gVGVycnkgTWFuZGVyc29uIGluIE1h cmNoIDIwMTksIHRoZW4gaXQgd2VudCBhZ2FpbiB0aHJvdWdoIElFU0cgZXZhbHVhdGlvbg0KIGlu IEp1bHkgMjAyMCBhbmQgdGhlcmUgYXJlIHN0aWxsIERJU0NVU1MgcG9pbnRzIHRvIGJlIGFkZHJl c3NlZCBldmVuIGFmdGVyIGEgY291cGxlIG9mIHJldmlzZWQgSS1ELi4uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPkRpZmZpY3VsdCBub3QgdG8gb2JzZXJ2ZSB0aGF0IHRoaXMgZG9jdW1l bnQgZG9lcyBub3QgcHJvZ3Jlc3MgdmVyeSBmYXN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5Nb3Jlb3ZlciwgdGhpcyBkb2N1bWVudCBpcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgZm9y IHJmYzQ0MjMtYmlzIHdhaXRpbmcgaW4gdGhlIFJGQyBlZGl0b3IgcXVldWUgc2luY2UgTWFyY2gg MjAxOS4uLiBTbywgYWxzbyBibG9ja2luZyB0aGUgSElQLU5BVCBkb2N1bWVudCBbMl0uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFmdGVyIGRpc2N1c3Npb24gd2l0aCB0aGUgSElQIGNo YWlyLCBHb256YWxvIGluIGNjLCB3ZSBoYXZlIHRha2VuIHRoZSBmb2xsb3dpbmcgZGVjaXNpb246 IGlmIGEgcmV2aXNlZCBJLUQgYWRkcmVzc2luZyByZW1haW5pbmcgRElTQ1VTUyBwb2ludHMgKyBF a3LigJlzIG9uZXMgaXMgbm90IHVwbG9hZGVkIHdpdGhpbiAyIG1vbnRocyAoMTN0aCBvZiBKYW51 YXJ5IDIwMjEpLCB0aGVuIEkgd2lsbCByZXF1ZXN0IHRoZQ0KIEhJUCBXRyB0byBhY2NlcHQgdGhl IGNvbXBsZXRlIHJlbW92YWwgb2Ygc2VjdGlvbiBBLjMuMyBvZiB0aGUgcmZjNDQyMy1iaXMgZG9j dW1lbnQgKDEgcGFnZSBhYm91dCBISVAtREVYIGluIHRoZSBhcHBlbmRpeCkgKyB0aGUgcmVmZXJl bmNlIHRvIHRoZSBISVAtREVYIGRvY3VtZW50IFszXS4gVGhpcyB3aWxsIGFsbG93IHRoZSBpbW1l ZGlhdGUgcHVibGljYXRpb24gb2YgdGhlIHJmYzQ0MjMtYmlzIGFuZCBISVAtTkFUIGRvY3VtZW50 cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIEhJUCBERVggYXV0aG9ycyBtYXkg YWxzbyBzZWxlY3QgdG8gY2hhbmdlIHRoZSBpbnRlbmRlZCBzdGF0dXMgb2YgdGhlIGRvY3VtZW50 IHRvIOKAmGV4cGVyaW1lbnRhbOKAmSAoaWYgdGhlIEhJUCBXRyBhZ3JlZXMpIGFzIHRoaXMgbWF5 IHJlZHVjZSB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGJ5IHRoZSBTRUMgQUQgYW5kIEVrci48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+R29uemFsbyBhbmQgSSBhcmUgc3RpbGwgaG9w aW5nIHRvIGdldCBhIHJldmlzZWQgSElQLURFWCBzaG9ydGx5LDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5SZWdhcmRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi3DqXJpYzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5bMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1oaXAtZGV4L2hpc3RvcnkvDQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPlsyXSBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9jbHVz dGVyX2luZm8ucGhwP2NpZD1DMzg2PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5bM10gYW5kIHBvc3NpYmx5IEkgd2lsbCBzZXQgdGhlIHN0YXRlIG9mIEhJUC1ERVggYXMg 4oCYZGVhZOKAmSBvbiB0aGUgZGF0YXRyYWNrZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLSA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJvYmVydCBNb3Nrb3dpdHo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk93bmVyPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IVFQgQ29uc3VsdGluZzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QzombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsyNDgtMjE5LTIwNTk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PkY6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7MjQ4LTk2OC0yODI0PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5FOiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO21haWx0bzpyZ21AbGFicy5odHQtY29uc3VsdC5jb208bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlcmUncyBubyBsaW1pdCB0byB3aGF0IGNhbiBiZSBhY2Nv bXBsaXNoZWQgaWYgaXQgZG9lc24ndCBtYXR0ZXIgd2hvIGdldHMgdGhlIGNyZWRpdDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_41AFBFEA7119451BBC5446CBB41274CAciscocom_-- From nobody Tue Jan 19 12:24:48 2021 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8E73A0928; Mon, 18 Jan 2021 08:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, 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 EDAdrw_vDIys; Mon, 18 Jan 2021 08:06:40 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 5AF113A0927; Mon, 18 Jan 2021 08:06:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 3FED3623C1; Mon, 18 Jan 2021 11:06:35 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aSCBLSyYG8XG; Mon, 18 Jan 2021 11:06:16 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 35D03622C2; Mon, 18 Jan 2021 11:06:15 -0500 (EST) To: "Eric Vyncke (evyncke)" , Robert Moskowitz , "hipsec@ietf.org" , "draft-ietf-hip-dex@ietf.org" , Miika Komu Cc: Roman Danyliw , Eric Rescorla , Gonzalo Camarillo , "rene.hummen@belden.com" , Benjamin Kaduk , Erik Kline , Adam Wiethuechter References: <68AF0368-8CB8-4DF3-A33E-0AA28E61B5F5@cisco.com> <45191baf-ee46-89b8-fe84-742c5c17aadc@labs.htt-consult.com> <41AFBFEA-7119-451B-BC54-46CBB41274CA@cisco.com> From: Robert Moskowitz Message-ID: <5f52aa64-48aa-87d3-5225-1741ca87b89d@htt-consult.com> Date: Mon, 18 Jan 2021 11:06:01 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <41AFBFEA-7119-451B-BC54-46CBB41274CA@cisco.com> Content-Type: multipart/alternative; boundary="------------E3C67E796303848A5E773791" Content-Language: en-US Archived-At: X-Mailman-Approved-At: Tue, 19 Jan 2021 12:24:34 -0800 Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13... X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 16:06:45 -0000 This is a multi-part message in MIME format. --------------E3C67E796303848A5E773791 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/18/21 9:12 AM, Eric Vyncke (evyncke) wrote: > Standard > > TD ;LR : more work to be done, deadline this Thursday 21st > > Bob, > > Thank you for the -23 (and Adam W for the footwork)and I understand > that you are quite busy. > > Here is the link to the diff between -21 and -23: > https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 > > (i.e., the one used by July 2020 IESG evaluation and the latest one) > > After the July 2020 IESG evaluation based on -21, there were a couple > of points to be addressed(with some comments of mine as EVY>): > > * Roman: “Section 6.3.  Per the definition of IKM, when should these > two different derivations be used? " > o EVY> indeed, IKMm and IKMp are both defined but nothing is > said which one to use in which case. >        IKM       IKMm for Master Key SA Input keying material                  or                  IKMp for Pair-wise Key SA Input keying material        IKMm      Kij | I_NONCE        IKMp      Kij | I_NONCE | (concatenated random values of the                      ENCRYPTED_KEY parameters in the same order as                      the HITs with sort(HIT-I | HIT-R)) Seems clear that IKMm is for the Master Key SA and IKMp is for the Pair-wise Key SA. > * Roman "discuss-discuss" (read this as request for reply and > non-blocking) about "further implementation experience provides > better guidance" in sections 6 and 9. > o EVY> this really pleads for experimental status > The only place this text exists anymore is in Appendix C:  iESG Considerations Perhaps I should delete it from there. > o > > > * Benjamin on FOLD collisions > o EVY> IMHO addressed in the new section 3.2.1 > I believe I have this covered.  We have the Python scripts for tests, but this is a lot of code to put into the document.  Right now it is privately held by Adam and I.  If called on, we can find some permanent home for it. > o > > > * Benjamin on ACL to counter FOLD collisions in section 3.2.1 > o EVY> still light on the ACL but the above should clear it > Sec 7.1 is referenced. > o > > > * Benjamin "how is it known that the peer should be using DEX vs. BEX" > o EVY> partially addressed in section 1.2 but should be repeated > in the security section > I can create a sec 9.1 (pushing down the current 9.1): 9.1 Caution on using HIP DEX rather than HIP BEX    Due to the substantially reduced security guarantees of HIP DEX    compared to HIP BEX, HIP DEX MUST only be used when at least one of    the two endpoints is a class 0 or 1 constrained device defined in    Section 3 of [RFC7228]).  HIP DEX MUST NOT be used when both    endpoints are class 2 devices or unconstrained. Will this work? > o > > > * Benjamin lack of discussion on the security consequences of > inadvertent counter reuse in AES-CTR > See sec 9.1 > * > > > * Benjamin "presence of a CSPRNG in order to obtain secure session keys" > 9.  Security Considerations ....    *  The strength of the keys for both the Master and Pair-wise Key SAs       is based on the quality of the random keying material generated by       the Initiator and the Responder.  As either peer may be a sensor       or an actuator device, there is a natural concern about the       quality of its random number generator.  Thus at least a CSPRNG       SHOULD be used. > * > > > > * Benjamin "usage of CMAC instead of HMAC" about KEYMAT algorithm > o EVY> new reference to NIST papers seems to address this concern > Ben did agree in an email that the SP800-56C and 108 addressed the concern.  I did not need to go further. > o > > > * Ekr’s one about why forfeiting FS when some algorithm could do it > in a reasonable time. In an email to authors and ADs, Eric R. > wrote “it defines a set of parameters (the NIST curves) which are > slower w/o FS than other parameters (X25519) are w/ FS. This fact > calls into question the need to dispense with FS.” > o EVY> the additional section 1.2.1 and the reference to a > paywall EfficientECC reference do not offer a conclusive > motivation for an IETF standards w/o FS. > Paywall?  Hmm.  I got it free.  I will have to check into this.  It may be to some cookie I have on this system.  Or the DOI has the wrong URL. Ah, that URL works for me because I am an IACR member.  For all else: https://link.springer.com/article/10.1007/s10623-015-0087-1 So I will change the reference.  But please check this out.  I tried it on another machine that should not have my IACR cookies, but... > o > > > > > ***Bottom line, the document is not yet ready to be approved.*** (even > if big progress has been made) > > As written in November (see below), the situation has lingered for too > long and is blocking the HIP-NAT and rfc4423-bis documents. > > *** Therefore, I request the authors for a revised I-D addressing the > above (and noting again that a change to ‘experimental’ – as there are > no deployed implementations – could probably fix all of them) before > Thursday 21st of January midnight UTC else I will ask the HIPSEC WG to > agree removing the HIP-DEX section from the architecture document. *** > Does the above address the open items? > All in all, there have been a couple of significant changes (I_NONCE, > some deleted ciphers) since the IETF last call (see > https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 > > ), so, another IETF Last Call is required but should not be a real > problem. > > -éric > > From: Robert Moskowitz > > Date: Thursday, 14 January 2021 at 16:08 > > To: Eric Vyncke , "Eric Vyncke (evyncke)" > , "hipsec@ietf.org" > , "draft-ietf-hip-dex@ietf.org" > , Miika Komu > > Cc: Roman Danyliw , Eric Rescorla , > Gonzalo Camarillo , > "rene.hummen@belden.com" , Benjamin Kaduk > , Erik Kline > > Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending > issues... before 2021-Jan-13... > > I had hoped to get -23 out end of last week, and missed my cutoff.  I > am now in IACR's Real World Crypto, where I have gotten a couple > pointers for DRIP work. > > I was waiting for two analyzes that I got Jan 4, and incorporating > them in.  I believe these SHOULD address much of EKR's questions. > > I will have a run of 1M DEX random HIs to HITs generated with no > duplicates that I add in an Appendix along with the Python code. > > I am adding a BEX/DEX crypto cost into 1.2, probably 1.2.1: > > For an Initiator, BEX is: > > 2 PK sig varifications. > > 1 PK sig generation. > > 1 DH keypair generation. > > 1 DH secret derivation. > > DEX is: > > 1 DH secret derivation. > > I have cycles for these and a paper to reference, except ECDH keypair > generation, on an 8 bit process and the numbers are big.  But I think > that part belongs in an Appendix. > > So unlikely Friday.  But early the following week. > > On 1/12/21 6:19 AM, Eric Vyncke (evyncke) wrote: > > Two months after the email below, I sending a kind reminder to authors > and WG. > > With the -22, a lot of (if not all ) SEC ADs’ DISCUSS points should > have been addressed. > > As far as I can tell, the other remaining issue was Ekr’s one about > why forfeiting FS when some algorithm could do it in a reasonable > time. In an email to authors and ADs, Eric R. wrote “it defines a set > of parameters (the NIST curves) which are slower w/o FS than other > parameters (X25519) are w/ FS. This fact calls into question the need > to dispense with FS.” > > While 2 months ago I put a deadline for tomorrow, I (as the > responsible AD) am flexible of course but we cannot linger anymore. I > know that a -23 is in the work for weeks => let’s publish it in the > coming days. > > Else, next week we will need to either change the intended status to > experimental or declare the document dead by lack of energy. The > latter does not have my preference obviously. > > Regards > > -éric > > From: Hipsec mailto:hipsec-bounces@ietf.org on behalf of "Eric Vyncke > (evyncke)" mailto:evyncke=40cisco.com@dmarc.ietf.org > > Date: Friday, 13 November 2020 at 15:32 > > To: mailto:hipsec@ietf.org mailto:hipsec@ietf.org, > mailto:draft-ietf-hip-dex@ietf.org mailto:draft-ietf-hip-dex@ietf.org, > Robert Moskowitz mailto:rgm@labs.htt-consult.com, Miika Komu > mailto:miika.komu@ericsson.com > > Cc: Roman Danyliw mailto:rdd@cert.org, Eric Rescorla > mailto:ekr@rtfm.com, Gonzalo Camarillo > mailto:gonzalo.camarillo@ericsson.com, mailto:rene.hummen@belden.com > mailto:rene.hummen@belden.com, Benjamin Kaduk mailto:kaduk@mit.edu, > Erik Kline mailto:ek.ietf@gmail.com > > Subject: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending > issues... before 2021-Jan-13... > > Dear HIP, dear authors, > > This document was requested for publication [1] in February 2018 (2.5 > years ago), then its IESG evaluation has been deferred, then I took > over this document from Terry Manderson in March 2019, then it went > again through IESG evaluation in July 2020 and there are still DISCUSS > points to be addressed even after a couple of revised I-D... > > Difficult not to observe that this document does not progress very fast. > > Moreover, this document is a normative reference for rfc4423-bis > waiting in the RFC editor queue since March 2019... So, also blocking > the HIP-NAT document [2]. > > After discussion with the HIP chair, Gonzalo in cc, we have taken the > following decision: if a revised I-D addressing remaining DISCUSS > points + Ekr’s ones is not uploaded within 2 months (13th of January > 2021), then I will request the HIP WG to accept the complete removal > of section A.3.3 of the rfc4423-bis document (1 page about HIP-DEX in > the appendix) + the reference to the HIP-DEX document [3]. This will > allow the immediate publication of the rfc4423-bis and HIP-NAT documents. > > The HIP DEX authors may also select to change the intended status of > the document to ‘experimental’ (if the HIP WG agrees) as this may > reduce the security requirements by the SEC AD and Ekr. > > Gonzalo and I are still hoping to get a revised HIP-DEX shortly, > > Regards > > -éric > > [1] https://datatracker.ietf.org/doc/draft-ietf-hip-dex/history/ > > [2] https://www.rfc-editor.org/cluster_info.php?cid=C386 > > [3] and possibly I will set the state of HIP-DEX as ‘dead’ on the > datatracker > > -- > > Robert Moskowitz > > Owner > > HTT Consulting > > C:      248-219-2059 > > F:      248-968-2824 > > E:      mailto:rgm@labs.htt-consult.com > > There's no limit to what can be accomplished if it doesn't matter who > gets the credit > --------------E3C67E796303848A5E773791 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 1/18/21 9:12 AM, Eric Vyncke (evyncke) wrote:
Standard

TD ;LR : more work to be done, deadline this Thursday 21st

 

Bob,

 

Thank you for the -23 (and Adam W for the footwork) and I understand that you are quite busy.

 

Here is the link to the diff between -21 and -23: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 (i.e., the one used by July 2020 IESG evaluation and the latest one)

 

After the July 2020 IESG evaluation based on -21, there were a couple of points to be addressed (with some comments of mine as EVY>):

  • Roman: “Section 6.3.  Per the definition of IKM, when should these two different derivations be used? "
    • EVY> indeed, IKMm and IKMp are both defined but nothing is said which one to use in which case.

       IKM       IKMm for Master Key SA Input keying material
                 or
                 IKMp for Pair-wise Key SA Input keying material

       IKMm      Kij | I_NONCE
       IKMp      Kij | I_NONCE | (concatenated random values of the
                     ENCRYPTED_KEY parameters in the same order as
                     the HITs with sort(HIT-I | HIT-R))

Seems clear that IKMm is for the Master Key SA and IKMp is for the Pair-wise Key SA.

  • Roman "discuss-discuss" (read this as request for reply and non-blocking) about " further implementation experience provides better guidance" in sections 6 and 9.
    • EVY> this really pleads for experimental status

The only place this text exists anymore is in Appendix C:  iESG Considerations

Perhaps I should delete it from there.


  • Benjamin on FOLD collisions
    • EVY> IMHO addressed in the new section 3.2.1

I believe I have this covered.  We have the Python scripts for tests, but this is a lot of code to put into the document.  Right now it is privately held by Adam and I.  If called on, we can find some permanent home for it.


  • Benjamin on ACL to counter FOLD collisions in section 3.2.1
    • EVY> still light on the ACL but the above should clear it

Sec 7.1 is referenced.


  • Benjamin "how is it known that the peer should be using DEX vs. BEX"
    • EVY> partially addressed in section 1.2 but should be repeated in the security section

I can create a sec 9.1 (pushing down the current 9.1):

9.1 Caution on using HIP DEX rather than HIP BEX

   Due to the substantially reduced security guarantees of HIP DEX
   compared to HIP BEX, HIP DEX MUST only be used when at least one of
   the two endpoints is a class 0 or 1 constrained device defined in
   Section 3 of [RFC7228]).  HIP DEX MUST NOT be used when both
   endpoints are class 2 devices or unconstrained.


Will this work?


  • Benjamin lack of discussion on the security consequences of inadvertent counter reuse in AES-CTR

See sec 9.1


  • Benjamin "presence of a CSPRNG in order to obtain secure session keys"

9.  Security Considerations

....

   *  The strength of the keys for both the Master and Pair-wise Key SAs
      is based on the quality of the random keying material generated by
      the Initiator and the Responder.  As either peer may be a sensor
      or an actuator device, there is a natural concern about the
      quality of its random number generator.  Thus at least a CSPRNG
      SHOULD be used.



  • Benjamin "usage of CMAC instead of HMAC" about KEYMAT algorithm
    • EVY> new reference to NIST papers seems to address this concern

Ben did agree in an email that the SP800-56C and 108 addressed the concern.  I did not need to go further.


  • Ekr’s one about why forfeiting FS when some algorithm could do it in a reasonable time. In an email to authors and ADs, Eric R. wrote “it defines a set of parameters (the NIST curves) which are slower w/o FS than other parameters (X25519) are w/ FS. This fact calls into question the need to dispense with FS.”
    • EVY> the additional section 1.2.1 and the reference to a paywall EfficientECC reference do not offer a conclusive motivation for an IETF standards w/o FS.

Paywall?  Hmm.  I got it free.  I will have to check into this.  It may be to some cookie I have on this system.  Or the DOI has the wrong URL.

Ah, that URL works for me because I am an IACR member.  For all else:

https://link.springer.com/article/10.1007/s10623-015-0087-1

So I will change the reference.  But please check this out.  I tried it on another machine that should not have my IACR cookies, but...




 

***Bottom line, the document is not yet ready to be approved.*** (even if big progress has been made)

 

As written in November (see below), the situation has lingered for too long and is blocking the HIP-NAT and rfc4423-bis documents.

 

*** Therefore, I request the authors for a revised I-D addressing the above (and noting again that a change to ‘experimental’ – as there are no deployed implementations – could probably fix all of them) before Thursday 21st of January midnight UTC else I will ask the HIPSEC WG to agree removing the HIP-DEX section from the architecture document. ***


Does the above address the open items?

 

All in all, there have been a couple of significant changes (I_NONCE, some deleted ciphers) since the IETF last call (see https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 ), so, another IETF Last Call is required but should not be a real problem.

 

 

-éric

 

 

 

From: Robert Moskowitz <rgm@labs.htt-consult.com>

Date: Thursday, 14 January 2021 at 16:08

To: Eric Vyncke <evyncke@cisco.com>, "Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>, "hipsec@ietf.org" <hipsec@ietf.org>, "draft-ietf-hip-dex@ietf.org" <draft-ietf-hip-dex@ietf.org>, Miika Komu <miika.komu@ericsson.com>

Cc: Roman Danyliw <rdd@cert.org>, Eric Rescorla <ekr@rtfm.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "rene.hummen@belden.com" <rene.hummen@belden.com>, Benjamin Kaduk <kaduk@mit.edu>, Erik Kline <ek.ietf@gmail.com>

Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...

 

I had hoped to get -23 out end of last week, and missed my cutoff.  I am now in IACR's Real World Crypto, where I have gotten a couple pointers for DRIP work.

 

I was waiting for two analyzes that I got Jan 4, and incorporating them in.  I believe these SHOULD address much of EKR's questions.

 

I will have a run of 1M DEX random HIs to HITs generated with no duplicates that I add in an Appendix along with the Python code.

 

I am adding a BEX/DEX crypto cost into 1.2, probably 1.2.1:

 

For an Initiator, BEX is:

 

2 PK sig varifications.

1 PK sig generation.

1 DH keypair generation.

1 DH secret derivation.

 

DEX is:

 

1 DH secret derivation.

 

I have cycles for these and a paper to reference, except ECDH keypair generation, on an 8 bit process and the numbers are big.  But I think that part belongs in an Appendix.

 

So unlikely Friday.  But early the following week.

 

 

 

 

 

On 1/12/21 6:19 AM, Eric Vyncke (evyncke) wrote:

Two months after the email below, I sending a kind reminder to authors and WG.

 

With the -22, a lot of (if not all ) SEC ADs’ DISCUSS points should have been addressed.

 

As far as I can tell, the other remaining issue was Ekr’s one about why forfeiting FS when some algorithm could do it in a reasonable time. In an email to authors and ADs, Eric R. wrote “it defines a set of parameters (the NIST curves) which are slower w/o FS than other parameters (X25519) are w/ FS. This fact calls into question the need to dispense with FS.”

 

While 2 months ago I put a deadline for tomorrow, I (as the responsible AD) am flexible of course but we cannot linger anymore. I know that a -23 is in the work for weeks => let’s publish it in the coming days.

 

Else, next week we will need to either change the intended status to experimental or declare the document dead by lack of energy. The latter does not have my preference obviously.

 

Regards

 

-éric

 

 

From: Hipsec mailto:hipsec-bounces@ietf.org on behalf of "Eric Vyncke (evyncke)" mailto:evyncke=40cisco.com@dmarc.ietf.org

Date: Friday, 13 November 2020 at 15:32

To: mailto:hipsec@ietf.org mailto:hipsec@ietf.org, mailto:draft-ietf-hip-dex@ietf.org mailto:draft-ietf-hip-dex@ietf.org, Robert Moskowitz mailto:rgm@labs.htt-consult.com, Miika Komu mailto:miika.komu@ericsson.com

Cc: Roman Danyliw mailto:rdd@cert.org, Eric Rescorla mailto:ekr@rtfm.com, Gonzalo Camarillo mailto:gonzalo.camarillo@ericsson.com, mailto:rene.hummen@belden.com mailto:rene.hummen@belden.com, Benjamin Kaduk mailto:kaduk@mit.edu, Erik Kline mailto:ek.ietf@gmail.com

Subject: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...

 

Dear HIP, dear authors,

 

This document was requested for publication [1] in February 2018 (2.5 years ago), then its IESG evaluation has been deferred, then I took over this document from Terry Manderson in March 2019, then it went again through IESG evaluation in July 2020 and there are still DISCUSS points to be addressed even after a couple of revised I-D...

 

Difficult not to observe that this document does not progress very fast.

 

Moreover, this document is a normative reference for rfc4423-bis waiting in the RFC editor queue since March 2019... So, also blocking the HIP-NAT document [2].

 

After discussion with the HIP chair, Gonzalo in cc, we have taken the following decision: if a revised I-D addressing remaining DISCUSS points + Ekr’s ones is not uploaded within 2 months (13th of January 2021), then I will request the HIP WG to accept the complete removal of section A.3.3 of the rfc4423-bis document (1 page about HIP-DEX in the appendix) + the reference to the HIP-DEX document [3]. This will allow the immediate publication of the rfc4423-bis and HIP-NAT documents.

 

The HIP DEX authors may also select to change the intended status of the document to ‘experimental’ (if the HIP WG agrees) as this may reduce the security requirements by the SEC AD and Ekr.

 

Gonzalo and I are still hoping to get a revised HIP-DEX shortly,

 

Regards

 

-éric

 

[1] https://datatracker.ietf.org/doc/draft-ietf-hip-dex/history/

[2] https://www.rfc-editor.org/cluster_info.php?cid=C386

[3] and possibly I will set the state of HIP-DEX as ‘dead’ on the datatracker

 

 

--

Robert Moskowitz

Owner

HTT Consulting

C:      248-219-2059

F:      248-968-2824

E:      mailto:rgm@labs.htt-consult.com

 

There's no limit to what can be accomplished if it doesn't matter who gets the credit


--------------E3C67E796303848A5E773791-- From nobody Tue Jan 19 12:24:52 2021 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934FC3A0983; Mon, 18 Jan 2021 08:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, 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 uJmV5UFXk4RR; Mon, 18 Jan 2021 08:14:02 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 A3F6A3A096C; Mon, 18 Jan 2021 08:14:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 0B57E623C1; Mon, 18 Jan 2021 11:13:59 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id coZr9B8K8cYW; Mon, 18 Jan 2021 11:13:20 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 439EC622C2; Mon, 18 Jan 2021 11:13:20 -0500 (EST) From: Robert Moskowitz To: "Eric Vyncke (evyncke)" , Robert Moskowitz , "hipsec@ietf.org" , "draft-ietf-hip-dex@ietf.org" , Miika Komu Cc: Roman Danyliw , Eric Rescorla , Gonzalo Camarillo , "rene.hummen@belden.com" , Benjamin Kaduk , Erik Kline , Adam Wiethuechter References: <68AF0368-8CB8-4DF3-A33E-0AA28E61B5F5@cisco.com> <45191baf-ee46-89b8-fe84-742c5c17aadc@labs.htt-consult.com> <41AFBFEA-7119-451B-BC54-46CBB41274CA@cisco.com> <5f52aa64-48aa-87d3-5225-1741ca87b89d@htt-consult.com> Message-ID: <769d84b8-0e9f-dc8d-ee3e-62e724a830fc@htt-consult.com> Date: Mon, 18 Jan 2021 11:13:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <5f52aa64-48aa-87d3-5225-1741ca87b89d@htt-consult.com> Content-Type: multipart/alternative; boundary="------------456236479009BEE58656548A" Content-Language: en-US Archived-At: X-Mailman-Approved-At: Tue, 19 Jan 2021 12:24:34 -0800 Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13... X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 16:14:09 -0000 This is a multi-part message in MIME format. --------------456236479009BEE58656548A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Oops hold it on that paywall URL issue.  I responded with a different paper.  All else is still ok, but let me dig a big more on that paper for non-IACR members. On 1/18/21 11:06 AM, Robert Moskowitz wrote: > > > On 1/18/21 9:12 AM, Eric Vyncke (evyncke) wrote: >> Standard >> >> TD ;LR : more work to be done, deadline this Thursday 21st >> >> Bob, >> >> Thank you for the -23 (and Adam W for the footwork)and I understand >> that you are quite busy. >> >> Here is the link to the diff between -21 and -23: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 >> >> (i.e., the one used by July 2020 IESG evaluation and the latest one) >> >> After the July 2020 IESG evaluation based on -21, there were a couple >> of points to be addressed(with some comments of mine as EVY>): >> >> * Roman: “Section 6.3.  Per the definition of IKM, when should >> these two different derivations be used? " >> o EVY> indeed, IKMm and IKMp are both defined but nothing is >> said which one to use in which case. >> > >        IKM       IKMm for Master Key SA Input keying material >                  or >                  IKMp for Pair-wise Key SA Input keying material > >        IKMm      Kij | I_NONCE >        IKMp      Kij | I_NONCE | (concatenated random values of the >                      ENCRYPTED_KEY parameters in the same order as >                      the HITs with sort(HIT-I | HIT-R)) > > Seems clear that IKMm is for the Master Key SA and IKMp is for the > Pair-wise Key SA. > >> * Roman "discuss-discuss" (read this as request for reply and >> non-blocking) about "further implementation experience provides >> better guidance" in sections 6 and 9. >> o EVY> this really pleads for experimental status >> > > The only place this text exists anymore is in Appendix C:  iESG > Considerations > > Perhaps I should delete it from there. > >> o >> >> >> * Benjamin on FOLD collisions >> o EVY> IMHO addressed in the new section 3.2.1 >> > > I believe I have this covered.  We have the Python scripts for tests, > but this is a lot of code to put into the document.  Right now it is > privately held by Adam and I.  If called on, we can find some > permanent home for it. > >> o >> >> >> * Benjamin on ACL to counter FOLD collisions in section 3.2.1 >> o EVY> still light on the ACL but the above should clear it >> > > Sec 7.1 is referenced. > >> o >> >> >> * Benjamin "how is it known that the peer should be using DEX vs. BEX" >> o EVY> partially addressed in section 1.2 but should be >> repeated in the security section >> > > I can create a sec 9.1 (pushing down the current 9.1): > > 9.1 Caution on using HIP DEX rather than HIP BEX > >    Due to the substantially reduced security guarantees of HIP DEX >    compared to HIP BEX, HIP DEX MUST only be used when at least one of >    the two endpoints is a class 0 or 1 constrained device defined in >    Section 3 of [RFC7228]).  HIP DEX MUST NOT be used when both >    endpoints are class 2 devices or unconstrained. > > > Will this work? > >> o >> >> >> * Benjamin lack of discussion on the security consequences of >> inadvertent counter reuse in AES-CTR >> > > See sec 9.1 > >> * >> >> >> * Benjamin "presence of a CSPRNG in order to obtain secure session >> keys" >> > > 9.  Security Considerations > > .... > >    *  The strength of the keys for both the Master and Pair-wise Key SAs >       is based on the quality of the random keying material generated by >       the Initiator and the Responder.  As either peer may be a sensor >       or an actuator device, there is a natural concern about the >       quality of its random number generator.  Thus at least a CSPRNG >       SHOULD be used. > > >> * >> >> >> >> * Benjamin "usage of CMAC instead of HMAC" about KEYMAT algorithm >> o EVY> new reference to NIST papers seems to address this concern >> > > Ben did agree in an email that the SP800-56C and 108 addressed the > concern.  I did not need to go further. > >> o >> >> >> * Ekr’s one about why forfeiting FS when some algorithm could do it >> in a reasonable time. In an email to authors and ADs, Eric R. >> wrote “it defines a set of parameters (the NIST curves) which are >> slower w/o FS than other parameters (X25519) are w/ FS. This fact >> calls into question the need to dispense with FS.” >> o EVY> the additional section 1.2.1 and the reference to a >> paywall EfficientECC reference do not offer a conclusive >> motivation for an IETF standards w/o FS. >> > > Paywall?  Hmm.  I got it free.  I will have to check into this. It may > be to some cookie I have on this system.  Or the DOI has the wrong URL. > > Ah, that URL works for me because I am an IACR member.  For all else: > > https://link.springer.com/article/10.1007/s10623-015-0087-1 > > So I will change the reference.  But please check this out.  I tried > it on another machine that should not have my IACR cookies, but... > > > >> o >> >> >> >> >> ***Bottom line, the document is not yet ready to be approved.*** >> (even if big progress has been made) >> >> As written in November (see below), the situation has lingered for >> too long and is blocking the HIP-NAT and rfc4423-bis documents. >> >> *** Therefore, I request the authors for a revised I-D addressing the >> above (and noting again that a change to ‘experimental’ – as there >> are no deployed implementations – could probably fix all of them) >> before Thursday 21st of January midnight UTC else I will ask the >> HIPSEC WG to agree removing the HIP-DEX section from the architecture >> document. *** >> > > Does the above address the open items? > >> All in all, there have been a couple of significant changes (I_NONCE, >> some deleted ciphers) since the IETF last call (see >> https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 >> >> ), so, another IETF Last Call is required but should not be a real >> problem. >> >> -éric >> >> From: Robert Moskowitz >> >> Date: Thursday, 14 January 2021 at 16:08 >> >> To: Eric Vyncke , "Eric Vyncke (evyncke)" >> , "hipsec@ietf.org" >> , "draft-ietf-hip-dex@ietf.org" >> , Miika Komu >> >> Cc: Roman Danyliw , Eric Rescorla , >> Gonzalo Camarillo , >> "rene.hummen@belden.com" , Benjamin Kaduk >> , Erik Kline >> >> Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending >> issues... before 2021-Jan-13... >> >> I had hoped to get -23 out end of last week, and missed my cutoff.  I >> am now in IACR's Real World Crypto, where I have gotten a couple >> pointers for DRIP work. >> >> I was waiting for two analyzes that I got Jan 4, and incorporating >> them in.  I believe these SHOULD address much of EKR's questions. >> >> I will have a run of 1M DEX random HIs to HITs generated with no >> duplicates that I add in an Appendix along with the Python code. >> >> I am adding a BEX/DEX crypto cost into 1.2, probably 1.2.1: >> >> For an Initiator, BEX is: >> >> 2 PK sig varifications. >> >> 1 PK sig generation. >> >> 1 DH keypair generation. >> >> 1 DH secret derivation. >> >> DEX is: >> >> 1 DH secret derivation. >> >> I have cycles for these and a paper to reference, except ECDH keypair >> generation, on an 8 bit process and the numbers are big.  But I think >> that part belongs in an Appendix. >> >> So unlikely Friday.  But early the following week. >> >> On 1/12/21 6:19 AM, Eric Vyncke (evyncke) wrote: >> >> Two months after the email below, I sending a kind reminder to >> authors and WG. >> >> With the -22, a lot of (if not all ) SEC ADs’ DISCUSS points should >> have been addressed. >> >> As far as I can tell, the other remaining issue was Ekr’s one about >> why forfeiting FS when some algorithm could do it in a reasonable >> time. In an email to authors and ADs, Eric R. wrote “it defines a set >> of parameters (the NIST curves) which are slower w/o FS than other >> parameters (X25519) are w/ FS. This fact calls into question the need >> to dispense with FS.” >> >> While 2 months ago I put a deadline for tomorrow, I (as the >> responsible AD) am flexible of course but we cannot linger anymore. I >> know that a -23 is in the work for weeks => let’s publish it in the >> coming days. >> >> Else, next week we will need to either change the intended status to >> experimental or declare the document dead by lack of energy. The >> latter does not have my preference obviously. >> >> Regards >> >> -éric >> >> From: Hipsec mailto:hipsec-bounces@ietf.org on behalf of "Eric Vyncke >> (evyncke)" mailto:evyncke=40cisco.com@dmarc.ietf.org >> >> Date: Friday, 13 November 2020 at 15:32 >> >> To: mailto:hipsec@ietf.org mailto:hipsec@ietf.org, >> mailto:draft-ietf-hip-dex@ietf.org >> mailto:draft-ietf-hip-dex@ietf.org, Robert Moskowitz >> mailto:rgm@labs.htt-consult.com, Miika Komu >> mailto:miika.komu@ericsson.com >> >> Cc: Roman Danyliw mailto:rdd@cert.org, Eric Rescorla >> mailto:ekr@rtfm.com, Gonzalo Camarillo >> mailto:gonzalo.camarillo@ericsson.com, mailto:rene.hummen@belden.com >> mailto:rene.hummen@belden.com, Benjamin Kaduk mailto:kaduk@mit.edu, >> Erik Kline mailto:ek.ietf@gmail.com >> >> Subject: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending >> issues... before 2021-Jan-13... >> >> Dear HIP, dear authors, >> >> This document was requested for publication [1] in February 2018 (2.5 >> years ago), then its IESG evaluation has been deferred, then I took >> over this document from Terry Manderson in March 2019, then it went >> again through IESG evaluation in July 2020 and there are still >> DISCUSS points to be addressed even after a couple of revised I-D... >> >> Difficult not to observe that this document does not progress very fast. >> >> Moreover, this document is a normative reference for rfc4423-bis >> waiting in the RFC editor queue since March 2019... So, also blocking >> the HIP-NAT document [2]. >> >> After discussion with the HIP chair, Gonzalo in cc, we have taken the >> following decision: if a revised I-D addressing remaining DISCUSS >> points + Ekr’s ones is not uploaded within 2 months (13th of January >> 2021), then I will request the HIP WG to accept the complete removal >> of section A.3.3 of the rfc4423-bis document (1 page about HIP-DEX in >> the appendix) + the reference to the HIP-DEX document [3]. This will >> allow the immediate publication of the rfc4423-bis and HIP-NAT documents. >> >> The HIP DEX authors may also select to change the intended status of >> the document to ‘experimental’ (if the HIP WG agrees) as this may >> reduce the security requirements by the SEC AD and Ekr. >> >> Gonzalo and I are still hoping to get a revised HIP-DEX shortly, >> >> Regards >> >> -éric >> >> [1] https://datatracker.ietf.org/doc/draft-ietf-hip-dex/history/ >> >> [2] https://www.rfc-editor.org/cluster_info.php?cid=C386 >> >> [3] and possibly I will set the state of HIP-DEX as ‘dead’ on the >> datatracker >> >> -- >> >> Robert Moskowitz >> >> Owner >> >> HTT Consulting >> >> C:      248-219-2059 >> >> F:      248-968-2824 >> >> E: mailto:rgm@labs.htt-consult.com >> >> There's no limit to what can be accomplished if it doesn't matter who >> gets the credit >> > --------------456236479009BEE58656548A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Oops hold it on that paywall URL issue.  I responded with a different paper.  All else is still ok, but let me dig a big more on that paper for non-IACR members.

On 1/18/21 11:06 AM, Robert Moskowitz wrote:


On 1/18/21 9:12 AM, Eric Vyncke (evyncke) wrote:
Standard

TD ;LR : more work to be done, deadline this Thursday 21st

 

Bob,

 

Thank you for the -23 (and Adam W for the footwork) and I understand that you are quite busy.

 

Here is the link to the diff between -21 and -23: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 (i.e., the one used by July 2020 IESG evaluation and the latest one)

 

After the July 2020 IESG evaluation based on -21, there were a couple of points to be addressed (with some comments of mine as EVY>):

  • Roman: “Section 6.3.  Per the definition of IKM, when should these two different derivations be used? "
    • EVY> indeed, IKMm and IKMp are both defined but nothing is said which one to use in which case.

       IKM       IKMm for Master Key SA Input keying material
                 or
                 IKMp for Pair-wise Key SA Input keying material

       IKMm      Kij | I_NONCE
       IKMp      Kij | I_NONCE | (concatenated random values of the
                     ENCRYPTED_KEY parameters in the same order as
                     the HITs with sort(HIT-I | HIT-R))

Seems clear that IKMm is for the Master Key SA and IKMp is for the Pair-wise Key SA.

  • Roman "discuss-discuss" (read this as request for reply and non-blocking) about " further implementation experience provides better guidance" in sections 6 and 9.
    • EVY> this really pleads for experimental status

The only place this text exists anymore is in Appendix C:  iESG Considerations

Perhaps I should delete it from there.


  • Benjamin on FOLD collisions
    • EVY> IMHO addressed in the new section 3.2.1

I believe I have this covered.  We have the Python scripts for tests, but this is a lot of code to put into the document.  Right now it is privately held by Adam and I.  If called on, we can find some permanent home for it.


  • Benjamin on ACL to counter FOLD collisions in section 3.2.1
    • EVY> still light on the ACL but the above should clear it

Sec 7.1 is referenced.


  • Benjamin "how is it known that the peer should be using DEX vs. BEX"
    • EVY> partially addressed in section 1.2 but should be repeated in the security section

I can create a sec 9.1 (pushing down the current 9.1):

9.1 Caution on using HIP DEX rather than HIP BEX

   Due to the substantially reduced security guarantees of HIP DEX
   compared to HIP BEX, HIP DEX MUST only be used when at least one of
   the two endpoints is a class 0 or 1 constrained device defined in
   Section 3 of [RFC7228]).  HIP DEX MUST NOT be used when both
   endpoints are class 2 devices or unconstrained.


Will this work?


  • Benjamin lack of discussion on the security consequences of inadvertent counter reuse in AES-CTR

See sec 9.1


  • Benjamin "presence of a CSPRNG in order to obtain secure session keys"

9.  Security Considerations

....

   *  The strength of the keys for both the Master and Pair-wise Key SAs
      is based on the quality of the random keying material generated by
      the Initiator and the Responder.  As either peer may be a sensor
      or an actuator device, there is a natural concern about the
      quality of its random number generator.  Thus at least a CSPRNG
      SHOULD be used.



  • Benjamin "usage of CMAC instead of HMAC" about KEYMAT algorithm
    • EVY> new reference to NIST papers seems to address this concern

Ben did agree in an email that the SP800-56C and 108 addressed the concern.  I did not need to go further.


  • Ekr’s one about why forfeiting FS when some algorithm could do it in a reasonable time. In an email to authors and ADs, Eric R. wrote “it defines a set of parameters (the NIST curves) which are slower w/o FS than other parameters (X25519) are w/ FS. This fact calls into question the need to dispense with FS.”
    • EVY> the additional section 1.2.1 and the reference to a paywall EfficientECC reference do not offer a conclusive motivation for an IETF standards w/o FS.

Paywall?  Hmm.  I got it free.  I will have to check into this.  It may be to some cookie I have on this system.  Or the DOI has the wrong URL.

Ah, that URL works for me because I am an IACR member.  For all else:

https://link.springer.com/article/10.1007/s10623-015-0087-1

So I will change the reference.  But please check this out.  I tried it on another machine that should not have my IACR cookies, but...




 

***Bottom line, the document is not yet ready to be approved.*** (even if big progress has been made)

 

As written in November (see below), the situation has lingered for too long and is blocking the HIP-NAT and rfc4423-bis documents.

 

*** Therefore, I request the authors for a revised I-D addressing the above (and noting again that a change to ‘experimental’ – as there are no deployed implementations – could probably fix all of them) before Thursday 21st of January midnight UTC else I will ask the HIPSEC WG to agree removing the HIP-DEX section from the architecture document. ***


Does the above address the open items?

 

All in all, there have been a couple of significant changes (I_NONCE, some deleted ciphers) since the IETF last call (see https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 ), so, another IETF Last Call is required but should not be a real problem.

 

 

-éric

 

 

 

From: Robert Moskowitz <rgm@labs.htt-consult.com>

Date: Thursday, 14 January 2021 at 16:08

To: Eric Vyncke <evyncke@cisco.com>, "Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>, "hipsec@ietf.org" <hipsec@ietf.org>, "draft-ietf-hip-dex@ietf.org" <draft-ietf-hip-dex@ietf.org>, Miika Komu <miika.komu@ericsson.com>

Cc: Roman Danyliw <rdd@cert.org>, Eric Rescorla <ekr@rtfm.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "rene.hummen@belden.com" <rene.hummen@belden.com>, Benjamin Kaduk <kaduk@mit.edu>, Erik Kline <ek.ietf@gmail.com>

Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...

 

I had hoped to get -23 out end of last week, and missed my cutoff.  I am now in IACR's Real World Crypto, where I have gotten a couple pointers for DRIP work.

 

I was waiting for two analyzes that I got Jan 4, and incorporating them in.  I believe these SHOULD address much of EKR's questions.

 

I will have a run of 1M DEX random HIs to HITs generated with no duplicates that I add in an Appendix along with the Python code.

 

I am adding a BEX/DEX crypto cost into 1.2, probably 1.2.1:

 

For an Initiator, BEX is:

 

2 PK sig varifications.

1 PK sig generation.

1 DH keypair generation.

1 DH secret derivation.

 

DEX is:

 

1 DH secret derivation.

 

I have cycles for these and a paper to reference, except ECDH keypair generation, on an 8 bit process and the numbers are big.  But I think that part belongs in an Appendix.

 

So unlikely Friday.  But early the following week.

 

 

 

 

 

On 1/12/21 6:19 AM, Eric Vyncke (evyncke) wrote:

Two months after the email below, I sending a kind reminder to authors and WG.

 

With the -22, a lot of (if not all ) SEC ADs’ DISCUSS points should have been addressed.

 

As far as I can tell, the other remaining issue was Ekr’s one about why forfeiting FS when some algorithm could do it in a reasonable time. In an email to authors and ADs, Eric R. wrote “it defines a set of parameters (the NIST curves) which are slower w/o FS than other parameters (X25519) are w/ FS. This fact calls into question the need to dispense with FS.”

 

While 2 months ago I put a deadline for tomorrow, I (as the responsible AD) am flexible of course but we cannot linger anymore. I know that a -23 is in the work for weeks => let’s publish it in the coming days.

 

Else, next week we will need to either change the intended status to experimental or declare the document dead by lack of energy. The latter does not have my preference obviously.

 

Regards

 

-éric

 

 

From: Hipsec mailto:hipsec-bounces@ietf.org on behalf of "Eric Vyncke (evyncke)" mailto:evyncke=40cisco.com@dmarc.ietf.org

Date: Friday, 13 November 2020 at 15:32

To: mailto:hipsec@ietf.org mailto:hipsec@ietf.org, mailto:draft-ietf-hip-dex@ietf.org mailto:draft-ietf-hip-dex@ietf.org, Robert Moskowitz mailto:rgm@labs.htt-consult.com, Miika Komu mailto:miika.komu@ericsson.com

Cc: Roman Danyliw mailto:rdd@cert.org, Eric Rescorla mailto:ekr@rtfm.com, Gonzalo Camarillo mailto:gonzalo.camarillo@ericsson.com, mailto:rene.hummen@belden.com mailto:rene.hummen@belden.com, Benjamin Kaduk mailto:kaduk@mit.edu, Erik Kline mailto:ek.ietf@gmail.com

Subject: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...

 

Dear HIP, dear authors,

 

This document was requested for publication [1] in February 2018 (2.5 years ago), then its IESG evaluation has been deferred, then I took over this document from Terry Manderson in March 2019, then it went again through IESG evaluation in July 2020 and there are still DISCUSS points to be addressed even after a couple of revised I-D...

 

Difficult not to observe that this document does not progress very fast.

 

Moreover, this document is a normative reference for rfc4423-bis waiting in the RFC editor queue since March 2019... So, also blocking the HIP-NAT document [2].

 

After discussion with the HIP chair, Gonzalo in cc, we have taken the following decision: if a revised I-D addressing remaining DISCUSS points + Ekr’s ones is not uploaded within 2 months (13th of January 2021), then I will request the HIP WG to accept the complete removal of section A.3.3 of the rfc4423-bis document (1 page about HIP-DEX in the appendix) + the reference to the HIP-DEX document [3]. This will allow the immediate publication of the rfc4423-bis and HIP-NAT documents.

 

The HIP DEX authors may also select to change the intended status of the document to ‘experimental’ (if the HIP WG agrees) as this may reduce the security requirements by the SEC AD and Ekr.

 

Gonzalo and I are still hoping to get a revised HIP-DEX shortly,

 

Regards

 

-éric

 

[1] https://datatracker.ietf.org/doc/draft-ietf-hip-dex/history/

[2] https://www.rfc-editor.org/cluster_info.php?cid=C386

[3] and possibly I will set the state of HIP-DEX as ‘dead’ on the datatracker

 

 

--

Robert Moskowitz

Owner

HTT Consulting

C:      248-219-2059

F:      248-968-2824

E:      mailto:rgm@labs.htt-consult.com

 

There's no limit to what can be accomplished if it doesn't matter who gets the credit



--------------456236479009BEE58656548A-- From nobody Tue Jan 19 12:24:56 2021 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDA23A09E1; Mon, 18 Jan 2021 08:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, 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 S7cNExEMPV4f; Mon, 18 Jan 2021 08:35:14 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 AC07F3A09E0; Mon, 18 Jan 2021 08:35:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 81463623C1; Mon, 18 Jan 2021 11:35:10 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dNmykgZOGjfU; Mon, 18 Jan 2021 11:34:49 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 7DDB4622C2; Mon, 18 Jan 2021 11:34:48 -0500 (EST) From: Robert Moskowitz To: "Eric Vyncke (evyncke)" , Robert Moskowitz , "hipsec@ietf.org" , "draft-ietf-hip-dex@ietf.org" , Miika Komu Cc: Roman Danyliw , Eric Rescorla , Gonzalo Camarillo , "rene.hummen@belden.com" , Benjamin Kaduk , Erik Kline , Adam Wiethuechter References: <68AF0368-8CB8-4DF3-A33E-0AA28E61B5F5@cisco.com> <45191baf-ee46-89b8-fe84-742c5c17aadc@labs.htt-consult.com> <41AFBFEA-7119-451B-BC54-46CBB41274CA@cisco.com> <5f52aa64-48aa-87d3-5225-1741ca87b89d@htt-consult.com> <769d84b8-0e9f-dc8d-ee3e-62e724a830fc@htt-consult.com> Message-ID: Date: Mon, 18 Jan 2021 11:34:45 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <769d84b8-0e9f-dc8d-ee3e-62e724a830fc@htt-consult.com> Content-Type: multipart/alternative; boundary="------------D232E518A53AC87D15E7FCD4" Content-Language: en-US Archived-At: X-Mailman-Approved-At: Tue, 19 Jan 2021 12:24:34 -0800 Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13... X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 16:35:18 -0000 This is a multi-part message in MIME format. --------------D232E518A53AC87D15E7FCD4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Ah, found the paper 'free' from: https://www.researchgate.net/publication/300253314_Efficient_and_Secure_Elliptic_Curve_Cryptography_for_8-bit_AVR_Microcontrollers pg 13 is the table I am using.  Please check that you can access this URL. On 1/18/21 11:13 AM, Robert Moskowitz wrote: > Oops hold it on that paywall URL issue.  I responded with a different > paper.  All else is still ok, but let me dig a big more on that paper > for non-IACR members. > > On 1/18/21 11:06 AM, Robert Moskowitz wrote: >> >> >> On 1/18/21 9:12 AM, Eric Vyncke (evyncke) wrote: >>> Standard >>> >>> TD ;LR : more work to be done, deadline this Thursday 21st >>> >>> Bob, >>> >>> Thank you for the -23 (and Adam W for the footwork)and I understand >>> that you are quite busy. >>> >>> Here is the link to the diff between -21 and -23: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 >>> >>> (i.e., the one used by July 2020 IESG evaluation and the latest one) >>> >>> After the July 2020 IESG evaluation based on -21, there were a >>> couple of points to be addressed(with some comments of mine as EVY>): >>> >>> * Roman: “Section 6.3.  Per the definition of IKM, when should >>> these two different derivations be used? " >>> o EVY> indeed, IKMm and IKMp are both defined but nothing is >>> said which one to use in which case. >>> >> >>        IKM       IKMm for Master Key SA Input keying material >>                  or >>                  IKMp for Pair-wise Key SA Input keying material >> >>        IKMm      Kij | I_NONCE >>        IKMp      Kij | I_NONCE | (concatenated random values of the >>                      ENCRYPTED_KEY parameters in the same order as >>                      the HITs with sort(HIT-I | HIT-R)) >> >> Seems clear that IKMm is for the Master Key SA and IKMp is for the >> Pair-wise Key SA. >> >>> * Roman "discuss-discuss" (read this as request for reply and >>> non-blocking) about "further implementation experience provides >>> better guidance" in sections 6 and 9. >>> o EVY> this really pleads for experimental status >>> >> >> The only place this text exists anymore is in Appendix C:  iESG >> Considerations >> >> Perhaps I should delete it from there. >> >>> o >>> >>> >>> * Benjamin on FOLD collisions >>> o EVY> IMHO addressed in the new section 3.2.1 >>> >> >> I believe I have this covered.  We have the Python scripts for tests, >> but this is a lot of code to put into the document. Right now it is >> privately held by Adam and I.  If called on, we can find some >> permanent home for it. >> >>> o >>> >>> >>> * Benjamin on ACL to counter FOLD collisions in section 3.2.1 >>> o EVY> still light on the ACL but the above should clear it >>> >> >> Sec 7.1 is referenced. >> >>> o >>> >>> >>> * Benjamin "how is it known that the peer should be using DEX vs. BEX" >>> o EVY> partially addressed in section 1.2 but should be >>> repeated in the security section >>> >> >> I can create a sec 9.1 (pushing down the current 9.1): >> >> 9.1 Caution on using HIP DEX rather than HIP BEX >> >>    Due to the substantially reduced security guarantees of HIP DEX >>    compared to HIP BEX, HIP DEX MUST only be used when at least one of >>    the two endpoints is a class 0 or 1 constrained device defined in >>    Section 3 of [RFC7228]).  HIP DEX MUST NOT be used when both >>    endpoints are class 2 devices or unconstrained. >> >> >> Will this work? >> >>> o >>> >>> >>> * Benjamin lack of discussion on the security consequences of >>> inadvertent counter reuse in AES-CTR >>> >> >> See sec 9.1 >> >>> * >>> >>> >>> * Benjamin "presence of a CSPRNG in order to obtain secure session >>> keys" >>> >> >> 9.  Security Considerations >> >> .... >> >>    *  The strength of the keys for both the Master and Pair-wise Key SAs >>       is based on the quality of the random keying material generated by >>       the Initiator and the Responder.  As either peer may be a sensor >>       or an actuator device, there is a natural concern about the >>       quality of its random number generator.  Thus at least a CSPRNG >>       SHOULD be used. >> >> >>> * >>> >>> >>> >>> * Benjamin "usage of CMAC instead of HMAC" about KEYMAT algorithm >>> o EVY> new reference to NIST papers seems to address this concern >>> >> >> Ben did agree in an email that the SP800-56C and 108 addressed the >> concern.  I did not need to go further. >> >>> o >>> >>> >>> * Ekr’s one about why forfeiting FS when some algorithm could do >>> it in a reasonable time. In an email to authors and ADs, Eric R. >>> wrote “it defines a set of parameters (the NIST curves) which >>> are slower w/o FS than other parameters (X25519) are w/ FS. This >>> fact calls into question the need to dispense with FS.” >>> o EVY> the additional section 1.2.1 and the reference to a >>> paywall EfficientECC reference do not offer a conclusive >>> motivation for an IETF standards w/o FS. >>> >> >> Paywall?  Hmm.  I got it free.  I will have to check into this. It >> may be to some cookie I have on this system.  Or the DOI has the >> wrong URL. >> >> Ah, that URL works for me because I am an IACR member.  For all else: >> >> https://link.springer.com/article/10.1007/s10623-015-0087-1 >> >> So I will change the reference.  But please check this out.  I tried >> it on another machine that should not have my IACR cookies, but... >> >> >> >>> o >>> >>> >>> >>> >>> ***Bottom line, the document is not yet ready to be approved.*** >>> (even if big progress has been made) >>> >>> As written in November (see below), the situation has lingered for >>> too long and is blocking the HIP-NAT and rfc4423-bis documents. >>> >>> *** Therefore, I request the authors for a revised I-D addressing >>> the above (and noting again that a change to ‘experimental’ – as >>> there are no deployed implementations – could probably fix all of >>> them) before Thursday 21st of January midnight UTC else I will ask >>> the HIPSEC WG to agree removing the HIP-DEX section from the >>> architecture document. *** >>> >> >> Does the above address the open items? >> >>> All in all, there have been a couple of significant changes >>> (I_NONCE, some deleted ciphers) since the IETF last call (see >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 >>> >>> ), so, another IETF Last Call is required but should not be a real >>> problem. >>> >>> -éric >>> >>> From: Robert Moskowitz >>> >>> Date: Thursday, 14 January 2021 at 16:08 >>> >>> To: Eric Vyncke , "Eric Vyncke (evyncke)" >>> , "hipsec@ietf.org" >>> , "draft-ietf-hip-dex@ietf.org" >>> , Miika Komu >>> >>> Cc: Roman Danyliw , Eric Rescorla , >>> Gonzalo Camarillo , >>> "rene.hummen@belden.com" , Benjamin Kaduk >>> , Erik Kline >>> >>> Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 >>> pending issues... before 2021-Jan-13... >>> >>> I had hoped to get -23 out end of last week, and missed my cutoff.  >>> I am now in IACR's Real World Crypto, where I have gotten a couple >>> pointers for DRIP work. >>> >>> I was waiting for two analyzes that I got Jan 4, and incorporating >>> them in.  I believe these SHOULD address much of EKR's questions. >>> >>> I will have a run of 1M DEX random HIs to HITs generated with no >>> duplicates that I add in an Appendix along with the Python code. >>> >>> I am adding a BEX/DEX crypto cost into 1.2, probably 1.2.1: >>> >>> For an Initiator, BEX is: >>> >>> 2 PK sig varifications. >>> >>> 1 PK sig generation. >>> >>> 1 DH keypair generation. >>> >>> 1 DH secret derivation. >>> >>> DEX is: >>> >>> 1 DH secret derivation. >>> >>> I have cycles for these and a paper to reference, except ECDH >>> keypair generation, on an 8 bit process and the numbers are big.  >>> But I think that part belongs in an Appendix. >>> >>> So unlikely Friday.  But early the following week. >>> >>> On 1/12/21 6:19 AM, Eric Vyncke (evyncke) wrote: >>> >>> Two months after the email below, I sending a kind reminder to >>> authors and WG. >>> >>> With the -22, a lot of (if not all ) SEC ADs’ DISCUSS points should >>> have been addressed. >>> >>> As far as I can tell, the other remaining issue was Ekr’s one about >>> why forfeiting FS when some algorithm could do it in a reasonable >>> time. In an email to authors and ADs, Eric R. wrote “it defines a >>> set of parameters (the NIST curves) which are slower w/o FS than >>> other parameters (X25519) are w/ FS. This fact calls into question >>> the need to dispense with FS.” >>> >>> While 2 months ago I put a deadline for tomorrow, I (as the >>> responsible AD) am flexible of course but we cannot linger anymore. >>> I know that a -23 is in the work for weeks => let’s publish it in >>> the coming days. >>> >>> Else, next week we will need to either change the intended status to >>> experimental or declare the document dead by lack of energy. The >>> latter does not have my preference obviously. >>> >>> Regards >>> >>> -éric >>> >>> From: Hipsec mailto:hipsec-bounces@ietf.org on behalf of "Eric >>> Vyncke (evyncke)" mailto:evyncke=40cisco.com@dmarc.ietf.org >>> >>> Date: Friday, 13 November 2020 at 15:32 >>> >>> To: mailto:hipsec@ietf.org mailto:hipsec@ietf.org, >>> mailto:draft-ietf-hip-dex@ietf.org >>> mailto:draft-ietf-hip-dex@ietf.org, Robert Moskowitz >>> mailto:rgm@labs.htt-consult.com, Miika Komu >>> mailto:miika.komu@ericsson.com >>> >>> Cc: Roman Danyliw mailto:rdd@cert.org, Eric Rescorla >>> mailto:ekr@rtfm.com, Gonzalo Camarillo >>> mailto:gonzalo.camarillo@ericsson.com, mailto:rene.hummen@belden.com >>> mailto:rene.hummen@belden.com, Benjamin Kaduk mailto:kaduk@mit.edu, >>> Erik Kline mailto:ek.ietf@gmail.com >>> >>> Subject: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending >>> issues... before 2021-Jan-13... >>> >>> Dear HIP, dear authors, >>> >>> This document was requested for publication [1] in February 2018 >>> (2.5 years ago), then its IESG evaluation has been deferred, then I >>> took over this document from Terry Manderson in March 2019, then it >>> went again through IESG evaluation in July 2020 and there are still >>> DISCUSS points to be addressed even after a couple of revised I-D... >>> >>> Difficult not to observe that this document does not progress very fast. >>> >>> Moreover, this document is a normative reference for rfc4423-bis >>> waiting in the RFC editor queue since March 2019... So, also >>> blocking the HIP-NAT document [2]. >>> >>> After discussion with the HIP chair, Gonzalo in cc, we have taken >>> the following decision: if a revised I-D addressing remaining >>> DISCUSS points + Ekr’s ones is not uploaded within 2 months (13th of >>> January 2021), then I will request the HIP WG to accept the complete >>> removal of section A.3.3 of the rfc4423-bis document (1 page about >>> HIP-DEX in the appendix) + the reference to the HIP-DEX document >>> [3]. This will allow the immediate publication of the rfc4423-bis >>> and HIP-NAT documents. >>> >>> The HIP DEX authors may also select to change the intended status of >>> the document to ‘experimental’ (if the HIP WG agrees) as this may >>> reduce the security requirements by the SEC AD and Ekr. >>> >>> Gonzalo and I are still hoping to get a revised HIP-DEX shortly, >>> >>> Regards >>> >>> -éric >>> >>> [1] https://datatracker.ietf.org/doc/draft-ietf-hip-dex/history/ >>> >>> [2] https://www.rfc-editor.org/cluster_info.php?cid=C386 >>> >>> [3] and possibly I will set the state of HIP-DEX as ‘dead’ on the >>> datatracker >>> >>> -- >>> >>> Robert Moskowitz >>> >>> Owner >>> >>> HTT Consulting >>> >>> C:      248-219-2059 >>> >>> F:      248-968-2824 >>> >>> E: mailto:rgm@labs.htt-consult.com >>> >>> There's no limit to what can be accomplished if it doesn't matter >>> who gets the credit >>> >> > --------------D232E518A53AC87D15E7FCD4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Ah, found the paper 'free' from:

https://www.researchgate.net/publication/300253314_Efficient_and_Secure_Elliptic_Curve_Cryptography_for_8-bit_AVR_Microcontrollers

pg 13 is the table I am using.  Please check that you can access this URL.

On 1/18/21 11:13 AM, Robert Moskowitz wrote:
Oops hold it on that paywall URL issue.  I responded with a different paper.  All else is still ok, but let me dig a big more on that paper for non-IACR members.

On 1/18/21 11:06 AM, Robert Moskowitz wrote:


On 1/18/21 9:12 AM, Eric Vyncke (evyncke) wrote:
Standard

TD ;LR : more work to be done, deadline this Thursday 21st

 

Bob,

 

Thank you for the -23 (and Adam W for the footwork) and I understand that you are quite busy.

 

Here is the link to the diff between -21 and -23: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 (i.e., the one used by July 2020 IESG evaluation and the latest one)

 

After the July 2020 IESG evaluation based on -21, there were a couple of points to be addressed (with some comments of mine as EVY>):

  • Roman: “Section 6.3.  Per the definition of IKM, when should these two different derivations be used? "
    • EVY> indeed, IKMm and IKMp are both defined but nothing is said which one to use in which case.

       IKM       IKMm for Master Key SA Input keying material
                 or
                 IKMp for Pair-wise Key SA Input keying material

       IKMm      Kij | I_NONCE
       IKMp      Kij | I_NONCE | (concatenated random values of the
                     ENCRYPTED_KEY parameters in the same order as
                     the HITs with sort(HIT-I | HIT-R))

Seems clear that IKMm is for the Master Key SA and IKMp is for the Pair-wise Key SA.

  • Roman "discuss-discuss" (read this as request for reply and non-blocking) about " further implementation experience provides better guidance" in sections 6 and 9.
    • EVY> this really pleads for experimental status

The only place this text exists anymore is in Appendix C:  iESG Considerations

Perhaps I should delete it from there.


  • Benjamin on FOLD collisions
    • EVY> IMHO addressed in the new section 3.2.1

I believe I have this covered.  We have the Python scripts for tests, but this is a lot of code to put into the document.  Right now it is privately held by Adam and I.  If called on, we can find some permanent home for it.


  • Benjamin on ACL to counter FOLD collisions in section 3.2.1
    • EVY> still light on the ACL but the above should clear it

Sec 7.1 is referenced.


  • Benjamin "how is it known that the peer should be using DEX vs. BEX"
    • EVY> partially addressed in section 1.2 but should be repeated in the security section

I can create a sec 9.1 (pushing down the current 9.1):

9.1 Caution on using HIP DEX rather than HIP BEX

   Due to the substantially reduced security guarantees of HIP DEX
   compared to HIP BEX, HIP DEX MUST only be used when at least one of
   the two endpoints is a class 0 or 1 constrained device defined in
   Section 3 of [RFC7228]).  HIP DEX MUST NOT be used when both
   endpoints are class 2 devices or unconstrained.


Will this work?


  • Benjamin lack of discussion on the security consequences of inadvertent counter reuse in AES-CTR

See sec 9.1


  • Benjamin "presence of a CSPRNG in order to obtain secure session keys"

9.  Security Considerations

....

   *  The strength of the keys for both the Master and Pair-wise Key SAs
      is based on the quality of the random keying material generated by
      the Initiator and the Responder.  As either peer may be a sensor
      or an actuator device, there is a natural concern about the
      quality of its random number generator.  Thus at least a CSPRNG
      SHOULD be used.



  • Benjamin "usage of CMAC instead of HMAC" about KEYMAT algorithm
    • EVY> new reference to NIST papers seems to address this concern

Ben did agree in an email that the SP800-56C and 108 addressed the concern.  I did not need to go further.


  • Ekr’s one about why forfeiting FS when some algorithm could do it in a reasonable time. In an email to authors and ADs, Eric R. wrote “it defines a set of parameters (the NIST curves) which are slower w/o FS than other parameters (X25519) are w/ FS. This fact calls into question the need to dispense with FS.”
    • EVY> the additional section 1.2.1 and the reference to a paywall EfficientECC reference do not offer a conclusive motivation for an IETF standards w/o FS.

Paywall?  Hmm.  I got it free.  I will have to check into this.  It may be to some cookie I have on this system.  Or the DOI has the wrong URL.

Ah, that URL works for me because I am an IACR member.  For all else:

https://link.springer.com/article/10.1007/s10623-015-0087-1

So I will change the reference.  But please check this out.  I tried it on another machine that should not have my IACR cookies, but...




 

***Bottom line, the document is not yet ready to be approved.*** (even if big progress has been made)

 

As written in November (see below), the situation has lingered for too long and is blocking the HIP-NAT and rfc4423-bis documents.

 

*** Therefore, I request the authors for a revised I-D addressing the above (and noting again that a change to ‘experimental’ – as there are no deployed implementations – could probably fix all of them) before Thursday 21st of January midnight UTC else I will ask the HIPSEC WG to agree removing the HIP-DEX section from the architecture document. ***


Does the above address the open items?

 

All in all, there have been a couple of significant changes (I_NONCE, some deleted ciphers) since the IETF last call (see https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 ), so, another IETF Last Call is required but should not be a real problem.

 

 

-éric

 

 

 

From: Robert Moskowitz <rgm@labs.htt-consult.com>

Date: Thursday, 14 January 2021 at 16:08

To: Eric Vyncke <evyncke@cisco.com>, "Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>, "hipsec@ietf.org" <hipsec@ietf.org>, "draft-ietf-hip-dex@ietf.org" <draft-ietf-hip-dex@ietf.org>, Miika Komu <miika.komu@ericsson.com>

Cc: Roman Danyliw <rdd@cert.org>, Eric Rescorla <ekr@rtfm.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "rene.hummen@belden.com" <rene.hummen@belden.com>, Benjamin Kaduk <kaduk@mit.edu>, Erik Kline <ek.ietf@gmail.com>

Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...

 

I had hoped to get -23 out end of last week, and missed my cutoff.  I am now in IACR's Real World Crypto, where I have gotten a couple pointers for DRIP work.

 

I was waiting for two analyzes that I got Jan 4, and incorporating them in.  I believe these SHOULD address much of EKR's questions.

 

I will have a run of 1M DEX random HIs to HITs generated with no duplicates that I add in an Appendix along with the Python code.

 

I am adding a BEX/DEX crypto cost into 1.2, probably 1.2.1:

 

For an Initiator, BEX is:

 

2 PK sig varifications.

1 PK sig generation.

1 DH keypair generation.

1 DH secret derivation.

 

DEX is:

 

1 DH secret derivation.

 

I have cycles for these and a paper to reference, except ECDH keypair generation, on an 8 bit process and the numbers are big.  But I think that part belongs in an Appendix.

 

So unlikely Friday.  But early the following week.

 

 

 

 

 

On 1/12/21 6:19 AM, Eric Vyncke (evyncke) wrote:

Two months after the email below, I sending a kind reminder to authors and WG.

 

With the -22, a lot of (if not all ) SEC ADs’ DISCUSS points should have been addressed.

 

As far as I can tell, the other remaining issue was Ekr’s one about why forfeiting FS when some algorithm could do it in a reasonable time. In an email to authors and ADs, Eric R. wrote “it defines a set of parameters (the NIST curves) which are slower w/o FS than other parameters (X25519) are w/ FS. This fact calls into question the need to dispense with FS.”

 

While 2 months ago I put a deadline for tomorrow, I (as the responsible AD) am flexible of course but we cannot linger anymore. I know that a -23 is in the work for weeks => let’s publish it in the coming days.

 

Else, next week we will need to either change the intended status to experimental or declare the document dead by lack of energy. The latter does not have my preference obviously.

 

Regards

 

-éric

 

 

From: Hipsec mailto:hipsec-bounces@ietf.org on behalf of "Eric Vyncke (evyncke)" mailto:evyncke=40cisco.com@dmarc.ietf.org

Date: Friday, 13 November 2020 at 15:32

To: mailto:hipsec@ietf.org mailto:hipsec@ietf.org, mailto:draft-ietf-hip-dex@ietf.org mailto:draft-ietf-hip-dex@ietf.org, Robert Moskowitz mailto:rgm@labs.htt-consult.com, Miika Komu mailto:miika.komu@ericsson.com

Cc: Roman Danyliw mailto:rdd@cert.org, Eric Rescorla mailto:ekr@rtfm.com, Gonzalo Camarillo mailto:gonzalo.camarillo@ericsson.com, mailto:rene.hummen@belden.com mailto:rene.hummen@belden.com, Benjamin Kaduk mailto:kaduk@mit.edu, Erik Kline mailto:ek.ietf@gmail.com

Subject: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...

 

Dear HIP, dear authors,

 

This document was requested for publication [1] in February 2018 (2.5 years ago), then its IESG evaluation has been deferred, then I took over this document from Terry Manderson in March 2019, then it went again through IESG evaluation in July 2020 and there are still DISCUSS points to be addressed even after a couple of revised I-D...

 

Difficult not to observe that this document does not progress very fast.

 

Moreover, this document is a normative reference for rfc4423-bis waiting in the RFC editor queue since March 2019... So, also blocking the HIP-NAT document [2].

 

After discussion with the HIP chair, Gonzalo in cc, we have taken the following decision: if a revised I-D addressing remaining DISCUSS points + Ekr’s ones is not uploaded within 2 months (13th of January 2021), then I will request the HIP WG to accept the complete removal of section A.3.3 of the rfc4423-bis document (1 page about HIP-DEX in the appendix) + the reference to the HIP-DEX document [3]. This will allow the immediate publication of the rfc4423-bis and HIP-NAT documents.

 

The HIP DEX authors may also select to change the intended status of the document to ‘experimental’ (if the HIP WG agrees) as this may reduce the security requirements by the SEC AD and Ekr.

 

Gonzalo and I are still hoping to get a revised HIP-DEX shortly,

 

Regards

 

-éric

 

[1] https://datatracker.ietf.org/doc/draft-ietf-hip-dex/history/

[2] https://www.rfc-editor.org/cluster_info.php?cid=C386

[3] and possibly I will set the state of HIP-DEX as ‘dead’ on the datatracker

 

 

--

Robert Moskowitz

Owner

HTT Consulting

C:      248-219-2059

F:      248-968-2824

E:      mailto:rgm@labs.htt-consult.com

 

There's no limit to what can be accomplished if it doesn't matter who gets the credit




--------------D232E518A53AC87D15E7FCD4-- From nobody Tue Jan 19 12:25:00 2021 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE633A14FC for ; Tue, 19 Jan 2021 05:52:31 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=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=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 DrwVvG3h9I0R for ; Tue, 19 Jan 2021 05:52:28 -0800 (PST) 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 DD9143A14FD for ; Tue, 19 Jan 2021 05:52:27 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id e7so21983811ljg.10 for ; Tue, 19 Jan 2021 05:52:27 -0800 (PST) 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=jNZEINnOKjNKbba/b+NE7lgxTawLRksLxukIk2j10e4=; b=ez5ev9rvgHtCgh687nq3ZdmXB/3rzDnLiUr3wsQcUwb7txHMeVKOc9mE1jPhffaqq6 pBMt64AuGgono4MRcC/KzQS5RJli98VoQswCnxG/gpvYe3f2oszzUkqjCMy9klCk/ArO aIdACdTo01uolmcL1fvw18pY1poT0nQlwgabb2xqSDMfIyJiHjodl0AgR3xkYY/tqdfP FA6jfQF8v+6KvmgeGfEowy+7kS8D16X3v3yJHzzUFFk4gX9twNDyovAC0ACtnuj3/p5y YiuWggXVQY3Y6VghsRd48j3ZmRLlq9bDqkJCWeWoTjVtMoCwOr++gyW8GG9mrkdAFAY1 FY9g== 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=jNZEINnOKjNKbba/b+NE7lgxTawLRksLxukIk2j10e4=; b=iFsD9p9uBsEe3apkUKkLfnr2IIEvOJJ31/I8rvWtEcCcBXCmQ5Wl2lxhxYnWIKC97/ i1fStzbLh/LdFIyWw5pfsdYI5zxvkFMsFQ0rLjlgUTeGljl5fspR679hcDEET/9rwj9k mHwTdcFIx4YzMvpGdWA44wE4dqcSUfyI3L8GpgtXZuNV121ry4jJFHVnlhRS7XOGjdVp eMFzDEsAEpCJPsZI+yt82NL+tGAtZd/izBdvfROhfGhhF59VRR6k92elws9vum4kQlKP V7OoE7ObQOs9Gfa7bijRR6Y5Eti1xfaxGnUHQrWZol5sKQNpWH73e+p8X04/Gl17eupH FExw== X-Gm-Message-State: AOAM533PfVsO1srMcDg8vO1y1IsLHem6k6KM3Ixw7p6uT5lfiuTNpNHw ZYfDkCWQj9zDR4AiwkyzA5IVN8clScpjd9wtzuTOYg== X-Google-Smtp-Source: ABdhPJyex6PlbIBkYKvnQxJLkFdS9Cd4ri15hAhxA4MHlZsVOcL7Ep3D9WR+3yhOrIqp+Zpuj3w3Obvt3A+JCeZ0x2Q= X-Received: by 2002:a2e:720c:: with SMTP id n12mr2103018ljc.2.1611064345899; Tue, 19 Jan 2021 05:52:25 -0800 (PST) MIME-Version: 1.0 References: <68AF0368-8CB8-4DF3-A33E-0AA28E61B5F5@cisco.com> <45191baf-ee46-89b8-fe84-742c5c17aadc@labs.htt-consult.com> <41AFBFEA-7119-451B-BC54-46CBB41274CA@cisco.com> <5f52aa64-48aa-87d3-5225-1741ca87b89d@htt-consult.com> <769d84b8-0e9f-dc8d-ee3e-62e724a830fc@htt-consult.com> In-Reply-To: From: Eric Rescorla Date: Tue, 19 Jan 2021 05:51:49 -0800 Message-ID: To: Robert Moskowitz Cc: "Eric Vyncke (evyncke)" , Robert Moskowitz , "hipsec@ietf.org" , "draft-ietf-hip-dex@ietf.org" , Miika Komu , Roman Danyliw , Gonzalo Camarillo , "rene.hummen@belden.com" , Benjamin Kaduk , Erik Kline , Adam Wiethuechter Content-Type: multipart/alternative; boundary="0000000000000c4a5305b9412625" Archived-At: X-Mailman-Approved-At: Tue, 19 Jan 2021 12:24:35 -0800 Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13... X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 13:52:32 -0000 --0000000000000c4a5305b9412625 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the link. However, this paper appears only to cover X25519. We'd need a comparison of this to P384, etc. in order to assess the relative performance of SIGMA-style protocols with NIST curves with HIP-DEX with X25519 On Mon, Jan 18, 2021 at 8:35 AM Robert Moskowitz wrote: > Ah, found the paper 'free' from: > > > https://www.researchgate.net/publication/300253314_Efficient_and_Secure_E= lliptic_Curve_Cryptography_for_8-bit_AVR_Microcontrollers > > pg 13 is the table I am using. Please check that you can access this URL= . > > On 1/18/21 11:13 AM, Robert Moskowitz wrote: > > Oops hold it on that paywall URL issue. I responded with a different > paper. All else is still ok, but let me dig a big more on that paper for > non-IACR members. > > On 1/18/21 11:06 AM, Robert Moskowitz wrote: > > > > On 1/18/21 9:12 AM, Eric Vyncke (evyncke) wrote: > > TD ;LR : more work to be done, deadline this Thursday 21st > > > > Bob, > > > > Thank you for the -23 (and Adam W for the footwork) and I understand that > you are quite busy. > > > > Here is the link to the diff between -21 and -23: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-dex-23&url1=3Ddraft-ie= tf-hip-dex-21 (i.e., > the one used by July 2020 IESG evaluation and the latest one) > > > > After the July 2020 IESG evaluation based on -21, there were a couple of > points to be addressed (with some comments of mine as EVY>): > > - Roman: =E2=80=9CSection 6.3. Per the definition of IKM, when should= these > two different derivations be used? " > - EVY> indeed, IKMm and IKMp are both defined but nothing is said > which one to use in which case. > > > IKM IKMm for Master Key SA Input keying material > or > IKMp for Pair-wise Key SA Input keying material > > IKMm Kij | I_NONCE > IKMp Kij | I_NONCE | (concatenated random values of the > ENCRYPTED_KEY parameters in the same order as > the HITs with sort(HIT-I | HIT-R)) > > Seems clear that IKMm is for the Master Key SA and IKMp is for the > Pair-wise Key SA. > > > - Roman "discuss-discuss" (read this as request for reply and > non-blocking) about " further implementation experience provides > better guidance" in sections 6 and 9. > - EVY> this really pleads for experimental status > > > The only place this text exists anymore is in Appendix C: iESG > Considerations > > Perhaps I should delete it from there. > > > - > - Benjamin on FOLD collisions > - EVY> IMHO addressed in the new section 3.2.1 > > > I believe I have this covered. We have the Python scripts for tests, but > this is a lot of code to put into the document. Right now it is privatel= y > held by Adam and I. If called on, we can find some permanent home for it= . > > > - > - Benjamin on ACL to counter FOLD collisions in section 3.2.1 > - EVY> still light on the ACL but the above should clear it > > > Sec 7.1 is referenced. > > > - > - Benjamin "how is it known that the peer should be using DEX vs. > BEX" > - EVY> partially addressed in section 1.2 but should be repeated in > the security section > > > I can create a sec 9.1 (pushing down the current 9.1): > > 9.1 Caution on using HIP DEX rather than HIP BEX > > Due to the substantially reduced security guarantees of HIP DEX > compared to HIP BEX, HIP DEX MUST only be used when at least one of > the two endpoints is a class 0 or 1 constrained device defined in > Section 3 of [RFC7228]). HIP DEX MUST NOT be used when both > endpoints are class 2 devices or unconstrained. > > > Will this work? > > > - > - Benjamin lack of discussion on the security consequences of > inadvertent counter reuse in AES-CTR > > > See sec 9.1 > > > - > - Benjamin "presence of a CSPRNG in order to obtain secure session > keys" > > > 9. Security Considerations > > .... > > * The strength of the keys for both the Master and Pair-wise Key SAs > is based on the quality of the random keying material generated by > the Initiator and the Responder. As either peer may be a sensor > or an actuator device, there is a natural concern about the > quality of its random number generator. Thus at least a CSPRNG > SHOULD be used. > > > > - > - Benjamin "usage of CMAC instead of HMAC" about KEYMAT algorithm > - EVY> new reference to NIST papers seems to address this concern > > > Ben did agree in an email that the SP800-56C and 108 addressed the > concern. I did not need to go further. > > > - > - Ekr=E2=80=99s one about why forfeiting FS when some algorithm cou= ld do it > in a reasonable time. In an email to authors and ADs, Eric R. wrote = =E2=80=9Cit > defines a set of parameters (the NIST curves) which are slower w/o FS = than > other parameters (X25519) are w/ FS. This fact calls into question the= need > to dispense with FS.=E2=80=9D > - EVY> the additional section 1.2.1 and the reference to a paywall > EfficientECC reference do not offer a conclusive motivation for an = IETF > standards w/o FS. > > > Paywall? Hmm. I got it free. I will have to check into this. It may b= e > to some cookie I have on this system. Or the DOI has the wrong URL. > > Ah, that URL works for me because I am an IACR member. For all else: > > https://link.springer.com/article/10.1007/s10623-015-0087-1 > > So I will change the reference. But please check this out. I tried it o= n > another machine that should not have my IACR cookies, but... > > > > > - > > > > ***Bottom line, the document is not yet ready to be approved.*** (even if > big progress has been made) > > > > As written in November (see below), the situation has lingered for too > long and is blocking the HIP-NAT and rfc4423-bis documents. > > > > *** Therefore, I request the authors for a revised I-D addressing the > above (and noting again that a change to =E2=80=98experimental=E2=80=99 = =E2=80=93 as there are no > deployed implementations =E2=80=93 could probably fix all of them) before= Thursday > 21st of January midnight UTC else I will ask the HIPSEC WG to agree > removing the HIP-DEX section from the architecture document. *** > > > Does the above address the open items? > > > > All in all, there have been a couple of significant changes (I_NONCE, som= e > deleted ciphers) since the IETF last call (see > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-dex-23&url1=3Ddraft-ie= tf-hip-dex-21 > ), so, another IETF Last Call is required but should not be a real proble= m. > > > > > > -=C3=A9ric > > > > > > > > From: Robert Moskowitz > > > Date: Thursday, 14 January 2021 at 16:08 > > To: Eric Vyncke , "Eric Vyncke > (evyncke)" > , "hipsec@ietf.org" > , "draft-ietf-hip-dex@ietf.org" > > , Miika Komu > > > Cc: Roman Danyliw , Eric Rescorla > , Gonzalo Camarillo > , > "rene.hummen@belden.com" > , Benjamin Kaduk , > Erik Kline > > Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending > issues... before 2021-Jan-13... > > > > I had hoped to get -23 out end of last week, and missed my cutoff. I am > now in IACR's Real World Crypto, where I have gotten a couple pointers fo= r > DRIP work. > > > > I was waiting for two analyzes that I got Jan 4, and incorporating them > in. I believe these SHOULD address much of EKR's questions. > > > > I will have a run of 1M DEX random HIs to HITs generated with no > duplicates that I add in an Appendix along with the Python code. > > > > I am adding a BEX/DEX crypto cost into 1.2, probably 1.2.1: > > > > For an Initiator, BEX is: > > > > 2 PK sig varifications. > > 1 PK sig generation. > > 1 DH keypair generation. > > 1 DH secret derivation. > > > > DEX is: > > > > 1 DH secret derivation. > > > > I have cycles for these and a paper to reference, except ECDH keypair > generation, on an 8 bit process and the numbers are big. But I think tha= t > part belongs in an Appendix. > > > > So unlikely Friday. But early the following week. > > > > > > > > > > > > On 1/12/21 6:19 AM, Eric Vyncke (evyncke) wrote: > > Two months after the email below, I sending a kind reminder to authors an= d > WG. > > > > With the -22, a lot of (if not all ) SEC ADs=E2=80=99 DISCUSS points shou= ld have > been addressed. > > > > As far as I can tell, the other remaining issue was Ekr=E2=80=99s one abo= ut why > forfeiting FS when some algorithm could do it in a reasonable time. In an > email to authors and ADs, Eric R. wrote =E2=80=9Cit defines a set of para= meters > (the NIST curves) which are slower w/o FS than other parameters (X25519) > are w/ FS. This fact calls into question the need to dispense with FS.=E2= =80=9D > > > > While 2 months ago I put a deadline for tomorrow, I (as the responsible > AD) am flexible of course but we cannot linger anymore. I know that a -23 > is in the work for weeks =3D> let=E2=80=99s publish it in the coming days= . > > > > Else, next week we will need to either change the intended status to > experimental or declare the document dead by lack of energy. The latter > does not have my preference obviously. > > > > Regards > > > > -=C3=A9ric > > > > > > From: Hipsec mailto:hipsec-bounces@ietf.org on > behalf of "Eric Vyncke (evyncke)" > mailto:evyncke=3D40cisco.com@dmarc.ietf.org > > > Date: Friday, 13 November 2020 at 15:32 > > To: mailto:hipsec@ietf.org mailto:hipsec@ietf.org > , mailto:draft-ietf-hip-dex@ietf.org > mailto:draft-ietf-hip-dex@ietf.org > , Robert Moskowitz > mailto:rgm@labs.htt-consult.com , Miika Komu > mailto:miika.komu@ericsson.com > > Cc: Roman Danyliw mailto:rdd@cert.org , Eric Rescorla > mailto:ekr@rtfm.com , Gonzalo Camarillo > mailto:gonzalo.camarillo@ericsson.com , > mailto:rene.hummen@belden.com > mailto:rene.hummen@belden.com , Benjamin Kaduk > mailto:kaduk@mit.edu , Erik Kline mailto:ek.ietf@gmail.com > > > Subject: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending > issues... before 2021-Jan-13... > > > > Dear HIP, dear authors, > > > > This document was requested for publication [1] in February 2018 (2.5 > years ago), then its IESG evaluation has been deferred, then I took over > this document from Terry Manderson in March 2019, then it went again > through IESG evaluation in July 2020 and there are still DISCUSS points t= o > be addressed even after a couple of revised I-D... > > > > Difficult not to observe that this document does not progress very fast. > > > > Moreover, this document is a normative reference for rfc4423-bis waiting > in the RFC editor queue since March 2019... So, also blocking the HIP-NAT > document [2]. > > > > After discussion with the HIP chair, Gonzalo in cc, we have taken the > following decision: if a revised I-D addressing remaining DISCUSS points = + > Ekr=E2=80=99s ones is not uploaded within 2 months (13th of January 2021)= , then I > will request the HIP WG to accept the complete removal of section A.3.3 o= f > the rfc4423-bis document (1 page about HIP-DEX in the appendix) + the > reference to the HIP-DEX document [3]. This will allow the immediate > publication of the rfc4423-bis and HIP-NAT documents. > > > > The HIP DEX authors may also select to change the intended status of the > document to =E2=80=98experimental=E2=80=99 (if the HIP WG agrees) as this= may reduce the > security requirements by the SEC AD and Ekr. > > > > Gonzalo and I are still hoping to get a revised HIP-DEX shortly, > > > > Regards > > > > -=C3=A9ric > > > > [1] https://datatracker.ietf.org/doc/draft-ietf-hip-dex/history/ > > [2] https://www.rfc-editor.org/cluster_info.php?cid=3DC386 > > [3] and possibly I will set the state of HIP-DEX as =E2=80=98dead=E2=80= =99 on the > datatracker > > > > > > -- > > Robert Moskowitz > > Owner > > HTT Consulting > > C: 248-219-2059 > > F: 248-968-2824 > > E: mailto:rgm@labs.htt-consult.com > > > > There's no limit to what can be accomplished if it doesn't matter who get= s > the credit > > > > > --0000000000000c4a5305b9412625 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the link. However, this paper appears only to c= over X25519. We'd need a comparison of this to P384, etc. in order to a= ssess the relative performance of SIGMA-style protocols with NIST curves wi= th HIP-DEX with X25519

On Mon, Jan 18, 2021 at 8:35 AM Robert Moskowitz = <rgm@htt-consul= t.com> wrote:
=20 =20 =20
Ah, found the paper 'free' from:

https://www.researchgate.net/publication/300253314_Efficient_an= d_Secure_Elliptic_Curve_Cryptography_for_8-bit_AVR_Microcontrollers

pg 13 is the table I am using.=C2=A0 Please check that you can access this URL.

On 1/18/21 11:13 AM, Robert Moskowitz wrote:
=20 Oops hold it on that paywall URL issue.=C2=A0 I responded with a different paper.=C2=A0 All else is still ok, but let me dig a big mor= e on that paper for non-IACR members.

On 1/18/21 11:06 AM, Robert Moskowitz wrote:
=20

On 1/18/21 9:12 AM, Eric Vyncke (evyncke) wrote:
=20 =20 =20 =20

TD=C2=A0;LR=C2=A0: more work to be done, deadline this Thursday 21st<= /span>

=C2=A0

Bob,

=C2=A0

Thank you for the -23 (and Adam W for the footwork) and I understand that you are quite busy.

=C2=A0

Here is the link to the diff between -21 and -23: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-dex-23&url1=3Ddraft-= ietf-hip-dex-21 (i.e., the one used by July 2020 IESG evaluation and the latest one)

=C2=A0

After the July 2020 IESG evaluation based on -21= , there were a couple of points to be addressed (with some comments of mine as EVY>):

  • Roman: =E2=80=9CSection 6.3.=C2=A0 Per the definition of IKM, when= should these two different derivations be used? "
    • EVY> indeed, IKMm and IKMp are = both defined but nothing is said which one to use in which case.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IKM=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 IKMm for Master Key SA Input keying material
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IKMp for Pair-wise Key SA Input keying mater= ial

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IKMm=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Kij | I_NONCE
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IKMp=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Kij | I_NONCE | (concatenated random values of the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ENCRYPTED_KEY parame= ters in the same order as
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the HITs with sort(H= IT-I | HIT-R))

Seems clear that IKMm is for the Master Key SA and IKMp is for the Pair-wise Key SA.

  • Roman "discuss-discuss" (r= ead this as request for reply and non-blocking) about " further implementation experience provides better guidance" = in sections 6 and 9.
    • EVY> this really pleads for experimental status

The only place this text exists anymore is in Appendix C:=C2=A0 iES= G Considerations

Perhaps I should delete it from there.


  • Benjamin on FOLD collisions <= u>
    • EVY> IMHO addressed in the new section 3.2.1

I believe I have this covered.=C2=A0 We have the Python scripts for tests, but this is a lot of code to put into the document.=C2=A0 Right now it is privately held by Adam and I.=C2=A0 If called on, w= e can find some permanent home for it.


  • Benjamin on ACL to counter FOLD collisions in section 3.2.1
    • EVY> still light on the ACL but= the above should clear it

Sec 7.1 is referenced.


  • Benjamin "how is it known that = the peer should be using DEX vs. BEX"
    • EVY> partially addressed in sec= tion 1.2 but should be repeated in the security section

I can create a sec 9.1 (pushing down the current 9.1):

9.1 Caution on using HIP DEX rather than HIP BEX

=C2=A0=C2=A0 Due to the substantially reduced security guarantees o= f HIP DEX
=C2=A0=C2=A0 compared to HIP BEX, HIP DEX MUST only be used when at= least one of
=C2=A0=C2=A0 the two endpoints is a class 0 or 1 constrained device defined in
=C2=A0=C2=A0 Section 3 of [RFC7228]).=C2=A0 HIP DEX MUST NOT be use= d when both
=C2=A0=C2=A0 endpoints are class 2 devices or unconstrained.


Will this work?


  • Benjamin lack of discussion on the security consequences of inadvertent counter reuse in AES-CTR

See sec 9.1


  • Benjamin "presence of a CSPRNG = in order to obtain secure session keys"

9.=C2=A0 Security Considerations

....

=C2=A0=C2=A0 *=C2=A0 The strength of the keys for both the Master a= nd Pair-wise Key SAs
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is based on the quality of the rando= m keying material generated by
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the Initiator and the Responder.=C2= =A0 As either peer may be a sensor
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or an actuator device, there is a na= tural concern about the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 quality of its random number generat= or.=C2=A0 Thus at least a CSPRNG
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHOULD be used.



  • Benjamin "usage of CMAC instead= of HMAC" about KEYMAT algorithm
    • EVY> new reference to NIST pape= rs seems to address this concern

Ben did agree in an email that the SP800-56C and 108 addressed the concern.=C2=A0 I did not need to go further.


  • Ekr=E2=80=99s one about why forfeiting FS when some algorithm could do it in a reasonable time. In an email to authors and ADs, Eric R. wrote =E2=80=9Cit defines a set of parameters (the = NIST curves) which are slower w/o FS than other parameters (X25519) are w/ FS. This fact calls into question the need to dispense with FS.=E2=80=9D
    • EVY> the additional section 1.2= .1 and the reference to a paywall EfficientECC reference do not offer a conclusive motivation for an IETF standards w/o FS.

Paywall?=C2=A0 Hmm.=C2=A0 I got it free.=C2=A0 I will have to check= into this.=C2=A0 It may be to some cookie I have on this system.=C2=A0 Or the DOI ha= s the wrong URL.

Ah, that URL works for me because I am an IACR member.=C2=A0 For al= l else:

https://link.springer.com/article/10.1007/s10623-015= -0087-1

So I will change the reference.=C2=A0 But please check this out.=C2= =A0 I tried it on another machine that should not have my IACR cookies, but...




=C2=A0

***Bottom line, the document is not yet ready to be approved.*** (even if big progress has been made)

=C2=A0

As written in November (see below), the situation has lingered for too long and is blocking the HIP-NAT and rfc4423-bis documents.

=C2=A0

*** Therefore, I request the authors for a revised I-D addressing the above (and noting again that a change to =E2=80=98experimen= tal=E2=80=99 =E2=80=93 as there are no deployed implementations =E2=80= =93 could probably fix all of them) before Thursday 21st of January midnight UTC else I will ask the HIPSEC WG to agree removing the HIP-DEX section from the architecture document. ***


Does the above address the open items?

=C2=A0

All in all, there have been a couple of significant changes (I_NONCE, some deleted ciphers) since the IETF last call (see https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-dex-23&url1=3Ddraft-= ietf-hip-dex-21 ), so, another IETF Last Call is required but should not be a real problem.

=C2=A0

=C2=A0

-=C3=A9ric

=C2=A0

=C2=A0

=C2=A0

From: Robert Moskowitz <rgm@labs.htt-consult.com>=

Date: Thursday, 14 January 2021 at 16:08

To: Eric Vyncke <evyncke@cisco.com>, "Eric Vyncke (evyncke)" <evyncke=3D40cisco.com@= dmarc.ietf.org>, "hi= psec@ietf.org" <hips= ec@ietf.org>, "draft-ietf-hip-dex@ietf.org" <draft-ietf-hip-dex@ietf.org>, Miika Komu <miika.komu@ericsson.com>

Cc: Roman Danyliw <rdd@cert.org>, Eric Rescorla &l= t;ekr@rtfm.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, &= quot;rene.hummen@belden.com" <rene.hummen@belden.com>, Benjamin Kaduk <kaduk@mit.edu>, Erik Kline <ek.ietf@gmail.com>

Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...

=C2=A0

I had hoped to get -23 out end of last week, and missed my cutoff.=C2=A0 I am now in IACR's= Real World Crypto, where I have gotten a couple pointers for DRIP work.

=C2=A0

I was waiting for two analyzes that I got Jan 4, and incorporating them in.=C2=A0 I believe these SHOULD address much of EKR's questions.

=C2=A0

I will have a run of 1M DEX random HIs to HITs generated with no duplicates that I add in an Appendix along with the Python code.

=C2=A0

I am adding a BEX/DEX crypto cost into 1.2, probably 1.2.1:

=C2=A0

For an Initiator, BEX is:

=C2=A0

2 PK sig varifications.

1 PK sig generation.

1 DH keypair generation.

1 DH secret derivation.

=C2=A0

DEX is:

=C2=A0

1 DH secret derivation.

=C2=A0

I have cycles for these and a paper to reference, except ECDH keypair generation, on an 8 bit process and the numbers are big.=C2=A0 But I think that part belongs in an Appendix.

=C2=A0

So unlikely Friday.=C2=A0 But early the following week.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On 1/12/21 6:19 AM, Eric Vyncke (evyncke) wrote:

Two months after the email below, I sending a kind reminder to authors and WG.

=C2=A0

With the -22, a lot of (if not all ) SEC ADs=E2=80=99 DISCUSS points should have been addressed.

=C2=A0

As far as I can tell, the other remaining issue was Ekr=E2=80=99s one about why forfeiting FS= when some algorithm could do it in a reasonable time. In an email to authors and ADs, Eric R. wrote =E2=80=9Cit defines a= set of parameters (the NIST curves) which are slower w/o FS than other parameters (X25519) are w/ FS. This fact calls into question the need to dispense with FS.=E2=80=9D

=C2=A0

While 2 months ago I put a deadline for tomorrow, I (as the responsible AD) am flexible of course but we cannot linger anymore. I know that a -23 is in the work for weeks =3D> let=E2=80=99s publish it in the= coming days.

=C2=A0

Else, next week we will need to either change the intended status to experimental or declare the document dead by lack of energy. The latter does not have my preference obviously.

=C2=A0

Regards

=C2=A0

-=C3=A9ric

=C2=A0

=C2=A0

From: Hipsec mailto:hipsec-bounces@ietf.org on behalf of "Eric Vyncke (evyncke)" mailto:evyncke= =3D40cisco.com@dmarc.ietf.org

Date: Friday, 13 November 2020 at 15:32

To: mai= lto:hipsec@ietf.org mailto:h= ipsec@ietf.org, mailto:draft-ietf-hip-dex@ietf.org mailto:draft-ietf-hip-dex@ietf.org, Robert Moskowitz mailto:rgm@labs.htt-consult.com, Miika Komu mailto:miika.komu@ericsson.com

Cc: Roman Danyliw mailto:rdd@cert.org, Eric Rescorla ma= ilto:ekr@rtfm.com, Gonzalo Camarillo mailto:gonzalo.camarillo@ericsson.com, m= ailto:rene.hummen@belden.com m= ailto:rene.hummen@belden.com, Benjamin Kaduk mailto:kaduk@mit.edu, Erik Kline mailto:ek.ietf@gmail.com

Subject: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...

=C2=A0

Dear HIP, dear authors,

=C2=A0

This document was requested for publication [1] in February 2018 (2.5 years ago), then its IESG evaluation has been deferred, then I took over this document from Terry Manderson in March 2019, then it went again through IESG evaluation in July 2020 and there are still DISCUSS points to be addressed even after a couple of revised I-D...

=C2=A0

Difficult not to observe that this document does not progress very fast.

=C2=A0

Moreover, this document is a normative reference for rfc4423-bis waiting in the RFC editor queue since March 2019... So, also blocking the HIP-NAT document [2].

=C2=A0

After discussion with the HIP chair, Gonzalo in cc, we have taken the following decision: if a revised I-D addressing remaining DISCUSS points + Ekr=E2=80= =99s ones is not uploaded within 2 months (13th of January 2021), then I will request the HIP WG to accept the complete removal of section A.3.3 of the rfc4423-bis document (1 page about HIP-DEX in the appendix) + the reference to the HIP-DEX document [3]. This will allow the immediate publication of the rfc4423-bis and HIP-NAT documents.

=C2=A0

The HIP DEX authors may also select to change the intended status of the document to =E2=80=98experimental=E2=80=99 (if the HIP WG agrees) as this= may reduce the security requirements by the SEC AD and Ekr.

=C2=A0

Gonzalo and I are still hoping to get a revised HIP-DEX shortly,

=C2=A0

Regards

=C2=A0

-=C3=A9ric

=C2=A0

[1] https://datatracker.ietf.org/doc/draft-i= etf-hip-dex/history/

[2] https://www.rfc-editor.org/cluster_info.php?ci= d=3DC386

[3] and possibly I will set the state of HIP-DEX as =E2=80=98dead=E2=80=99 on the datatracker=

=C2=A0

=C2=A0

--

Robert Moskowitz

Owner

HTT Consulting

C:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0248-219-2059=

F:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0248-968-2824=

E:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0mailto:rgm@labs.htt-consult.com=

=C2=A0

There's no limit to what can be accomplished if it doesn't matter who gets the credit<= /u>




--0000000000000c4a5305b9412625-- From nobody Tue Jan 19 12:25:04 2021 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512A03A1355; Tue, 19 Jan 2021 06:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, 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 UhwqjQdOCJGC; Tue, 19 Jan 2021 06:29:36 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 399B33A15C7; Tue, 19 Jan 2021 06:29:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 7C4B562470; Tue, 19 Jan 2021 09:29:12 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5QS3lGiO79r2; Tue, 19 Jan 2021 09:28:41 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 2CA5F623C1; Tue, 19 Jan 2021 09:28:37 -0500 (EST) To: Eric Rescorla Cc: "Eric Vyncke (evyncke)" , Robert Moskowitz , "hipsec@ietf.org" , "draft-ietf-hip-dex@ietf.org" , Miika Komu , Roman Danyliw , Gonzalo Camarillo , "rene.hummen@belden.com" , Benjamin Kaduk , Erik Kline , Adam Wiethuechter References: <68AF0368-8CB8-4DF3-A33E-0AA28E61B5F5@cisco.com> <45191baf-ee46-89b8-fe84-742c5c17aadc@labs.htt-consult.com> <41AFBFEA-7119-451B-BC54-46CBB41274CA@cisco.com> <5f52aa64-48aa-87d3-5225-1741ca87b89d@htt-consult.com> <769d84b8-0e9f-dc8d-ee3e-62e724a830fc@htt-consult.com> From: Robert Moskowitz Message-ID: <6e141f89-2308-563c-24fd-bba941d0dad7@htt-consult.com> Date: Tue, 19 Jan 2021 09:28:26 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9BBE3146E017A2C40B48E703" Content-Language: en-US Archived-At: X-Mailman-Approved-At: Tue, 19 Jan 2021 12:24:34 -0800 Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13... X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 14:29:42 -0000 This is a multi-part message in MIME format. --------------9BBE3146E017A2C40B48E703 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X25519 (and x448) is the only curve remaining in HIP DEX. In checking on this, I see I do need to remove text from 9.3 which is the only remaining reference. Of course there is the valid question of why x448 is still there. Probably should remove it as well. So looking into p384: If you follow this link: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwi0_P_ZlKjuAhVGHc0KHSyyDdgQFjAEegQIBRAC&url=https%3A%2F%2Fcryptobook.nakov.com%2Fasymmetric-key-ciphers%2Felliptic-curve-cryptography-ecc&usg=AOvVaw3i71pEYmIH0HT9pwbTca4j you get a very recent paper on P-256 and it is slower than X25519. Then there is this: https://cockrum.net/Implementation_of_ECC_on_an_8-bit_microcontroller.pdf https://arxiv.org/pdf/1902.10313.pdf If you want to roll your own test: https://github.com/kmackay/micro-ecc But again, on your recommendation (and a good one!), I removed the NIST curves due to their poorer performance over x25519. On 1/19/21 8:51 AM, Eric Rescorla wrote: > Thanks for the link. However, this paper appears only to cover X25519. > We'd need a comparison of this to P384, etc. in order to assess the > relative performance of SIGMA-style protocols with NIST curves with > HIP-DEX with X25519 > > On Mon, Jan 18, 2021 at 8:35 AM Robert Moskowitz > wrote: > > Ah, found the paper 'free' from: > > https://www.researchgate.net/publication/300253314_Efficient_and_Secure_Elliptic_Curve_Cryptography_for_8-bit_AVR_Microcontrollers > > > pg 13 is the table I am using.  Please check that you can access > this URL. > > On 1/18/21 11:13 AM, Robert Moskowitz wrote: >> Oops hold it on that paywall URL issue.  I responded with a >> different paper.  All else is still ok, but let me dig a big more >> on that paper for non-IACR members. >> >> On 1/18/21 11:06 AM, Robert Moskowitz wrote: >>> >>> >>> On 1/18/21 9:12 AM, Eric Vyncke (evyncke) wrote: >>>> >>>> TD ;LR : more work to be done, deadline this Thursday 21st >>>> >>>> Bob, >>>> >>>> Thank you for the -23 (and Adam W for the footwork)and I >>>> understand that you are quite busy. >>>> >>>> Here is the link to the diff between -21 and -23: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 >>>> >>>> (i.e., the one used by July 2020 IESG evaluation and the latest >>>> one) >>>> >>>> After the July 2020 IESG evaluation based on -21, there were a >>>> couple of points to be addressed(with some comments of mine as >>>> EVY>): >>>> >>>> * Roman: “Section 6.3.  Per the definition of IKM, when >>>> should these two different derivations be used? " >>>> o EVY> indeed, IKMm and IKMp are both defined but nothing >>>> is said which one to use in which case. >>>> >>> >>>        IKM       IKMm for Master Key SA Input keying material >>>                  or >>>                  IKMp for Pair-wise Key SA Input keying material >>> >>>        IKMm      Kij | I_NONCE >>>        IKMp      Kij | I_NONCE | (concatenated random values of the >>>                      ENCRYPTED_KEY parameters in the same order as >>>                      the HITs with sort(HIT-I | HIT-R)) >>> >>> Seems clear that IKMm is for the Master Key SA and IKMp is for >>> the Pair-wise Key SA. >>> >>>> * Roman "discuss-discuss" (read this as request for reply and >>>> non-blocking) about "further implementation experience >>>> provides better guidance" in sections 6 and 9. >>>> o EVY> this really pleads for experimental status >>>> >>> >>> The only place this text exists anymore is in Appendix C:  iESG >>> Considerations >>> >>> Perhaps I should delete it from there. >>> >>>> o >>>> >>>> >>>> * Benjamin on FOLD collisions >>>> o EVY> IMHO addressed in the new section 3.2.1 >>>> >>> >>> I believe I have this covered.  We have the Python scripts for >>> tests, but this is a lot of code to put into the document.  >>> Right now it is privately held by Adam and I.  If called on, we >>> can find some permanent home for it. >>> >>>> o >>>> >>>> >>>> * Benjamin on ACL to counter FOLD collisions in section 3.2.1 >>>> o EVY> still light on the ACL but the above should clear it >>>> >>> >>> Sec 7.1 is referenced. >>> >>>> o >>>> >>>> >>>> * Benjamin "how is it known that the peer should be using DEX >>>> vs. BEX" >>>> o EVY> partially addressed in section 1.2 but should be >>>> repeated in the security section >>>> >>> >>> I can create a sec 9.1 (pushing down the current 9.1): >>> >>> 9.1 Caution on using HIP DEX rather than HIP BEX >>> >>>    Due to the substantially reduced security guarantees of HIP DEX >>>    compared to HIP BEX, HIP DEX MUST only be used when at least >>> one of >>>    the two endpoints is a class 0 or 1 constrained device defined in >>>    Section 3 of [RFC7228]).  HIP DEX MUST NOT be used when both >>>    endpoints are class 2 devices or unconstrained. >>> >>> >>> Will this work? >>> >>>> o >>>> >>>> >>>> * Benjamin lack of discussion on the security consequences of >>>> inadvertent counter reuse in AES-CTR >>>> >>> >>> See sec 9.1 >>> >>>> * >>>> >>>> >>>> * Benjamin "presence of a CSPRNG in order to obtain secure >>>> session keys" >>>> >>> >>> 9.  Security Considerations >>> >>> .... >>> >>>    *  The strength of the keys for both the Master and Pair-wise >>> Key SAs >>>       is based on the quality of the random keying material >>> generated by >>>       the Initiator and the Responder.  As either peer may be a >>> sensor >>>       or an actuator device, there is a natural concern about the >>>       quality of its random number generator.  Thus at least a >>> CSPRNG >>>       SHOULD be used. >>> >>> >>>> * >>>> >>>> >>>> >>>> * Benjamin "usage of CMAC instead of HMAC" about KEYMAT algorithm >>>> o EVY> new reference to NIST papers seems to address this >>>> concern >>>> >>> >>> Ben did agree in an email that the SP800-56C and 108 addressed >>> the concern.  I did not need to go further. >>> >>>> o >>>> >>>> >>>> * Ekr’s one about why forfeiting FS when some algorithm could >>>> do it in a reasonable time. In an email to authors and ADs, >>>> Eric R. wrote “it defines a set of parameters (the NIST >>>> curves) which are slower w/o FS than other parameters >>>> (X25519) are w/ FS. This fact calls into question the need >>>> to dispense with FS.” >>>> o EVY> the additional section 1.2.1 and the reference to >>>> a paywall EfficientECC reference do not offer a >>>> conclusive motivation for an IETF standards w/o FS. >>>> >>> >>> Paywall?  Hmm.  I got it free.  I will have to check into this.  >>> It may be to some cookie I have on this system.  Or the DOI has >>> the wrong URL. >>> >>> Ah, that URL works for me because I am an IACR member. For all else: >>> >>> https://link.springer.com/article/10.1007/s10623-015-0087-1 >>> >>> >>> So I will change the reference.  But please check this out.  I >>> tried it on another machine that should not have my IACR >>> cookies, but... >>> >>> >>> >>>> o >>>> >>>> >>>> >>>> >>>> ***Bottom line, the document is not yet ready to be >>>> approved.*** (even if big progress has been made) >>>> >>>> As written in November (see below), the situation has lingered >>>> for too long and is blocking the HIP-NAT and rfc4423-bis >>>> documents. >>>> >>>> *** Therefore, I request the authors for a revised I-D >>>> addressing the above (and noting again that a change to >>>> ‘experimental’ – as there are no deployed implementations – >>>> could probably fix all of them) before Thursday 21st of January >>>> midnight UTC else I will ask the HIPSEC WG to agree removing >>>> the HIP-DEX section from the architecture document. *** >>>> >>> >>> Does the above address the open items? >>> >>>> All in all, there have been a couple of significant changes >>>> (I_NONCE, some deleted ciphers) since the IETF last call (see >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 >>>> >>>> ), so, another IETF Last Call is required but should not be a >>>> real problem. >>>> >>>> -éric >>>> >>>> From: Robert Moskowitz >>>> >>>> >>>> Date: Thursday, 14 January 2021 at 16:08 >>>> >>>> To: Eric Vyncke , >>>> "Eric Vyncke (evyncke)" >>>> , "hipsec@ietf.org" >>>> >>>> , "draft-ietf-hip-dex@ietf.org" >>>> >>>> >>>> , Miika Komu >>>> >>>> >>>> Cc: Roman Danyliw , Eric >>>> Rescorla , Gonzalo >>>> Camarillo >>>> , >>>> "rene.hummen@belden.com" >>>> , >>>> Benjamin Kaduk , Erik >>>> Kline >>>> >>>> Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 >>>> pending issues... before 2021-Jan-13... >>>> >>>> I had hoped to get -23 out end of last week, and missed my >>>> cutoff.  I am now in IACR's Real World Crypto, where I have >>>> gotten a couple pointers for DRIP work. >>>> >>>> I was waiting for two analyzes that I got Jan 4, and >>>> incorporating them in.  I believe these SHOULD address much of >>>> EKR's questions. >>>> >>>> I will have a run of 1M DEX random HIs to HITs generated with >>>> no duplicates that I add in an Appendix along with the Python code. >>>> >>>> I am adding a BEX/DEX crypto cost into 1.2, probably 1.2.1: >>>> >>>> For an Initiator, BEX is: >>>> >>>> 2 PK sig varifications. >>>> >>>> 1 PK sig generation. >>>> >>>> 1 DH keypair generation. >>>> >>>> 1 DH secret derivation. >>>> >>>> DEX is: >>>> >>>> 1 DH secret derivation. >>>> >>>> I have cycles for these and a paper to reference, except ECDH >>>> keypair generation, on an 8 bit process and the numbers are >>>> big.  But I think that part belongs in an Appendix. >>>> >>>> So unlikely Friday.  But early the following week. >>>> >>>> On 1/12/21 6:19 AM, Eric Vyncke (evyncke) wrote: >>>> >>>> Two months after the email below, I sending a kind reminder to >>>> authors and WG. >>>> >>>> With the -22, a lot of (if not all ) SEC ADs’ DISCUSS points >>>> should have been addressed. >>>> >>>> As far as I can tell, the other remaining issue was Ekr’s one >>>> about why forfeiting FS when some algorithm could do it in a >>>> reasonable time. In an email to authors and ADs, Eric R. wrote >>>> “it defines a set of parameters (the NIST curves) which are >>>> slower w/o FS than other parameters (X25519) are w/ FS. This >>>> fact calls into question the need to dispense with FS.” >>>> >>>> While 2 months ago I put a deadline for tomorrow, I (as the >>>> responsible AD) am flexible of course but we cannot linger >>>> anymore. I know that a -23 is in the work for weeks => let’s >>>> publish it in the coming days. >>>> >>>> Else, next week we will need to either change the intended >>>> status to experimental or declare the document dead by lack of >>>> energy. The latter does not have my preference obviously. >>>> >>>> Regards >>>> >>>> -éric >>>> >>>> From: Hipsec mailto:hipsec-bounces@ietf.org >>>> on behalf of "Eric Vyncke >>>> (evyncke)" mailto:evyncke=40cisco.com@dmarc.ietf.org >>>> >>>> >>>> Date: Friday, 13 November 2020 at 15:32 >>>> >>>> To: mailto:hipsec@ietf.org >>>> mailto:hipsec@ietf.org , >>>> mailto:draft-ietf-hip-dex@ietf.org >>>> >>>> mailto:draft-ietf-hip-dex@ietf.org >>>> , Robert Moskowitz >>>> mailto:rgm@labs.htt-consult.com >>>> , Miika Komu >>>> mailto:miika.komu@ericsson.com >>>> >>>> Cc: Roman Danyliw mailto:rdd@cert.org , >>>> Eric Rescorla mailto:ekr@rtfm.com , >>>> Gonzalo Camarillo mailto:gonzalo.camarillo@ericsson.com >>>> , >>>> mailto:rene.hummen@belden.com >>>> mailto:rene.hummen@belden.com , >>>> Benjamin Kaduk mailto:kaduk@mit.edu , >>>> Erik Kline mailto:ek.ietf@gmail.com >>>> >>>> Subject: [Hipsec] Need to close all draft-ietf-hip-dex-21 >>>> pending issues... before 2021-Jan-13... >>>> >>>> Dear HIP, dear authors, >>>> >>>> This document was requested for publication [1] in February >>>> 2018 (2.5 years ago), then its IESG evaluation has been >>>> deferred, then I took over this document from Terry Manderson >>>> in March 2019, then it went again through IESG evaluation in >>>> July 2020 and there are still DISCUSS points to be addressed >>>> even after a couple of revised I-D... >>>> >>>> Difficult not to observe that this document does not progress >>>> very fast. >>>> >>>> Moreover, this document is a normative reference for >>>> rfc4423-bis waiting in the RFC editor queue since March 2019... >>>> So, also blocking the HIP-NAT document [2]. >>>> >>>> After discussion with the HIP chair, Gonzalo in cc, we have >>>> taken the following decision: if a revised I-D addressing >>>> remaining DISCUSS points + Ekr’s ones is not uploaded within 2 >>>> months (13th of January 2021), then I will request the HIP WG >>>> to accept the complete removal of section A.3.3 of the >>>> rfc4423-bis document (1 page about HIP-DEX in the appendix) + >>>> the reference to the HIP-DEX document [3]. This will allow the >>>> immediate publication of the rfc4423-bis and HIP-NAT documents. >>>> >>>> The HIP DEX authors may also select to change the intended >>>> status of the document to ‘experimental’ (if the HIP WG agrees) >>>> as this may reduce the security requirements by the SEC AD and Ekr. >>>> >>>> Gonzalo and I are still hoping to get a revised HIP-DEX shortly, >>>> >>>> Regards >>>> >>>> -éric >>>> >>>> [1] >>>> https://datatracker.ietf.org/doc/draft-ietf-hip-dex/history/ >>>> >>>> >>>> [2] https://www.rfc-editor.org/cluster_info.php?cid=C386 >>>> >>>> >>>> [3] and possibly I will set the state of HIP-DEX as ‘dead’ on >>>> the datatracker >>>> >>>> -- >>>> >>>> Robert Moskowitz >>>> >>>> Owner >>>> >>>> HTT Consulting >>>> >>>> C:      248-219-2059 >>>> >>>> F:      248-968-2824 >>>> >>>> E: mailto:rgm@labs.htt-consult.com >>>> >>>> >>>> There's no limit to what can be accomplished if it doesn't >>>> matter who gets the credit >>>> >>> >> > --------------9BBE3146E017A2C40B48E703 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit X25519 (and x448) is the only curve remaining in HIP DEX.

In checking on this, I see I do need to remove text from 9.3 which is the only remaining reference.

Of course there is the valid question of why x448 is still there.  Probably should remove it as well.

So looking into p384:

If you follow this link:

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwi0_P_ZlKjuAhVGHc0KHSyyDdgQFjAEegQIBRAC&url=https%3A%2F%2Fcryptobook.nakov.com%2Fasymmetric-key-ciphers%2Felliptic-curve-cryptography-ecc&usg=AOvVaw3i71pEYmIH0HT9pwbTca4j

you get a very recent paper on P-256 and it is slower than X25519.

Then there is this:

https://cockrum.net/Implementation_of_ECC_on_an_8-bit_microcontroller.pdf

https://arxiv.org/pdf/1902.10313.pdf

If you want to roll your own test:

https://github.com/kmackay/micro-ecc

But again, on your recommendation (and a good one!), I removed the NIST curves due to their poorer performance over x25519.



On 1/19/21 8:51 AM, Eric Rescorla wrote:
Thanks for the link. However, this paper appears only to cover X25519. We'd need a comparison of this to P384, etc. in order to assess the relative performance of SIGMA-style protocols with NIST curves with HIP-DEX with X25519

On Mon, Jan 18, 2021 at 8:35 AM Robert Moskowitz <rgm@htt-consult.com> wrote:
Ah, found the paper 'free' from:

https://www.researchgate.net/publication/300253314_Efficient_and_Secure_Elliptic_Curve_Cryptography_for_8-bit_AVR_Microcontrollers

pg 13 is the table I am using.  Please check that you can access this URL.

On 1/18/21 11:13 AM, Robert Moskowitz wrote:
Oops hold it on that paywall URL issue.  I responded with a different paper.  All else is still ok, but let me dig a big more on that paper for non-IACR members.

On 1/18/21 11:06 AM, Robert Moskowitz wrote:


On 1/18/21 9:12 AM, Eric Vyncke (evyncke) wrote:

TD ;LR : more work to be done, deadline this Thursday 21st

 

Bob,

 

Thank you for the -23 (and Adam W for the footwork) and I understand that you are quite busy.

 

Here is the link to the diff between -21 and -23: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 (i.e., the one used by July 2020 IESG evaluation and the latest one)

 

After the July 2020 IESG evaluation based on -21, there were a couple of points to be addressed (with some comments of mine as EVY>):

  • Roman: “Section 6.3.  Per the definition of IKM, when should these two different derivations be used? "
    • EVY> indeed, IKMm and IKMp are both defined but nothing is said which one to use in which case.

       IKM       IKMm for Master Key SA Input keying material
                 or
                 IKMp for Pair-wise Key SA Input keying material

       IKMm      Kij | I_NONCE
       IKMp      Kij | I_NONCE | (concatenated random values of the
                     ENCRYPTED_KEY parameters in the same order as
                     the HITs with sort(HIT-I | HIT-R))

Seems clear that IKMm is for the Master Key SA and IKMp is for the Pair-wise Key SA.

  • Roman "discuss-discuss" (read this as request for reply and non-blocking) about " further implementation experience provides better guidance" in sections 6 and 9.
    • EVY> this really pleads for experimental status

The only place this text exists anymore is in Appendix C:  iESG Considerations

Perhaps I should delete it from there.


  • Benjamin on FOLD collisions
    • EVY> IMHO addressed in the new section 3.2.1

I believe I have this covered.  We have the Python scripts for tests, but this is a lot of code to put into the document.  Right now it is privately held by Adam and I.  If called on, we can find some permanent home for it.


  • Benjamin on ACL to counter FOLD collisions in section 3.2.1
    • EVY> still light on the ACL but the above should clear it

Sec 7.1 is referenced.


  • Benjamin "how is it known that the peer should be using DEX vs. BEX"
    • EVY> partially addressed in section 1.2 but should be repeated in the security section

I can create a sec 9.1 (pushing down the current 9.1):

9.1 Caution on using HIP DEX rather than HIP BEX

   Due to the substantially reduced security guarantees of HIP DEX
   compared to HIP BEX, HIP DEX MUST only be used when at least one of
   the two endpoints is a class 0 or 1 constrained device defined in
   Section 3 of [RFC7228]).  HIP DEX MUST NOT be used when both
   endpoints are class 2 devices or unconstrained.


Will this work?


  • Benjamin lack of discussion on the security consequences of inadvertent counter reuse in AES-CTR

See sec 9.1


  • Benjamin "presence of a CSPRNG in order to obtain secure session keys"

9.  Security Considerations

....

   *  The strength of the keys for both the Master and Pair-wise Key SAs
      is based on the quality of the random keying material generated by
      the Initiator and the Responder.  As either peer may be a sensor
      or an actuator device, there is a natural concern about the
      quality of its random number generator.  Thus at least a CSPRNG
      SHOULD be used.



  • Benjamin "usage of CMAC instead of HMAC" about KEYMAT algorithm
    • EVY> new reference to NIST papers seems to address this concern

Ben did agree in an email that the SP800-56C and 108 addressed the concern.  I did not need to go further.


  • Ekr’s one about why forfeiting FS when some algorithm could do it in a reasonable time. In an email to authors and ADs, Eric R. wrote “it defines a set of parameters (the NIST curves) which are slower w/o FS than other parameters (X25519) are w/ FS. This fact calls into question the need to dispense with FS.”
    • EVY> the additional section 1.2.1 and the reference to a paywall EfficientECC reference do not offer a conclusive motivation for an IETF standards w/o FS.

Paywall?  Hmm.  I got it free.  I will have to check into this.  It may be to some cookie I have on this system.  Or the DOI has the wrong URL.

Ah, that URL works for me because I am an IACR member.  For all else:

https://link.springer.com/article/10.1007/s10623-015-0087-1

So I will change the reference.  But please check this out.  I tried it on another machine that should not have my IACR cookies, but...




 

***Bottom line, the document is not yet ready to be approved.*** (even if big progress has been made)

 

As written in November (see below), the situation has lingered for too long and is blocking the HIP-NAT and rfc4423-bis documents.

 

*** Therefore, I request the authors for a revised I-D addressing the above (and noting again that a change to ‘experimental’ – as there are no deployed implementations – could probably fix all of them) before Thursday 21st of January midnight UTC else I will ask the HIPSEC WG to agree removing the HIP-DEX section from the architecture document. ***


Does the above address the open items?

 

All in all, there have been a couple of significant changes (I_NONCE, some deleted ciphers) since the IETF last call (see https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 ), so, another IETF Last Call is required but should not be a real problem.

 

 

-éric

 

 

 

From: Robert Moskowitz <rgm@labs.htt-consult.com>

Date: Thursday, 14 January 2021 at 16:08

To: Eric Vyncke <evyncke@cisco.com>, "Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>, "hipsec@ietf.org" <hipsec@ietf.org>, "draft-ietf-hip-dex@ietf.org" <draft-ietf-hip-dex@ietf.org>, Miika Komu <miika.komu@ericsson.com>

Cc: Roman Danyliw <rdd@cert.org>, Eric Rescorla <ekr@rtfm.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "rene.hummen@belden.com" <rene.hummen@belden.com>, Benjamin Kaduk <kaduk@mit.edu>, Erik Kline <ek.ietf@gmail.com>

Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...

 

I had hoped to get -23 out end of last week, and missed my cutoff.  I am now in IACR's Real World Crypto, where I have gotten a couple pointers for DRIP work.

 

I was waiting for two analyzes that I got Jan 4, and incorporating them in.  I believe these SHOULD address much of EKR's questions.

 

I will have a run of 1M DEX random HIs to HITs generated with no duplicates that I add in an Appendix along with the Python code.

 

I am adding a BEX/DEX crypto cost into 1.2, probably 1.2.1:

 

For an Initiator, BEX is:

 

2 PK sig varifications.

1 PK sig generation.

1 DH keypair generation.

1 DH secret derivation.

 

DEX is:

 

1 DH secret derivation.

 

I have cycles for these and a paper to reference, except ECDH keypair generation, on an 8 bit process and the numbers are big.  But I think that part belongs in an Appendix.

 

So unlikely Friday.  But early the following week.

 

 

 

 

 

On 1/12/21 6:19 AM, Eric Vyncke (evyncke) wrote:

Two months after the email below, I sending a kind reminder to authors and WG.

 

With the -22, a lot of (if not all ) SEC ADs’ DISCUSS points should have been addressed.

 

As far as I can tell, the other remaining issue was Ekr’s one about why forfeiting FS when some algorithm could do it in a reasonable time. In an email to authors and ADs, Eric R. wrote “it defines a set of parameters (the NIST curves) which are slower w/o FS than other parameters (X25519) are w/ FS. This fact calls into question the need to dispense with FS.”

 

While 2 months ago I put a deadline for tomorrow, I (as the responsible AD) am flexible of course but we cannot linger anymore. I know that a -23 is in the work for weeks => let’s publish it in the coming days.

 

Else, next week we will need to either change the intended status to experimental or declare the document dead by lack of energy. The latter does not have my preference obviously.

 

Regards

 

-éric

 

 

From: Hipsec mailto:hipsec-bounces@ietf.org on behalf of "Eric Vyncke (evyncke)" mailto:evyncke=40cisco.com@dmarc.ietf.org

Date: Friday, 13 November 2020 at 15:32

To: mailto:hipsec@ietf.org mailto:hipsec@ietf.org, mailto:draft-ietf-hip-dex@ietf.org mailto:draft-ietf-hip-dex@ietf.org, Robert Moskowitz mailto:rgm@labs.htt-consult.com, Miika Komu mailto:miika.komu@ericsson.com

Cc: Roman Danyliw mailto:rdd@cert.org, Eric Rescorla mailto:ekr@rtfm.com, Gonzalo Camarillo mailto:gonzalo.camarillo@ericsson.com, mailto:rene.hummen@belden.com mailto:rene.hummen@belden.com, Benjamin Kaduk mailto:kaduk@mit.edu, Erik Kline mailto:ek.ietf@gmail.com

Subject: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...

 

Dear HIP, dear authors,

 

This document was requested for publication [1] in February 2018 (2.5 years ago), then its IESG evaluation has been deferred, then I took over this document from Terry Manderson in March 2019, then it went again through IESG evaluation in July 2020 and there are still DISCUSS points to be addressed even after a couple of revised I-D...

 

Difficult not to observe that this document does not progress very fast.

 

Moreover, this document is a normative reference for rfc4423-bis waiting in the RFC editor queue since March 2019... So, also blocking the HIP-NAT document [2].

 

After discussion with the HIP chair, Gonzalo in cc, we have taken the following decision: if a revised I-D addressing remaining DISCUSS points + Ekr’s ones is not uploaded within 2 months (13th of January 2021), then I will request the HIP WG to accept the complete removal of section A.3.3 of the rfc4423-bis document (1 page about HIP-DEX in the appendix) + the reference to the HIP-DEX document [3]. This will allow the immediate publication of the rfc4423-bis and HIP-NAT documents.

 

The HIP DEX authors may also select to change the intended status of the document to ‘experimental’ (if the HIP WG agrees) as this may reduce the security requirements by the SEC AD and Ekr.

 

Gonzalo and I are still hoping to get a revised HIP-DEX shortly,

 

Regards

 

-éric

 

[1] https://datatracker.ietf.org/doc/draft-ietf-hip-dex/history/

[2] https://www.rfc-editor.org/cluster_info.php?cid=C386

[3] and possibly I will set the state of HIP-DEX as ‘dead’ on the datatracker

 

 

--

Robert Moskowitz

Owner

HTT Consulting

C:      248-219-2059

F:      248-968-2824

E:      mailto:rgm@labs.htt-consult.com

 

There's no limit to what can be accomplished if it doesn't matter who gets the credit





--------------9BBE3146E017A2C40B48E703-- From nobody Tue Jan 19 12:25:07 2021 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35173A1560; Tue, 19 Jan 2021 06:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=BXP4L+LS; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=UaYSIYPU 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 R95Q9S9jKUdf; Tue, 19 Jan 2021 06:44:35 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F73C3A155D; Tue, 19 Jan 2021 06:44:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=73879; q=dns/txt; s=iport; t=1611067475; x=1612277075; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8gWmIBAl/c6wN84As3EH+3O1nmvkjbJqiGvRAsU4G8Q=; b=BXP4L+LSG3lD17IckV4WlLV2KQQSw17HCJSAQPjiB9Nn7EcSF/+XbJ0f KsAA/9EjP68UqmT2WD7pU2u8Kj1yqK+S6SykqtJv+VQlQydzYUtAPGtJu gaPOWTRJxRNNLa25eoGFv8L/P8tBZk/U19vTsGH/7b+ufy8X0AGYvN1R1 g=; X-IPAS-Result: =?us-ascii?q?A0DxAABN7gZgkJJdJa1GGQMbAQEBAQEBAQEFAQEBEgEBA?= =?us-ascii?q?QMDAQEBgg+BIzAjBih9Wy8vhD+DSAOOBQOKHIR0igOBQoERA1QDCAEBAQ0BA?= =?us-ascii?q?SUIAgQBAYRKAheBXAIlOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQGGO?= =?us-ascii?q?AyFcwEBAQQaAwYKEwEBNwEPAgEGAg4DAQIBAiEBBgMCAgIfERQDBggCBAENB?= =?us-ascii?q?YMmAYF+VwMuAQ5AknaQawKKJXaBMoMFAQEGgTMBAwICDEGDAw0LghEDBoE4g?= =?us-ascii?q?naEAAGBCoQXgR8mG4FBP4EQASccglY+gQQBgRZCAQECAQEVgQwFAQwGATgJA?= =?us-ascii?q?QUHCRGCUjSCLIFPCQEQWQYCExEqEAEDGCMICgYgAg0hIQISCwgEFhAIEQEFG?= =?us-ascii?q?gQCBgkDEQUHBzmPWYJbAT+HNIw4kGdYCoJ3iS+GfoYdhR4DH4MqijCFYIlAh?= =?us-ascii?q?XAkk3eLHIJ6jmUCBBgBhDUCAgICBAUCDgEBBoFtIRRVcHAVZQGCCgEzUBcCD?= =?us-ascii?q?VeNSgwMAgkUbgEBgkqFFIUJATp0AjUCAwMBCQEBAwl8iSeBZl8BAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AgwAz0hzK5tecS7fXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRaBt/VxkBrCWoPA9vZYzeHRtvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX+e0GXqXq09iMWBl?= =?us-ascii?q?P0Mg8mbujwE5TZ2sKw0e368pbPYgJO0Ty6Z746LBi/oQjL8McMho43IacqwR?= =?us-ascii?q?yPqXxNKOk=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,359,1602547200"; d="scan'208,217";a="670433883" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Jan 2021 14:44:34 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 10JEiXJE022444 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Jan 2021 14:44:34 GMT Received: from xfe-aln-003.cisco.com (173.37.135.123) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 19 Jan 2021 08:44:33 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Tue, 19 Jan 2021 08:44:33 -0600 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 19 Jan 2021 09:44:33 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RpW1Ngv4q2cQD50xfHPZQf1P70BFffFFkcUWHpMJFsxHI5xLfDOmJC2MGH7S6JOykjApxtrvl2iE6+cLHzTqZ85DIH8/1UMUy7ZZh3pXFMxh7plIByPqtyXMJJ2mklaInlmMGF8M/rDP1P74rMru4I/dgxgn1Bm+7KAjq0vrBbIZ4a955SoFPmGf1cykqbgR5+ylIJJMmKhKRfKUC7NuPOjpOZIzE2dGPvh/wL2ElhFji7w3ERcCfDiKzmubahJZHLPmjph5YO1xth12+Gj2nlLd7grUckU4Ws2nHs1ae+e9iEpgFVCTL7hbhs/n5wDTANT1HV4S4184+hlGA9Xs3w== 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=8gWmIBAl/c6wN84As3EH+3O1nmvkjbJqiGvRAsU4G8Q=; b=UkNaZsr7Y/7Hpa7FDD9v38y5JdEsK5pKRMOTVCOQaTFBibr5k2ZB9zbz322JHQ0gEGJWLcAxrv8i4SNNuVWYySyV3/gISrs1lPjq/pwfYQKbobzs2G+moKqENnauXW9KWWXusRf3eyQeDYBIU8pJ04tJNjyPgWEgN2OLofohcU33yy6yjwTxYzQg7TuP6maZIQhO6B3TYH3AN31sY7yS8YItYpL3z/eGWYzbapu86CwNDWmi20jl2YQVbJUPiI+aUYfczVt+2uwuFIcjKXXGKeQgf1cCriJJrneQL1cZ55v4aaSzK6geI8O+QuiCg7LE+Inpvhwj55ya+euqdIhv9Q== 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=8gWmIBAl/c6wN84As3EH+3O1nmvkjbJqiGvRAsU4G8Q=; b=UaYSIYPU4ZDfnXwy8b5zp0JK1DZnG3ELTVtl9uORbWCL2iCJMp1386pl7S4Suek+13qpEcGcAZlwSsbnte6tAG87L/rZlKx5n63XCfoNiYPH4xcKxL+qPxan2sVD31DTx0SpG2eL+d1g7TC1hAVJ6O/IEHWTG0+QImfHijGYnSc= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5048.namprd11.prod.outlook.com (2603:10b6:510:3d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.11; Tue, 19 Jan 2021 14:44:30 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b%3]) with mapi id 15.20.3763.014; Tue, 19 Jan 2021 14:44:29 +0000 From: "Eric Vyncke (evyncke)" To: Robert Moskowitz , Robert Moskowitz , "hipsec@ietf.org" , "draft-ietf-hip-dex@ietf.org" , Miika Komu CC: Roman Danyliw , Eric Rescorla , "Gonzalo Camarillo" , "rene.hummen@belden.com" , Benjamin Kaduk , Erik Kline , Adam Wiethuechter Thread-Topic: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13... Thread-Index: AQHW6ocQR6j818zXLUeYvsVAsj8W+6otktXYgAGMDoA= Date: Tue, 19 Jan 2021 14:44:29 +0000 Message-ID: <0651C536-61F4-4B95-A187-EC8F7BFD058D@cisco.com> References: <68AF0368-8CB8-4DF3-A33E-0AA28E61B5F5@cisco.com> <45191baf-ee46-89b8-fe84-742c5c17aadc@labs.htt-consult.com> <41AFBFEA-7119-451B-BC54-46CBB41274CA@cisco.com> <5f52aa64-48aa-87d3-5225-1741ca87b89d@htt-consult.com> In-Reply-To: <5f52aa64-48aa-87d3-5225-1741ca87b89d@htt-consult.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.45.21011103 authentication-results: htt-consult.com; dkim=none (message not signed) header.d=none;htt-consult.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:e9bb:a31f:ef27:e865] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b5072971-8c57-4fe5-1552-08d8bc88ba3e x-ms-traffictypediagnostic: PH0PR11MB5048: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P7yZpZFpr19M5J2E/nycJ6xq8cDD194YRTuTEIfJb6mgjpU4/7tZI/FF6ZzkTQe72pmbOk7Cf2g8iq8EL7PMSqDOPFBotFnueJtVv9cSxMbmYF5pnm2tri65nJVP+kRMHBxCV4Y83ceClfTHeJ2IR+FxdWNLm07EMNqjGUTvnKayrZknEkH8UiK7wGlfYXla0+JgxMmrHzB3Xb5uQp51xox+LlBTHRiGmcJj9IRm+KAzOrJH0Hj6R/IMFseeybEDlbXb4eprDDTHe+0T4BJPVKMrb/YzjCmIrwgzFoqhKcel/P35DAda1H3U9foZb6yzDhn6jsPmBt/8SptwuSlrcWVFnLUDieV+RLhHFYwkN2ekaypE8a0wL+UX+4VBLInnONEG4r1KyBHYMUyqJktkWSpvUJ+R6jqHDjtwnbpw8KcP6l3ZA3wnEsXHkSm0JCnxfUNMLxKrG9i29s+vJGyLxWoM+ecd8PuDfDB7jpQWhiis3nznEZHsOiqah0YBQvXpD/mTE0EuuW8qTrf0cICtQw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(346002)(136003)(376002)(39860400002)(396003)(66556008)(2906002)(71200400001)(2616005)(8676002)(6486002)(166002)(8936002)(110136005)(54906003)(53546011)(6506007)(4326008)(186003)(66946007)(86362001)(36756003)(66446008)(7416002)(76116006)(91956017)(83380400001)(30864003)(316002)(6512007)(16799955002)(966005)(66476007)(33656002)(64756008)(5660300002)(478600001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?R2RtUEcrNTNuQWMyUlRYS1FXZ2xoZTRNRmxPbEF3dnFiTzVHemp5TzJROXhq?= =?utf-8?B?eTZ1dFVSYVFlQ0ZhNUZRY0JDd0R2d1RHbW03dzFzUDFqUiswV2h6TEhKb1Ew?= =?utf-8?B?TUVDZHV6YUNPY0JiVzhaN0tTMTNXOS9VRVZWVVRMWGJ2bU9LcXJ0bTY3SnFs?= =?utf-8?B?WHU0VXhRa0laYVc1bUlMaWZFc0Q0cm5tcHhtNm9XZVZXZkxud0R4K3drQlNU?= =?utf-8?B?L1YyZjlKRHFOZUVXYmVFRmlpK1lVeHR1Y0tGbE0zK3BkZkdDdVRNUWR1Y1JT?= =?utf-8?B?QmhSSWJZem9oY3dnY3U3dnlWY2VzOWZ1M3VVRFo2SEIwdEpMT2F1WW1Da0NZ?= =?utf-8?B?SmRONzg5OGlWWGY1aHA5QmQvRXl2dE1wNlZ5ZlJCYTNNOHJQcWxiQkt5Y05L?= =?utf-8?B?d0N2L204ZGVKbGVVV2FHbm5zNnZ4emdPOUpsbDFHaWJWOG8rbFlRdDFMalUv?= =?utf-8?B?RHV4U2lEMXpFOUFGWEhlbHFBOEZPMjlicnYxK3kvUy9ZYzJpNjRPSjhzNmdD?= =?utf-8?B?aEZHTEdIYnBpMERSQ1l0Y3E0M0g5MGM0U1laTm8rMmlkeGZQU211UzVzaVZo?= =?utf-8?B?SUhQQnA0ZmxWNndXc3lNWXZxNWFsOEU2N0JiTURkeEd2Z0RWKzg5dnNXQTlz?= =?utf-8?B?MjJ6ZGxzMDdiVmN2ekI0Rk9IRjBXZTltMmlodkM1ODVOYStiWXIvaGZycU5E?= =?utf-8?B?YmlIR0ZiNlpHY2dPenU2WURFeVhTUFJEMVBKVU0rbVpMU1pleFVnd1poM2sy?= =?utf-8?B?RHE1OGoydnFaeUMralF1MTRaVm1lVUFSR1FETTg1L0E0VGJCTmF4bUhFcWtv?= =?utf-8?B?Tks5NTBlVDlCWXEzdTUxSnhJQUdoekRyck9nK0NONTVHK2VaSnZBdTY0NG9x?= =?utf-8?B?aVNBSWIwQXRCNWRodTVBa1pYbmdZVE9IRVljRXNqRERmWHo3VXVEaEhFMktU?= =?utf-8?B?YjdwQkRFNHVNN3crS3BEZnI0TTQwVVQrMHRwZWJZRzNTYm50UFVwUTFDam85?= =?utf-8?B?MHZGL3ZiUmdMdndIZHJoUi9YTnRVc1JJMWFwR21aOUpMbUt2VXFRb0xlekUv?= =?utf-8?B?UE91R0FrK0lwS1BFTGNMSVVOV1grTWZwZldmY2dkWW1saFBLV1Q2dnp4cit1?= =?utf-8?B?SlZiZHpxSDZXZEU0RFlZYzBWdE41eVY1UFA0bmZjRlVTV3poSk9ZbWlyaVY2?= =?utf-8?B?SXFxcEU5U2RIY2pFZFBqWTB4ckpveWhLaUNLU3BGMnlxTjBid3hIMmlpSG9I?= =?utf-8?B?by9HNHYvRGNxUXg3SEJyOWlYdGNsQ0NnTUcwdFZ5Mkg4eHQwVlZWQi9SbHFU?= =?utf-8?B?QjZDbkk3NE0xNHdYOGxuVjcrUFBITXZhVmdibGM2cG5yeXVNdVROUXpNdzFX?= =?utf-8?B?NHdOZ3Y5Y0ZYTGI0dWZXVTFrT2NJL3pLK29veEdFSEVxUGExUHM0ejRhcUhG?= =?utf-8?Q?KVg84o35?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_0651C53661F44B95A187EC8F7BFD058Dciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b5072971-8c57-4fe5-1552-08d8bc88ba3e X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2021 14:44:29.8194 (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: 6svG3meQZD+/RIUayGA/u0qbZEjFlgreO5gOlsi2DpoW0669tjm6MESw8PzlQZ0VKLDPrNdwFj02XGHVLoByNg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5048 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: X-Mailman-Approved-At: Tue, 19 Jan 2021 12:24:34 -0800 Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13... X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 14:44:39 -0000 --_000_0651C53661F44B95A187EC8F7BFD058Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Qm9iLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmVwbHkuIEkgdG9vayBzb21lIHRpbWUgdG8gcmV2 aWV3IHRoZSBwb2ludHMuIExvb2sgZm9yIEVWWTI+IGJlbG93IGJ1dCBhdCBmaXJzdCBzaWdodCwg dGhpcyBsb29rcyByZWFsbHkgZ29vZCB0byBtZSBub3cuIE9mIGNvdXJzZSwgUm9tYW4gYW5kIEJl biB3aWxsIGhhdmUgYSBmaW5hbCBzYXkuDQoNCkFib3V0IEVrcuKAmXMgY29tbWVudCwgSSBhbSBy ZWFkaW5nIHlvdXIgbGF0ZXN0IGVtYWlsIHNlbnQgbWludXRlcyBhZ28sIGFuZCBJIGFtIHN0aWxs IHVuY2xlYXIgd2hlcmUsIGluIHRoZSB0ZXh0LCBpdCBpcyBzaG93biB0aGF0IEZTIGlzIG5vdCBh Y2hpZXZhYmxlLg0KDQpBY3Rpb24gcGxhbjogcGxlYXNlIGFwcGx5IHRoZSBjaGFuZ2VzIHlvdSBo YXZlIHByb3Bvc2VkIGJlbG93LCBwb3N0IGEgcmV2aXNlZCBJLUQsIHRoZW4gb24gbXkgc2lkZToN Cg0KICAqICAgTGF1bmNoaW5nIGFuIElFVEYgTGFzdCBDYWxsIGZvciAyIHdlZWtzIChhcyB3cml0 dGVuIGJlbG93IHNvbWUgaW1wb3J0YW50IGNoYW5nZXMgaGF2ZSBiZWVuIG1hZGUgYnV0IEkgZXhw ZWN0IHRoZSBMQyBldmVudGxlc3MpDQogICogICBQcm9iaW5nIEJlbiAmIFJvbWFuIHRvIHJldmll dyB3aGV0aGVyIHRoZWlyIERJU0NVU1Mgc3RpbGwgaG9sZA0KDQpSZWdhcmRzLCBpdCBzZWVtcyB0 aGF0IHRoZSBjb25jbHVzaW9uIGlzIG5lYXIgOy0pDQoNCi3DqXJpYw0KDQpGcm9tOiBSb2JlcnQg TW9za293aXR6IDxyZ21AaHR0LWNvbnN1bHQuY29tPg0KRGF0ZTogTW9uZGF5LCAxOCBKYW51YXJ5 IDIwMjEgYXQgMTc6MDYNClRvOiBFcmljIFZ5bmNrZSA8ZXZ5bmNrZUBjaXNjby5jb20+LCBSb2Jl cnQgTW9za293aXR6IDxyZ21AbGFicy5odHQtY29uc3VsdC5jb20+LCAiaGlwc2VjQGlldGYub3Jn IiA8aGlwc2VjQGlldGYub3JnPiwgImRyYWZ0LWlldGYtaGlwLWRleEBpZXRmLm9yZyIgPGRyYWZ0 LWlldGYtaGlwLWRleEBpZXRmLm9yZz4sIE1paWthIEtvbXUgPG1paWthLmtvbXVAZXJpY3Nzb24u Y29tPg0KQ2M6IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz4sIEVyaWMgUmVzY29ybGEgPGVr ckBydGZtLmNvbT4sIEdvbnphbG8gQ2FtYXJpbGxvIDxnb256YWxvLmNhbWFyaWxsb0Blcmljc3Nv bi5jb20+LCAicmVuZS5odW1tZW5AYmVsZGVuLmNvbSIgPHJlbmUuaHVtbWVuQGJlbGRlbi5jb20+ LCBCZW5qYW1pbiBLYWR1ayA8a2FkdWtAbWl0LmVkdT4sIEVyaWsgS2xpbmUgPGVrLmlldGZAZ21h aWwuY29tPiwgQWRhbSBXaWV0aHVlY2h0ZXIgPGFkYW0ud2lldGh1ZWNodGVyQGF4ZW50ZXJwcml6 ZS5jb20+DQpTdWJqZWN0OiBSZTogW0hpcHNlY10gTmVlZCB0byBjbG9zZSBhbGwgZHJhZnQtaWV0 Zi1oaXAtZGV4LTIxIHBlbmRpbmcgaXNzdWVzLi4uIGJlZm9yZSAyMDIxLUphbi0xMy4uLg0KDQoN Ck9uIDEvMTgvMjEgOToxMiBBTSwgRXJpYyBWeW5ja2UgKGV2eW5ja2UpIHdyb3RlOg0KDQpURCA7 TFIgOiBtb3JlIHdvcmsgdG8gYmUgZG9uZSwgZGVhZGxpbmUgdGhpcyBUaHVyc2RheSAyMXN0DQoN Cg0KDQpCb2IsDQoNCg0KDQpUaGFuayB5b3UgZm9yIHRoZSAtMjMgKGFuZCBBZGFtIFcgZm9yIHRo ZSBmb290d29yaykgYW5kIEkgdW5kZXJzdGFuZCB0aGF0IHlvdSBhcmUgcXVpdGUgYnVzeS4NCg0K DQoNCkhlcmUgaXMgdGhlIGxpbmsgdG8gdGhlIGRpZmYgYmV0d2VlbiAtMjEgYW5kIC0yMzogaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtaGlwLWRleC0yMyZ1cmwx PWRyYWZ0LWlldGYtaGlwLWRleC0yMSAoaS5lLiwgdGhlIG9uZSB1c2VkIGJ5IEp1bHkgMjAyMCBJ RVNHIGV2YWx1YXRpb24gYW5kIHRoZSBsYXRlc3Qgb25lKQ0KDQoNCg0KQWZ0ZXIgdGhlIEp1bHkg MjAyMCBJRVNHIGV2YWx1YXRpb24gYmFzZWQgb24gLTIxLCB0aGVyZSB3ZXJlIGEgY291cGxlIG9m IHBvaW50cyB0byBiZSBhZGRyZXNzZWQgKHdpdGggc29tZSBjb21tZW50cyBvZiBtaW5lIGFzIEVW WT4pOg0KDQoxLiAgICAgICBSb21hbjog4oCcU2VjdGlvbiA2LjMuICBQZXIgdGhlIGRlZmluaXRp b24gb2YgSUtNLCB3aGVuIHNob3VsZCB0aGVzZSB0d28gZGlmZmVyZW50IGRlcml2YXRpb25zIGJl IHVzZWQ/ICINCg0KMS4gICAgICAgRVZZPiBpbmRlZWQsIElLTW0gYW5kIElLTXAgYXJlIGJvdGgg ZGVmaW5lZCBidXQgbm90aGluZyBpcyBzYWlkIHdoaWNoIG9uZSB0byB1c2UgaW4gd2hpY2ggY2Fz ZS4NCg0KICAgICAgIElLTSAgICAgICBJS01tIGZvciBNYXN0ZXIgS2V5IFNBIElucHV0IGtleWlu ZyBtYXRlcmlhbA0KICAgICAgICAgICAgICAgICBvcg0KICAgICAgICAgICAgICAgICBJS01wIGZv ciBQYWlyLXdpc2UgS2V5IFNBIElucHV0IGtleWluZyBtYXRlcmlhbA0KDQogICAgICAgSUtNbSAg ICAgIEtpaiB8IElfTk9OQ0UNCiAgICAgICBJS01wICAgICAgS2lqIHwgSV9OT05DRSB8IChjb25j YXRlbmF0ZWQgcmFuZG9tIHZhbHVlcyBvZiB0aGUNCiAgICAgICAgICAgICAgICAgICAgIEVOQ1JZ UFRFRF9LRVkgcGFyYW1ldGVycyBpbiB0aGUgc2FtZSBvcmRlciBhcw0KICAgICAgICAgICAgICAg ICAgICAgdGhlIEhJVHMgd2l0aCBzb3J0KEhJVC1JIHwgSElULVIpKQ0KDQpTZWVtcyBjbGVhciB0 aGF0IElLTW0gaXMgZm9yIHRoZSBNYXN0ZXIgS2V5IFNBIGFuZCBJS01wIGlzIGZvciB0aGUgUGFp ci13aXNlIEtleSBTQS4NCg0KRVZZMj4gU3VnZ2VzdCB0byBhZGQgYSBwb2ludGVyIHRvIHNlY3Rp b24gMi4zIChkZWZpbml0aW9ucykgYW5kIHBvc3NpYmx5IGNyZWF0ZSBlbnRyaWVzIGZvciB0aGUg bWFzdGVyIGtleSBTQSBhbmQgcGFpci13aXNlIGtleSBTQSAocGVyaGFwcyBhIGxpdHRsZSBleHRy ZW1lIHRob3VnaCkNCg0KDQoNCg0KDQoyLiAgICAgICBSb21hbiAiZGlzY3Vzcy1kaXNjdXNzIiAo cmVhZCB0aGlzIGFzIHJlcXVlc3QgZm9yIHJlcGx5IGFuZCBub24tYmxvY2tpbmcpIGFib3V0ICIg ZnVydGhlciBpbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlIHByb3ZpZGVzIGJldHRlciBndWlkYW5j ZSIgaW4gc2VjdGlvbnMgNiBhbmQgOS4NCg0KMS4gICAgICAgRVZZPiB0aGlzIHJlYWxseSBwbGVh ZHMgZm9yIGV4cGVyaW1lbnRhbCBzdGF0dXMNCg0KVGhlIG9ubHkgcGxhY2UgdGhpcyB0ZXh0IGV4 aXN0cyBhbnltb3JlIGlzIGluIEFwcGVuZGl4IEM6ICBpRVNHIENvbnNpZGVyYXRpb25zDQoNClBl cmhhcHMgSSBzaG91bGQgZGVsZXRlIGl0IGZyb20gdGhlcmUuDQoNCkVWWTI+IHlvdSBjYW4ga2Vl cCBpdCB0aGUgYXBwZW5kaXgsIEkgZ3Vlc3MgdGhpcyBmaXhlcyBSb21hbuKAmXMg4oCcZGlzY3Vz cy1kaXNjdXNz4oCdDQoNCjIuDQoNCjMuICAgICAgIEJlbmphbWluIG9uIEZPTEQgY29sbGlzaW9u cw0KDQoxLiAgICAgICBFVlk+IElNSE8gYWRkcmVzc2VkIGluIHRoZSBuZXcgc2VjdGlvbiAzLjIu MQ0KDQpJIGJlbGlldmUgSSBoYXZlIHRoaXMgY292ZXJlZC4gIFdlIGhhdmUgdGhlIFB5dGhvbiBz Y3JpcHRzIGZvciB0ZXN0cywgYnV0IHRoaXMgaXMgYSBsb3Qgb2YgY29kZSB0byBwdXQgaW50byB0 aGUgZG9jdW1lbnQuICBSaWdodCBub3cgaXQgaXMgcHJpdmF0ZWx5IGhlbGQgYnkgQWRhbSBhbmQg SS4gIElmIGNhbGxlZCBvbiwgd2UgY2FuIGZpbmQgc29tZSBwZXJtYW5lbnQgaG9tZSBmb3IgaXQu DQoNCg0KDQoyLg0KDQo0LiAgICAgICBCZW5qYW1pbiBvbiBBQ0wgdG8gY291bnRlciBGT0xEIGNv bGxpc2lvbnMgaW4gc2VjdGlvbiAzLjIuMQ0KDQoxLiAgICAgICBFVlk+IHN0aWxsIGxpZ2h0IG9u IHRoZSBBQ0wgYnV0IHRoZSBhYm92ZSBzaG91bGQgY2xlYXIgaXQNCg0KU2VjIDcuMSBpcyByZWZl cmVuY2VkLg0KDQoNCg0KMi4NCg0KNS4gICAgICAgQmVuamFtaW4gImhvdyBpcyBpdCBrbm93biB0 aGF0IHRoZSBwZWVyIHNob3VsZCBiZSB1c2luZyBERVggdnMuIEJFWCINCg0KMS4gICAgICAgRVZZ PiBwYXJ0aWFsbHkgYWRkcmVzc2VkIGluIHNlY3Rpb24gMS4yIGJ1dCBzaG91bGQgYmUgcmVwZWF0 ZWQgaW4gdGhlIHNlY3VyaXR5IHNlY3Rpb24NCg0KSSBjYW4gY3JlYXRlIGEgc2VjIDkuMSAocHVz aGluZyBkb3duIHRoZSBjdXJyZW50IDkuMSk6DQoNCjkuMSBDYXV0aW9uIG9uIHVzaW5nIEhJUCBE RVggcmF0aGVyIHRoYW4gSElQIEJFWA0KDQogICBEdWUgdG8gdGhlIHN1YnN0YW50aWFsbHkgcmVk dWNlZCBzZWN1cml0eSBndWFyYW50ZWVzIG9mIEhJUCBERVgNCiAgIGNvbXBhcmVkIHRvIEhJUCBC RVgsIEhJUCBERVggTVVTVCBvbmx5IGJlIHVzZWQgd2hlbiBhdCBsZWFzdCBvbmUgb2YNCiAgIHRo ZSB0d28gZW5kcG9pbnRzIGlzIGEgY2xhc3MgMCBvciAxIGNvbnN0cmFpbmVkIGRldmljZSBkZWZp bmVkIGluDQogICBTZWN0aW9uIDMgb2YgW1JGQzcyMjhdKS4gIEhJUCBERVggTVVTVCBOT1QgYmUg dXNlZCB3aGVuIGJvdGgNCiAgIGVuZHBvaW50cyBhcmUgY2xhc3MgMiBkZXZpY2VzIG9yIHVuY29u c3RyYWluZWQuDQoNCg0KV2lsbCB0aGlzIHdvcms/DQoNCkVWWTI+ICBpdCB3b3JrcyBmb3IgbWUg YW5kIGhvcGVmdWxseSBmb3IgQmVuIGFzIHdlbGwNCg0KMi4NCg0KNi4gICAgICAgQmVuamFtaW4g bGFjayBvZiBkaXNjdXNzaW9uIG9uIHRoZSBzZWN1cml0eSBjb25zZXF1ZW5jZXMgb2YgaW5hZHZl cnRlbnQgY291bnRlciByZXVzZSBpbiBBRVMtQ1RSDQoNClNlZSBzZWMgOS4xDQoNCkVWWTI+IElu ZGVlZCwgQmVu4oCZcyBiYWxsb3QgaXMgZGF0ZWQgTWFyY2ggMjAyMCBvbiB0aGUgcmV2aXNpb24g LTEzLiBJdCBzZWVtcyB0byBiZSBmaXhlZCB0byBtZSBpbiB0aGUgbGF0ZXN0IHJldmlzaW9ucy4N Cg0KDQo3Lg0KDQo4LiAgICAgICBCZW5qYW1pbiAicHJlc2VuY2Ugb2YgYSBDU1BSTkcgaW4gb3Jk ZXIgdG8gb2J0YWluIHNlY3VyZSBzZXNzaW9uIGtleXMiDQoNCjkuICBTZWN1cml0eSBDb25zaWRl cmF0aW9ucw0KDQouLi4uDQoNCiAgICogIFRoZSBzdHJlbmd0aCBvZiB0aGUga2V5cyBmb3IgYm90 aCB0aGUgTWFzdGVyIGFuZCBQYWlyLXdpc2UgS2V5IFNBcw0KICAgICAgaXMgYmFzZWQgb24gdGhl IHF1YWxpdHkgb2YgdGhlIHJhbmRvbSBrZXlpbmcgbWF0ZXJpYWwgZ2VuZXJhdGVkIGJ5DQogICAg ICB0aGUgSW5pdGlhdG9yIGFuZCB0aGUgUmVzcG9uZGVyLiAgQXMgZWl0aGVyIHBlZXIgbWF5IGJl IGEgc2Vuc29yDQogICAgICBvciBhbiBhY3R1YXRvciBkZXZpY2UsIHRoZXJlIGlzIGEgbmF0dXJh bCBjb25jZXJuIGFib3V0IHRoZQ0KICAgICAgcXVhbGl0eSBvZiBpdHMgcmFuZG9tIG51bWJlciBn ZW5lcmF0b3IuICBUaHVzIGF0IGxlYXN0IGEgQ1NQUk5HDQogICAgICBTSE9VTEQgYmUgdXNlZC4N Cg0KDQpFVlkyPiBpbmRlZWQsIEkgc2hvdWxkIGhhdmUgZGV0ZWN0ZWQgdGhhdCBCZW4gd2FzIG5v dCB1c2luZyB0aGUgLTIxIGJ1dCB0aGUgLTEzIPCfmIkgTm93LCBwbGVhc2UgZXhwYW5kIENTUFJO RyBhdCBmaXJzdCB1c2UuDQoNCg0KOS4NCg0KMTAuICAgQmVuamFtaW4gInVzYWdlIG9mIENNQUMg aW5zdGVhZCBvZiBITUFDIiBhYm91dCBLRVlNQVQgYWxnb3JpdGhtDQoNCjEuICAgICAgIEVWWT4g bmV3IHJlZmVyZW5jZSB0byBOSVNUIHBhcGVycyBzZWVtcyB0byBhZGRyZXNzIHRoaXMgY29uY2Vy bg0KDQpCZW4gZGlkIGFncmVlIGluIGFuIGVtYWlsIHRoYXQgdGhlIFNQODAwLTU2QyBhbmQgMTA4 IGFkZHJlc3NlZCB0aGUgY29uY2Vybi4gIEkgZGlkIG5vdCBuZWVkIHRvIGdvIGZ1cnRoZXIuDQoN Cg0KRVZZMj4gaWYgQmVuIHdhcyBoYXBweSwgdGhlbiBJIGFtIGhhcHB5LiBUaGFuayB5b3UgZm9y IHRoZSBpbmZvcm1hdGlvbi4NCg0KDQoyLg0KDQoxMS4gICBFa3LigJlzIG9uZSBhYm91dCB3aHkg Zm9yZmVpdGluZyBGUyB3aGVuIHNvbWUgYWxnb3JpdGhtIGNvdWxkIGRvIGl0IGluIGEgcmVhc29u YWJsZSB0aW1lLiBJbiBhbiBlbWFpbCB0byBhdXRob3JzIGFuZCBBRHMsIEVyaWMgUi4gd3JvdGUg 4oCcaXQgZGVmaW5lcyBhIHNldCBvZiBwYXJhbWV0ZXJzICh0aGUgTklTVCBjdXJ2ZXMpIHdoaWNo IGFyZSBzbG93ZXIgdy9vIEZTIHRoYW4gb3RoZXIgcGFyYW1ldGVycyAoWDI1NTE5KSBhcmUgdy8g RlMuIFRoaXMgZmFjdCBjYWxscyBpbnRvIHF1ZXN0aW9uIHRoZSBuZWVkIHRvIGRpc3BlbnNlIHdp dGggRlMu4oCdDQoNCjEuICAgICAgIEVWWT4gdGhlIGFkZGl0aW9uYWwgc2VjdGlvbiAxLjIuMSBh bmQgdGhlIHJlZmVyZW5jZSB0byBhIHBheXdhbGwgRWZmaWNpZW50RUNDIHJlZmVyZW5jZSBkbyBu b3Qgb2ZmZXIgYSBjb25jbHVzaXZlIG1vdGl2YXRpb24gZm9yIGFuIElFVEYgc3RhbmRhcmRzIHcv byBGUy4NCg0KUGF5d2FsbD8gIEhtbS4gIEkgZ290IGl0IGZyZWUuICBJIHdpbGwgaGF2ZSB0byBj aGVjayBpbnRvIHRoaXMuICBJdCBtYXkgYmUgdG8gc29tZSBjb29raWUgSSBoYXZlIG9uIHRoaXMg c3lzdGVtLiAgT3IgdGhlIERPSSBoYXMgdGhlIHdyb25nIFVSTC4NCg0KQWgsIHRoYXQgVVJMIHdv cmtzIGZvciBtZSBiZWNhdXNlIEkgYW0gYW4gSUFDUiBtZW1iZXIuICBGb3IgYWxsIGVsc2U6DQoN Cmh0dHBzOi8vbGluay5zcHJpbmdlci5jb20vYXJ0aWNsZS8xMC4xMDA3L3MxMDYyMy0wMTUtMDA4 Ny0xDQoNClNvIEkgd2lsbCBjaGFuZ2UgdGhlIHJlZmVyZW5jZS4gIEJ1dCBwbGVhc2UgY2hlY2sg dGhpcyBvdXQuICBJIHRyaWVkIGl0IG9uIGFub3RoZXIgbWFjaGluZSB0aGF0IHNob3VsZCBub3Qg aGF2ZSBteSBJQUNSIGNvb2tpZXMsIGJ1dC4uLg0KDQoNCg0KDQoNCjIuDQoNCg0KDQoqKipCb3R0 b20gbGluZSwgdGhlIGRvY3VtZW50IGlzIG5vdCB5ZXQgcmVhZHkgdG8gYmUgYXBwcm92ZWQuKioq IChldmVuIGlmIGJpZyBwcm9ncmVzcyBoYXMgYmVlbiBtYWRlKQ0KDQoNCg0KQXMgd3JpdHRlbiBp biBOb3ZlbWJlciAoc2VlIGJlbG93KSwgdGhlIHNpdHVhdGlvbiBoYXMgbGluZ2VyZWQgZm9yIHRv byBsb25nIGFuZCBpcyBibG9ja2luZyB0aGUgSElQLU5BVCBhbmQgcmZjNDQyMy1iaXMgZG9jdW1l bnRzLg0KDQoNCg0KKioqIFRoZXJlZm9yZSwgSSByZXF1ZXN0IHRoZSBhdXRob3JzIGZvciBhIHJl dmlzZWQgSS1EIGFkZHJlc3NpbmcgdGhlIGFib3ZlIChhbmQgbm90aW5nIGFnYWluIHRoYXQgYSBj aGFuZ2UgdG8g4oCYZXhwZXJpbWVudGFs4oCZIOKAkyBhcyB0aGVyZSBhcmUgbm8gZGVwbG95ZWQg aW1wbGVtZW50YXRpb25zIOKAkyBjb3VsZCBwcm9iYWJseSBmaXggYWxsIG9mIHRoZW0pIGJlZm9y ZSBUaHVyc2RheSAyMXN0IG9mIEphbnVhcnkgbWlkbmlnaHQgVVRDIGVsc2UgSSB3aWxsIGFzayB0 aGUgSElQU0VDIFdHIHRvIGFncmVlIHJlbW92aW5nIHRoZSBISVAtREVYIHNlY3Rpb24gZnJvbSB0 aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50LiAqKioNCg0KRG9lcyB0aGUgYWJvdmUgYWRkcmVzcyB0 aGUgb3BlbiBpdGVtcz8NCg0KDQoNCg0KDQpBbGwgaW4gYWxsLCB0aGVyZSBoYXZlIGJlZW4gYSBj b3VwbGUgb2Ygc2lnbmlmaWNhbnQgY2hhbmdlcyAoSV9OT05DRSwgc29tZSBkZWxldGVkIGNpcGhl cnMpIHNpbmNlIHRoZSBJRVRGIGxhc3QgY2FsbCAoc2VlIGh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLWhpcC1kZXgtMjMmdXJsMT1kcmFmdC1pZXRmLWhpcC1kZXgt MjEgKSwgc28sIGFub3RoZXIgSUVURiBMYXN0IENhbGwgaXMgcmVxdWlyZWQgYnV0IHNob3VsZCBu b3QgYmUgYSByZWFsIHByb2JsZW0uDQoNCg0KDQoNCg0KLcOpcmljDQoNCg0KDQoNCg0KDQoNCkZy b206IFJvYmVydCBNb3Nrb3dpdHogPHJnbUBsYWJzLmh0dC1jb25zdWx0LmNvbT48bWFpbHRvOnJn bUBsYWJzLmh0dC1jb25zdWx0LmNvbT4NCg0KRGF0ZTogVGh1cnNkYXksIDE0IEphbnVhcnkgMjAy MSBhdCAxNjowOA0KDQpUbzogRXJpYyBWeW5ja2UgPGV2eW5ja2VAY2lzY28uY29tPjxtYWlsdG86 ZXZ5bmNrZUBjaXNjby5jb20+LCAiRXJpYyBWeW5ja2UgKGV2eW5ja2UpIiA8ZXZ5bmNrZT00MGNp c2NvLmNvbUBkbWFyYy5pZXRmLm9yZz48bWFpbHRvOmV2eW5ja2U9NDBjaXNjby5jb21AZG1hcmMu aWV0Zi5vcmc+LCAiaGlwc2VjQGlldGYub3JnIjxtYWlsdG86aGlwc2VjQGlldGYub3JnPiA8aGlw c2VjQGlldGYub3JnPjxtYWlsdG86aGlwc2VjQGlldGYub3JnPiwgImRyYWZ0LWlldGYtaGlwLWRl eEBpZXRmLm9yZyI8bWFpbHRvOmRyYWZ0LWlldGYtaGlwLWRleEBpZXRmLm9yZz4gPGRyYWZ0LWll dGYtaGlwLWRleEBpZXRmLm9yZz48bWFpbHRvOmRyYWZ0LWlldGYtaGlwLWRleEBpZXRmLm9yZz4s IE1paWthIEtvbXUgPG1paWthLmtvbXVAZXJpY3Nzb24uY29tPjxtYWlsdG86bWlpa2Eua29tdUBl cmljc3Nvbi5jb20+DQoNCkNjOiBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+PG1haWx0bzpy ZGRAY2VydC5vcmc+LCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+PG1haWx0bzpla3JAcnRm bS5jb20+LCBHb256YWxvIENhbWFyaWxsbyA8Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29t PjxtYWlsdG86Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tPiwgInJlbmUuaHVtbWVuQGJl bGRlbi5jb20iPG1haWx0bzpyZW5lLmh1bW1lbkBiZWxkZW4uY29tPiA8cmVuZS5odW1tZW5AYmVs ZGVuLmNvbT48bWFpbHRvOnJlbmUuaHVtbWVuQGJlbGRlbi5jb20+LCBCZW5qYW1pbiBLYWR1ayA8 a2FkdWtAbWl0LmVkdT48bWFpbHRvOmthZHVrQG1pdC5lZHU+LCBFcmlrIEtsaW5lIDxlay5pZXRm QGdtYWlsLmNvbT48bWFpbHRvOmVrLmlldGZAZ21haWwuY29tPg0KDQpTdWJqZWN0OiBSZTogW0hp cHNlY10gTmVlZCB0byBjbG9zZSBhbGwgZHJhZnQtaWV0Zi1oaXAtZGV4LTIxIHBlbmRpbmcgaXNz dWVzLi4uIGJlZm9yZSAyMDIxLUphbi0xMy4uLg0KDQoNCg0KSSBoYWQgaG9wZWQgdG8gZ2V0IC0y MyBvdXQgZW5kIG9mIGxhc3Qgd2VlaywgYW5kIG1pc3NlZCBteSBjdXRvZmYuICBJIGFtIG5vdyBp biBJQUNSJ3MgUmVhbCBXb3JsZCBDcnlwdG8sIHdoZXJlIEkgaGF2ZSBnb3R0ZW4gYSBjb3VwbGUg cG9pbnRlcnMgZm9yIERSSVAgd29yay4NCg0KDQoNCkkgd2FzIHdhaXRpbmcgZm9yIHR3byBhbmFs eXplcyB0aGF0IEkgZ290IEphbiA0LCBhbmQgaW5jb3Jwb3JhdGluZyB0aGVtIGluLiAgSSBiZWxp ZXZlIHRoZXNlIFNIT1VMRCBhZGRyZXNzIG11Y2ggb2YgRUtSJ3MgcXVlc3Rpb25zLg0KDQoNCg0K SSB3aWxsIGhhdmUgYSBydW4gb2YgMU0gREVYIHJhbmRvbSBISXMgdG8gSElUcyBnZW5lcmF0ZWQg d2l0aCBubyBkdXBsaWNhdGVzIHRoYXQgSSBhZGQgaW4gYW4gQXBwZW5kaXggYWxvbmcgd2l0aCB0 aGUgUHl0aG9uIGNvZGUuDQoNCg0KDQpJIGFtIGFkZGluZyBhIEJFWC9ERVggY3J5cHRvIGNvc3Qg aW50byAxLjIsIHByb2JhYmx5IDEuMi4xOg0KDQoNCg0KRm9yIGFuIEluaXRpYXRvciwgQkVYIGlz Og0KDQoNCg0KMiBQSyBzaWcgdmFyaWZpY2F0aW9ucy4NCg0KMSBQSyBzaWcgZ2VuZXJhdGlvbi4N Cg0KMSBESCBrZXlwYWlyIGdlbmVyYXRpb24uDQoNCjEgREggc2VjcmV0IGRlcml2YXRpb24uDQoN Cg0KDQpERVggaXM6DQoNCg0KDQoxIERIIHNlY3JldCBkZXJpdmF0aW9uLg0KDQoNCg0KSSBoYXZl IGN5Y2xlcyBmb3IgdGhlc2UgYW5kIGEgcGFwZXIgdG8gcmVmZXJlbmNlLCBleGNlcHQgRUNESCBr ZXlwYWlyIGdlbmVyYXRpb24sIG9uIGFuIDggYml0IHByb2Nlc3MgYW5kIHRoZSBudW1iZXJzIGFy ZSBiaWcuICBCdXQgSSB0aGluayB0aGF0IHBhcnQgYmVsb25ncyBpbiBhbiBBcHBlbmRpeC4NCg0K DQoNClNvIHVubGlrZWx5IEZyaWRheS4gIEJ1dCBlYXJseSB0aGUgZm9sbG93aW5nIHdlZWsuDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KT24gMS8xMi8yMSA2OjE5IEFNLCBFcmljIFZ5bmNrZSAoZXZ5 bmNrZSkgd3JvdGU6DQoNClR3byBtb250aHMgYWZ0ZXIgdGhlIGVtYWlsIGJlbG93LCBJIHNlbmRp bmcgYSBraW5kIHJlbWluZGVyIHRvIGF1dGhvcnMgYW5kIFdHLg0KDQoNCg0KV2l0aCB0aGUgLTIy LCBhIGxvdCBvZiAoaWYgbm90IGFsbCApIFNFQyBBRHPigJkgRElTQ1VTUyBwb2ludHMgc2hvdWxk IGhhdmUgYmVlbiBhZGRyZXNzZWQuDQoNCg0KDQpBcyBmYXIgYXMgSSBjYW4gdGVsbCwgdGhlIG90 aGVyIHJlbWFpbmluZyBpc3N1ZSB3YXMgRWty4oCZcyBvbmUgYWJvdXQgd2h5IGZvcmZlaXRpbmcg RlMgd2hlbiBzb21lIGFsZ29yaXRobSBjb3VsZCBkbyBpdCBpbiBhIHJlYXNvbmFibGUgdGltZS4g SW4gYW4gZW1haWwgdG8gYXV0aG9ycyBhbmQgQURzLCBFcmljIFIuIHdyb3RlIOKAnGl0IGRlZmlu ZXMgYSBzZXQgb2YgcGFyYW1ldGVycyAodGhlIE5JU1QgY3VydmVzKSB3aGljaCBhcmUgc2xvd2Vy IHcvbyBGUyB0aGFuIG90aGVyIHBhcmFtZXRlcnMgKFgyNTUxOSkgYXJlIHcvIEZTLiBUaGlzIGZh Y3QgY2FsbHMgaW50byBxdWVzdGlvbiB0aGUgbmVlZCB0byBkaXNwZW5zZSB3aXRoIEZTLuKAnQ0K DQoNCg0KV2hpbGUgMiBtb250aHMgYWdvIEkgcHV0IGEgZGVhZGxpbmUgZm9yIHRvbW9ycm93LCBJ IChhcyB0aGUgcmVzcG9uc2libGUgQUQpIGFtIGZsZXhpYmxlIG9mIGNvdXJzZSBidXQgd2UgY2Fu bm90IGxpbmdlciBhbnltb3JlLiBJIGtub3cgdGhhdCBhIC0yMyBpcyBpbiB0aGUgd29yayBmb3Ig d2Vla3MgPT4gbGV04oCZcyBwdWJsaXNoIGl0IGluIHRoZSBjb21pbmcgZGF5cy4NCg0KDQoNCkVs c2UsIG5leHQgd2VlayB3ZSB3aWxsIG5lZWQgdG8gZWl0aGVyIGNoYW5nZSB0aGUgaW50ZW5kZWQg c3RhdHVzIHRvIGV4cGVyaW1lbnRhbCBvciBkZWNsYXJlIHRoZSBkb2N1bWVudCBkZWFkIGJ5IGxh Y2sgb2YgZW5lcmd5LiBUaGUgbGF0dGVyIGRvZXMgbm90IGhhdmUgbXkgcHJlZmVyZW5jZSBvYnZp b3VzbHkuDQoNCg0KDQpSZWdhcmRzDQoNCg0KDQotw6lyaWMNCg0KDQoNCg0KDQpGcm9tOiBIaXBz ZWMgbWFpbHRvOmhpcHNlYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiAiRXJpYyBWeW5j a2UgKGV2eW5ja2UpIiBtYWlsdG86ZXZ5bmNrZT00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZw0K DQpEYXRlOiBGcmlkYXksIDEzIE5vdmVtYmVyIDIwMjAgYXQgMTU6MzINCg0KVG86IG1haWx0bzpo aXBzZWNAaWV0Zi5vcmcgbWFpbHRvOmhpcHNlY0BpZXRmLm9yZywgbWFpbHRvOmRyYWZ0LWlldGYt aGlwLWRleEBpZXRmLm9yZyBtYWlsdG86ZHJhZnQtaWV0Zi1oaXAtZGV4QGlldGYub3JnLCBSb2Jl cnQgTW9za293aXR6IG1haWx0bzpyZ21AbGFicy5odHQtY29uc3VsdC5jb20sIE1paWthIEtvbXUg bWFpbHRvOm1paWthLmtvbXVAZXJpY3Nzb24uY29tDQoNCkNjOiBSb21hbiBEYW55bGl3IG1haWx0 bzpyZGRAY2VydC5vcmcsIEVyaWMgUmVzY29ybGEgbWFpbHRvOmVrckBydGZtLmNvbSwgR29uemFs byBDYW1hcmlsbG8gbWFpbHRvOmdvbnphbG8uY2FtYXJpbGxvQGVyaWNzc29uLmNvbSwgbWFpbHRv OnJlbmUuaHVtbWVuQGJlbGRlbi5jb20gbWFpbHRvOnJlbmUuaHVtbWVuQGJlbGRlbi5jb20sIEJl bmphbWluIEthZHVrIG1haWx0bzprYWR1a0BtaXQuZWR1LCBFcmlrIEtsaW5lIG1haWx0bzplay5p ZXRmQGdtYWlsLmNvbQ0KDQpTdWJqZWN0OiBbSGlwc2VjXSBOZWVkIHRvIGNsb3NlIGFsbCBkcmFm dC1pZXRmLWhpcC1kZXgtMjEgcGVuZGluZyBpc3N1ZXMuLi4gYmVmb3JlIDIwMjEtSmFuLTEzLi4u DQoNCg0KDQpEZWFyIEhJUCwgZGVhciBhdXRob3JzLA0KDQoNCg0KVGhpcyBkb2N1bWVudCB3YXMg cmVxdWVzdGVkIGZvciBwdWJsaWNhdGlvbiBbMV0gaW4gRmVicnVhcnkgMjAxOCAoMi41IHllYXJz IGFnbyksIHRoZW4gaXRzIElFU0cgZXZhbHVhdGlvbiBoYXMgYmVlbiBkZWZlcnJlZCwgdGhlbiBJ IHRvb2sgb3ZlciB0aGlzIGRvY3VtZW50IGZyb20gVGVycnkgTWFuZGVyc29uIGluIE1hcmNoIDIw MTksIHRoZW4gaXQgd2VudCBhZ2FpbiB0aHJvdWdoIElFU0cgZXZhbHVhdGlvbiBpbiBKdWx5IDIw MjAgYW5kIHRoZXJlIGFyZSBzdGlsbCBESVNDVVNTIHBvaW50cyB0byBiZSBhZGRyZXNzZWQgZXZl biBhZnRlciBhIGNvdXBsZSBvZiByZXZpc2VkIEktRC4uLg0KDQoNCg0KRGlmZmljdWx0IG5vdCB0 byBvYnNlcnZlIHRoYXQgdGhpcyBkb2N1bWVudCBkb2VzIG5vdCBwcm9ncmVzcyB2ZXJ5IGZhc3Qu DQoNCg0KDQpNb3Jlb3ZlciwgdGhpcyBkb2N1bWVudCBpcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2Ug Zm9yIHJmYzQ0MjMtYmlzIHdhaXRpbmcgaW4gdGhlIFJGQyBlZGl0b3IgcXVldWUgc2luY2UgTWFy Y2ggMjAxOS4uLiBTbywgYWxzbyBibG9ja2luZyB0aGUgSElQLU5BVCBkb2N1bWVudCBbMl0uDQoN Cg0KDQpBZnRlciBkaXNjdXNzaW9uIHdpdGggdGhlIEhJUCBjaGFpciwgR29uemFsbyBpbiBjYywg d2UgaGF2ZSB0YWtlbiB0aGUgZm9sbG93aW5nIGRlY2lzaW9uOiBpZiBhIHJldmlzZWQgSS1EIGFk ZHJlc3NpbmcgcmVtYWluaW5nIERJU0NVU1MgcG9pbnRzICsgRWty4oCZcyBvbmVzIGlzIG5vdCB1 cGxvYWRlZCB3aXRoaW4gMiBtb250aHMgKDEzdGggb2YgSmFudWFyeSAyMDIxKSwgdGhlbiBJIHdp bGwgcmVxdWVzdCB0aGUgSElQIFdHIHRvIGFjY2VwdCB0aGUgY29tcGxldGUgcmVtb3ZhbCBvZiBz ZWN0aW9uIEEuMy4zIG9mIHRoZSByZmM0NDIzLWJpcyBkb2N1bWVudCAoMSBwYWdlIGFib3V0IEhJ UC1ERVggaW4gdGhlIGFwcGVuZGl4KSArIHRoZSByZWZlcmVuY2UgdG8gdGhlIEhJUC1ERVggZG9j dW1lbnQgWzNdLiBUaGlzIHdpbGwgYWxsb3cgdGhlIGltbWVkaWF0ZSBwdWJsaWNhdGlvbiBvZiB0 aGUgcmZjNDQyMy1iaXMgYW5kIEhJUC1OQVQgZG9jdW1lbnRzLg0KDQoNCg0KVGhlIEhJUCBERVgg YXV0aG9ycyBtYXkgYWxzbyBzZWxlY3QgdG8gY2hhbmdlIHRoZSBpbnRlbmRlZCBzdGF0dXMgb2Yg dGhlIGRvY3VtZW50IHRvIOKAmGV4cGVyaW1lbnRhbOKAmSAoaWYgdGhlIEhJUCBXRyBhZ3JlZXMp IGFzIHRoaXMgbWF5IHJlZHVjZSB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGJ5IHRoZSBTRUMg QUQgYW5kIEVrci4NCg0KDQoNCkdvbnphbG8gYW5kIEkgYXJlIHN0aWxsIGhvcGluZyB0byBnZXQg YSByZXZpc2VkIEhJUC1ERVggc2hvcnRseSwNCg0KDQoNClJlZ2FyZHMNCg0KDQoNCi3DqXJpYw0K DQoNCg0KWzFdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaGlw LWRleC9oaXN0b3J5Lw0KDQpbMl0gaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvY2x1c3Rlcl9p bmZvLnBocD9jaWQ9QzM4Ng0KDQpbM10gYW5kIHBvc3NpYmx5IEkgd2lsbCBzZXQgdGhlIHN0YXRl IG9mIEhJUC1ERVggYXMg4oCYZGVhZOKAmSBvbiB0aGUgZGF0YXRyYWNrZXINCg0KDQoNCg0KDQot LQ0KDQpSb2JlcnQgTW9za293aXR6DQoNCk93bmVyDQoNCkhUVCBDb25zdWx0aW5nDQoNCkM6ICAg ICAgMjQ4LTIxOS0yMDU5DQoNCkY6ICAgICAgMjQ4LTk2OC0yODI0DQoNCkU6ICAgICAgbWFpbHRv OnJnbUBsYWJzLmh0dC1jb25zdWx0LmNvbQ0KDQoNCg0KVGhlcmUncyBubyBsaW1pdCB0byB3aGF0 IGNhbiBiZSBhY2NvbXBsaXNoZWQgaWYgaXQgZG9lc24ndCBtYXR0ZXIgd2hvIGdldHMgdGhlIGNy ZWRpdA0KDQoNCg== --_000_0651C53661F44B95A187EC8F7BFD058Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8dGl0bGU+U3RhbmRhcmQ8L3RpdGxlPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQg RGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBh bm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi Q2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29Q bGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFp biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xp c3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eToz NDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206 MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww DQoJe21zby1saXN0LWlkOjc3Mjc1MTI3MTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTgyNDY5 NzM0ODt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDps ZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJ e21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1z dG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDoyNTIu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDEN Cgl7bXNvLWxpc3QtaWQ6OTk5NDk5MjUzOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczo1Nzg3MTY1MzYgLTk0MzgzMDA5NiA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpA bGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MGNtO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJlbi1CRSIgbGluaz0i IzA1NjNDMSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+Qm9iLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmsgeW91IGZvciB5b3VyIHJlcGx5 LiBJIHRvb2sgc29tZSB0aW1lIHRvIHJldmlldyB0aGUgcG9pbnRzLiBMb29rIGZvciBFVlkyJmd0 OyBiZWxvdyBidXQgYXQgZmlyc3Qgc2lnaHQsIHRoaXMgbG9va3MgcmVhbGx5IGdvb2QgdG8gbWUg bm93LiBPZiBjb3Vyc2UsIFJvbWFuIGFuZCBCZW4gd2lsbCBoYXZlIGEgZmluYWwgc2F5LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+QWJvdXQgRWty4oCZcyBjb21tZW50LCBJIGFtIHJlYWRpbmcgeW91ciBs YXRlc3QgZW1haWwgc2VudCBtaW51dGVzIGFnbywgYW5kIEkgYW0gc3RpbGwgdW5jbGVhciB3aGVy ZSwgaW4gdGhlIHRleHQsIGl0IGlzIHNob3duIHRoYXQgRlMgaXMgbm90IGFjaGlldmFibGUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5BY3Rpb24gcGxhbjogcGxlYXNlIGFwcGx5IHRoZSBjaGFuZ2VzIHlv dSBoYXZlIHByb3Bvc2VkIGJlbG93LCBwb3N0IGEgcmV2aXNlZCBJLUQsIHRoZW4gb24gbXkgc2lk ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiB0eXBl PSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjBjbTttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PHNwYW4gbGFuZz0iRU4tVVMiPkxhdW5jaGlu ZyBhbiBJRVRGIExhc3QgQ2FsbCBmb3IgMiB3ZWVrcyAoYXMgd3JpdHRlbiBiZWxvdyBzb21lIGlt cG9ydGFudCBjaGFuZ2VzIGhhdmUgYmVlbiBtYWRlIGJ1dCBJIGV4cGVjdCB0aGUgTEMgZXZlbnRs ZXNzKTxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48c3BhbiBsYW5n PSJFTi1VUyI+UHJvYmluZyBCZW4gJmFtcDsgUm9tYW4gdG8gcmV2aWV3IHdoZXRoZXIgdGhlaXIg RElTQ1VTUyBzdGlsbCBob2xkPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLCBpdCBz ZWVtcyB0aGF0IHRoZSBjb25jbHVzaW9uIGlzIG5lYXIgOy0pPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4t w6lyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Um9iZXJ0IE1vc2tvd2l0eiAmbHQ7cmdtQGh0dC1j b25zdWx0LmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCAxOCBKYW51YXJ5IDIwMjEg YXQgMTc6MDY8YnI+DQo8Yj5UbzogPC9iPkVyaWMgVnluY2tlICZsdDtldnluY2tlQGNpc2NvLmNv bSZndDssIFJvYmVydCBNb3Nrb3dpdHogJmx0O3JnbUBsYWJzLmh0dC1jb25zdWx0LmNvbSZndDss ICZxdW90O2hpcHNlY0BpZXRmLm9yZyZxdW90OyAmbHQ7aGlwc2VjQGlldGYub3JnJmd0OywgJnF1 b3Q7ZHJhZnQtaWV0Zi1oaXAtZGV4QGlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC1pZXRmLWhpcC1k ZXhAaWV0Zi5vcmcmZ3Q7LCBNaWlrYSBLb211ICZsdDttaWlrYS5rb211QGVyaWNzc29uLmNvbSZn dDs8YnI+DQo8Yj5DYzogPC9iPlJvbWFuIERhbnlsaXcgJmx0O3JkZEBjZXJ0Lm9yZyZndDssIEVy aWMgUmVzY29ybGEgJmx0O2VrckBydGZtLmNvbSZndDssIEdvbnphbG8gQ2FtYXJpbGxvICZsdDtn b256YWxvLmNhbWFyaWxsb0Blcmljc3Nvbi5jb20mZ3Q7LCAmcXVvdDtyZW5lLmh1bW1lbkBiZWxk ZW4uY29tJnF1b3Q7ICZsdDtyZW5lLmh1bW1lbkBiZWxkZW4uY29tJmd0OywgQmVuamFtaW4gS2Fk dWsgJmx0O2thZHVrQG1pdC5lZHUmZ3Q7LCBFcmlrIEtsaW5lICZsdDtlay5pZXRmQGdtYWlsLmNv bSZndDssIEFkYW0gV2lldGh1ZWNodGVyICZsdDthZGFtLndpZXRodWVjaHRlckBheGVudGVycHJp emUuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0hpcHNlY10gTmVlZCB0byBjbG9z ZSBhbGwgZHJhZnQtaWV0Zi1oaXAtZGV4LTIxIHBlbmRpbmcgaXNzdWVzLi4uIGJlZm9yZSAyMDIx LUphbi0xMy4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0 OjM2LjBwdCI+DQo8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiAxLzE4LzIxIDk6MTIgQU0sIEVyaWMg VnluY2tlIChldnluY2tlKSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+VEQmbmJzcDs7TFImbmJzcDs6IG1vcmUgd29yayB0byBiZSBkb25lLCBkZWFkbGluZSB0 aGlzIFRodXJzZGF5IDIxc3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Qm9iLCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiPlQ8L3NwYW4+aGFuayB5b3UgZm9yIHRoZSAtMjMgKGFuZCBBZGFtIFcg Zm9yIHRoZSBmb290d29yayk8c3BhbiBsYW5nPSJFTi1VUyI+IGFuZCBJIHVuZGVyc3RhbmQgdGhh dCB5b3UgYXJlIHF1aXRlIGJ1c3kuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5I ZXJlIGlzIHRoZSBsaW5rIHRvIHRoZSBkaWZmIGJldHdlZW4gLTIxIGFuZCAtMjM6DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1oaXAtZGV4LTIz JmFtcDt1cmwxPWRyYWZ0LWlldGYtaGlwLWRleC0yMSI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1oaXAtZGV4LTIzJmFtcDt1cmwxPWRyYWZ0LWlldGYtaGlw LWRleC0yMTwvYT4NCjxzcGFuIGxhbmc9IkVOLVVTIj4oaS5lLiwgdGhlIG9uZSB1c2VkIGJ5IEp1 bHkgMjAyMCBJRVNHIGV2YWx1YXRpb24gYW5kIHRoZSBsYXRlc3Qgb25lKTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QWZ0ZXIgdGhlIEp1bHkgMjAyMCBJRVNHIGV2YWx1YXRpb24N CjxzcGFuIGxhbmc9IkVOLVVTIj5iYXNlZCA8L3NwYW4+b24gLTxzcGFuIGxhbmc9IkVOLVVTIj4y MTwvc3Bhbj4sIHRoZXJlIHdlcmUgYSBjb3VwbGUgb2YgcG9pbnRzIHRvIGJlIGFkZHJlc3NlZDxz cGFuIGxhbmc9IkVOLVVTIj4gKHdpdGggc29tZSBjb21tZW50cyBvZiBtaW5lIGFzIEVWWSZndDsp PC9zcGFuPjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJt YXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT5Sb21hbjog4oCcU2VjdGlvbiA2LjMuJm5ic3A7IFBlciB0aGUgZGVmaW5pdGlvbiBvZiBJ S00sIHdoZW4gc2hvdWxkIHRoZXNlIHR3byBkaWZmZXJlbnQgZGVyaXZhdGlvbnMgYmUgdXNlZD8N CjxzcGFuIGxhbmc9IkVOLVVTIj4mcXVvdDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7dGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+RVZZJmd0 OyBpbmRlZWQsIElLTW0gYW5kIElLTXAgYXJlIGJvdGggZGVmaW5lZCBidXQgbm90aGluZyBpcyBz YWlkIHdoaWNoIG9uZSB0byB1c2UgaW4gd2hpY2ggY2FzZS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSUtNJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElLTW0gZm9yIE1hc3RlciBLZXkgU0Eg SW5wdXQga2V5aW5nIG1hdGVyaWFsPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IG9yPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IElLTXAgZm9yIFBhaXItd2lzZSBLZXkgU0EgSW5wdXQga2V5aW5nIG1hdGVyaWFsPGJyPg0KPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElLTW0mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgS2lqIHwgSV9OT05DRTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBJS01wJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEtpaiB8 IElfTk9OQ0UgfCAoY29uY2F0ZW5hdGVkIHJhbmRvbSB2YWx1ZXMgb2YgdGhlPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEVOQ1JZUFRFRF9LRVkgcGFyYW1ldGVycyBpbiB0aGUgc2FtZSBvcmRlciBhczxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB0aGUgSElUcyB3aXRoIHNvcnQoSElULUkgfCBISVQtUikpPGJyPg0KPGJyPg0KU2VlbXMgY2xl YXIgdGhhdCBJS01tIGlzIGZvciB0aGUgTWFzdGVyIEtleSBTQSBhbmQgSUtNcCBpcyBmb3IgdGhl IFBhaXItd2lzZSBLZXkgU0EuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5FVlkyJmd0OyBTdWdnZXN0IHRvIGFkZCBhIHBvaW50ZXIgdG8gc2VjdGlvbiAyLjMgKGRl ZmluaXRpb25zKSBhbmQgcG9zc2libHkgY3JlYXRlIGVudHJpZXMgZm9yIHRoZSBtYXN0ZXIga2V5 IFNBIGFuZCBwYWlyLXdpc2Uga2V5IFNBIChwZXJoYXBzIGEgbGl0dGxlIGV4dHJlbWUgdGhvdWdo KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBw dDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9 IkVOLVVTIj5Sb21hbiAmcXVvdDtkaXNjdXNzLWRpc2N1c3MmcXVvdDsgKHJlYWQgdGhpcyBhcyBy ZXF1ZXN0IGZvciByZXBseSBhbmQgbm9uLWJsb2NraW5nKSBhYm91dCAmcXVvdDsgZnVydGhlciBp bXBsZW1lbnRhdGlvbiBleHBlcmllbmNlIHByb3ZpZGVzIGJldHRlciBndWlkYW5jZSZxdW90OyBp biBzZWN0aW9ucyA2IGFuZCA5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiPkVWWSZndDsgdGhpcyBy ZWFsbHkgcGxlYWRzIGZvciBleHBlcmltZW50YWwgc3RhdHVzPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PGJyPg0KVGhlIG9ubHkgcGxhY2UgdGhpcyB0ZXh0IGV4aXN0cyBhbnltb3JlIGlz IGluIEFwcGVuZGl4IEM6Jm5ic3A7IGlFU0cgQ29uc2lkZXJhdGlvbnM8YnI+DQo8YnI+DQpQZXJo YXBzIEkgc2hvdWxkIGRlbGV0ZSBpdCBmcm9tIHRoZXJlLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkVWWTImZ3Q7IHlv dSBjYW4ga2VlcCBpdCB0aGUgYXBwZW5kaXgsIEkgZ3Vlc3MgdGhpcyBmaXhlcyBSb21hbuKAmXMg 4oCcZGlzY3Vzcy1kaXNjdXNz4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdDt0ZXh0LWluZGVudDotMTgu MHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5CZW5qYW1p biBvbiBGT0xEIGNvbGxpc2lvbnMgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+RVZZJmd0OyBJTUhP IGFkZHJlc3NlZCBpbiB0aGUgbmV3IHNlY3Rpb24gMy4yLjE8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48YnI+DQpJIGJlbGlldmUgSSBoYXZlIHRoaXMgY292ZXJlZC4mbmJzcDsgV2UgaGF2 ZSB0aGUgUHl0aG9uIHNjcmlwdHMgZm9yIHRlc3RzLCBidXQgdGhpcyBpcyBhIGxvdCBvZiBjb2Rl IHRvIHB1dCBpbnRvIHRoZSBkb2N1bWVudC4mbmJzcDsgUmlnaHQgbm93IGl0IGlzIHByaXZhdGVs eSBoZWxkIGJ5IEFkYW0gYW5kIEkuJm5ic3A7IElmIGNhbGxlZCBvbiwgd2UgY2FuIGZpbmQgc29t ZSBwZXJtYW5lbnQgaG9tZSBmb3IgaXQuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0O3Rl eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0 O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+NC48c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0i RU4tVVMiPkJlbmphbWluIG9uIEFDTCB0byBjb3VudGVyIEZPTEQgY29sbGlzaW9ucyBpbiBzZWN0 aW9uIDMuMi4xPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MCBsZXZlbDIgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+RVZZJmd0OyBzdGlsbCBsaWdodCBvbiB0 aGUgQUNMIGJ1dCB0aGUgYWJvdmUgc2hvdWxkIGNsZWFyIGl0PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PGJyPg0KU2VjIDcuMSBpcyByZWZlcmVuY2VkLjxicj4NCjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MTA4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjUu PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIGxhbmc9IkVOLVVTIj5CZW5qYW1pbiAmcXVvdDtob3cgaXMgaXQga25vd24gdGhhdCB0 aGUgcGVlciBzaG91bGQgYmUgdXNpbmcgREVYIHZzLiBCRVgmcXVvdDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBw dDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9 IkVOLVVTIj5FVlkmZ3Q7IHBhcnRpYWxseSBhZGRyZXNzZWQgaW4gc2VjdGlvbiAxLjIgYnV0IHNo b3VsZCBiZSByZXBlYXRlZCBpbiB0aGUgc2VjdXJpdHkgc2VjdGlvbjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxicj4NCkkgY2FuIGNyZWF0ZSBhIHNlYyA5LjEgKHB1c2hpbmcgZG93biB0 aGUgY3VycmVudCA5LjEpOjxicj4NCjxicj4NCjkuMSBDYXV0aW9uIG9uIHVzaW5nIEhJUCBERVgg cmF0aGVyIHRoYW4gSElQIEJFWDxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyBEdWUgdG8gdGhlIHN1 YnN0YW50aWFsbHkgcmVkdWNlZCBzZWN1cml0eSBndWFyYW50ZWVzIG9mIEhJUCBERVg8YnI+DQom bmJzcDsmbmJzcDsgY29tcGFyZWQgdG8gSElQIEJFWCwgSElQIERFWCBNVVNUIG9ubHkgYmUgdXNl ZCB3aGVuIGF0IGxlYXN0IG9uZSBvZjxicj4NCiZuYnNwOyZuYnNwOyB0aGUgdHdvIGVuZHBvaW50 cyBpcyBhIGNsYXNzIDAgb3IgMSBjb25zdHJhaW5lZCBkZXZpY2UgZGVmaW5lZCBpbjxicj4NCiZu YnNwOyZuYnNwOyBTZWN0aW9uIDMgb2YgW1JGQzcyMjhdKS4mbmJzcDsgSElQIERFWCBNVVNUIE5P VCBiZSB1c2VkIHdoZW4gYm90aDxicj4NCiZuYnNwOyZuYnNwOyBlbmRwb2ludHMgYXJlIGNsYXNz IDIgZGV2aWNlcyBvciB1bmNvbnN0cmFpbmVkLjxicj4NCjxicj4NCjxicj4NCldpbGwgdGhpcyB3 b3JrPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5FVlkyJmd0OyAmbmJzcDtpdCB3b3JrcyBmb3IgbWUgYW5kIGhvcGVm dWxseSBmb3IgQmVuIGFzIHdlbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0O3RleHQtaW5kZW50Oi0xOC4w cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0x OC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Ni48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiPkJlbmphbWlu IGxhY2sgb2YgZGlzY3Vzc2lvbiBvbiB0aGUgc2VjdXJpdHkgY29uc2VxdWVuY2VzIG9mIGluYWR2 ZXJ0ZW50IGNvdW50ZXIgcmV1c2UgaW4gQUVTLUNUUjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxicj4NClNlZSBzZWMgOS4xPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RVZZMiZndDsgSW5kZWVkLCBCZW7igJlz IGJhbGxvdCBpcyBkYXRlZCBNYXJjaCAyMDIwIG9uIHRoZSByZXZpc2lvbiAtMTMuIEl0IHNlZW1z IHRvIGJlIGZpeGVkIHRvIG1lIGluIHRoZSBsYXRlc3QgcmV2aXNpb25zLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJt YXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij43LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZl bDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj44LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+QmVuamFtaW4gJnF1b3Q7cHJlc2VuY2Ugb2YgYSBD U1BSTkcgaW4gb3JkZXIgdG8gb2J0YWluIHNlY3VyZSBzZXNzaW9uIGtleXMmcXVvdDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQo5LiZuYnNwOyBTZWN1cml0eSBDb25zaWRlcmF0 aW9uczxicj4NCjxicj4NCi4uLi48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgKiZuYnNwOyBUaGUg c3RyZW5ndGggb2YgdGhlIGtleXMgZm9yIGJvdGggdGhlIE1hc3RlciBhbmQgUGFpci13aXNlIEtl eSBTQXM8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMgYmFzZWQgb24gdGhl IHF1YWxpdHkgb2YgdGhlIHJhbmRvbSBrZXlpbmcgbWF0ZXJpYWwgZ2VuZXJhdGVkIGJ5PGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBJbml0aWF0b3IgYW5kIHRoZSBSZXNw b25kZXIuJm5ic3A7IEFzIGVpdGhlciBwZWVyIG1heSBiZSBhIHNlbnNvcjxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvciBhbiBhY3R1YXRvciBkZXZpY2UsIHRoZXJlIGlzIGEg bmF0dXJhbCBjb25jZXJuIGFib3V0IHRoZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBxdWFsaXR5IG9mIGl0cyByYW5kb20gbnVtYmVyIGdlbmVyYXRvci4mbmJzcDsgVGh1cyBh dCBsZWFzdCBhIENTUFJORzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTSE9V TEQgYmUgdXNlZC48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RVZZMiZndDsgaW5kZWVkLCBJIHNo b3VsZCBoYXZlIGRldGVjdGVkIHRoYXQgQmVuIHdhcyBub3QgdXNpbmcgdGhlIC0yMSBidXQgdGhl IC0xMw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXBwbGUgQ29sb3IgRW1vamkmcXVvdDsiPiYjMTI4NTIxOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+IE5vdywgcGxlYXNlIGV4cGFuZCBDU1BSTkcgYXQgZmlyc3QgdXNlLjwvc3Bhbj48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PjkuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVs MSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPjEwLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1V UyI+QmVuamFtaW4gJnF1b3Q7dXNhZ2Ugb2YgQ01BQyBpbnN0ZWFkIG9mIEhNQUMmcXVvdDsgYWJv dXQgS0VZTUFUIGFsZ29yaXRobTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiPkVWWSZndDsgbmV3IHJl ZmVyZW5jZSB0byBOSVNUIHBhcGVycyBzZWVtcyB0byBhZGRyZXNzIHRoaXMgY29uY2Vybjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxicj4NCkJlbiBkaWQgYWdyZWUgaW4gYW4gZW1haWwg dGhhdCB0aGUgU1A4MDAtNTZDIGFuZCAxMDggYWRkcmVzc2VkIHRoZSBjb25jZXJuLiZuYnNwOyBJ IGRpZCBub3QgbmVlZCB0byBnbyBmdXJ0aGVyLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5FVlky Jmd0OyBpZiBCZW4gd2FzIGhhcHB5LCB0aGVuIEkgYW0gaGFwcHkuIFRoYW5rIHlvdSBmb3IgdGhl IGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0O3RleHQtaW5kZW50 Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5k ZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MTEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPkVrcuKAmXMgb25lIGFib3V0IHdoeSBmb3JmZWl0aW5nIEZTIHdoZW4gc29t ZSBhbGdvcml0aG0gY291bGQgZG8gaXQgaW4gYSByZWFzb25hYmxlIHRpbWUuIEluIGFuIGVtYWls IHRvIGF1dGhvcnMgYW5kIEFEcywgRXJpYyBSLiB3cm90ZSDigJxpdCBkZWZpbmVzIGEgc2V0IG9m IHBhcmFtZXRlcnMgKHRoZSBOSVNUIGN1cnZlcykgd2hpY2ggYXJlIHNsb3dlciB3L28gRlMgdGhh biBvdGhlciBwYXJhbWV0ZXJzIChYMjU1MTkpDQogYXJlIHcvIEZTLiBUaGlzIGZhY3QgY2FsbHMg aW50byBxdWVzdGlvbiB0aGUgbmVlZCB0byBkaXNwZW5zZSB3aXRoIEZTLuKAnTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7 dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+DQo8IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJF Ti1VUyI+RVZZJmd0OyB0aGUgYWRkaXRpb25hbCBzZWN0aW9uIDEuMi4xIGFuZCB0aGUgcmVmZXJl bmNlIHRvIGEgcGF5d2FsbCBFZmZpY2llbnRFQ0MgcmVmZXJlbmNlIGRvIG5vdCBvZmZlciBhIGNv bmNsdXNpdmUgbW90aXZhdGlvbiBmb3IgYW4gSUVURiBzdGFuZGFyZHMgdy9vIEZTLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxicj4NClBheXdhbGw/Jm5ic3A7IEhtbS4mbmJzcDsgSSBn b3QgaXQgZnJlZS4mbmJzcDsgSSB3aWxsIGhhdmUgdG8gY2hlY2sgaW50byB0aGlzLiZuYnNwOyBJ dCBtYXkgYmUgdG8gc29tZSBjb29raWUgSSBoYXZlIG9uIHRoaXMgc3lzdGVtLiZuYnNwOyBPciB0 aGUgRE9JIGhhcyB0aGUgd3JvbmcgVVJMLjxicj4NCjxicj4NCkFoLCB0aGF0IFVSTCB3b3JrcyBm b3IgbWUgYmVjYXVzZSBJIGFtIGFuIElBQ1IgbWVtYmVyLiZuYnNwOyBGb3IgYWxsIGVsc2U6PGJy Pg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9saW5rLnNwcmluZ2VyLmNvbS9hcnRpY2xlLzEwLjEw MDcvczEwNjIzLTAxNS0wMDg3LTEiPmh0dHBzOi8vbGluay5zcHJpbmdlci5jb20vYXJ0aWNsZS8x MC4xMDA3L3MxMDYyMy0wMTUtMDA4Ny0xPC9hPjxicj4NCjxicj4NClNvIEkgd2lsbCBjaGFuZ2Ug dGhlIHJlZmVyZW5jZS4mbmJzcDsgQnV0IHBsZWFzZSBjaGVjayB0aGlzIG91dC4mbmJzcDsgSSB0 cmllZCBpdCBvbiBhbm90aGVyIG1hY2hpbmUgdGhhdCBzaG91bGQgbm90IGhhdmUgbXkgSUFDUiBj b29raWVzLCBidXQuLi48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7 dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+DQo8IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPioqKkJvdHRvbSBsaW5lLCB0 aGUgZG9jdW1lbnQgaXMgbm90IHlldCByZWFkeSB0byBiZSBhcHByb3ZlZC4qKiogKGV2ZW4gaWYg YmlnIHByb2dyZXNzIGhhcyBiZWVuIG1hZGUpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5BcyB3cml0 dGVuIGluIE5vdmVtYmVyIChzZWUgYmVsb3cpLCB0aGUgc2l0dWF0aW9uIGhhcyBsaW5nZXJlZCBm b3IgdG9vIGxvbmcgYW5kIGlzIGJsb2NraW5nIHRoZSBISVAtTkFUIGFuZCByZmM0NDIzLWJpcyBk b2N1bWVudHMuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPioqKiBUaGVyZWZvcmUsIEkgcmVxdWVz dCB0aGUgYXV0aG9ycyBmb3IgYSByZXZpc2VkIEktRCBhZGRyZXNzaW5nIHRoZSBhYm92ZSAoYW5k IG5vdGluZyBhZ2FpbiB0aGF0IGEgY2hhbmdlIHRvIOKAmGV4cGVyaW1lbnRhbOKAmSDigJMgYXMg dGhlcmUgYXJlIG5vIGRlcGxveWVkIGltcGxlbWVudGF0aW9ucyDigJMgY291bGQgcHJvYmFibHkg Zml4DQogYWxsIG9mIHRoZW0pIGJlZm9yZSBUaHVyc2RheSAyMXN0IG9mIEphbnVhcnkgbWlkbmln aHQgVVRDIGVsc2UgSSB3aWxsIGFzayB0aGUgSElQU0VDIFdHIHRvIGFncmVlIHJlbW92aW5nIHRo ZSBISVAtREVYIHNlY3Rpb24gZnJvbSB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50LiAqKio8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQpEb2VzIHRoZSBhYm92ZSBhZGRyZXNzIHRo ZSBvcGVuIGl0ZW1zPzxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFsbCBpbiBh bGwsIHRoZXJlIGhhdmUgYmVlbiBhIGNvdXBsZSBvZiBzaWduaWZpY2FudCBjaGFuZ2VzIChJX05P TkNFLCBzb21lIGRlbGV0ZWQgY2lwaGVycykgc2luY2UgdGhlIElFVEYgbGFzdCBjYWxsIChzZWUN CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWhp cC1kZXgtMjMmYW1wO3VybDE9ZHJhZnQtaWV0Zi1oaXAtZGV4LTIxIj4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWhpcC1kZXgtMjMmYW1wO3VybDE9ZHJhZnQt aWV0Zi1oaXAtZGV4LTIxPC9hPiApLCBzbywgYW5vdGhlciBJRVRGIExhc3QgQ2FsbCBpcyByZXF1 aXJlZCBidXQgc2hvdWxkIG5vdCBiZSBhIHJlYWwgcHJvYmxlbS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4tw6lyaWM8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+RnJvbTogUm9iZXJ0IE1vc2tvd2l0eiA8YSBocmVmPSJtYWlsdG86cmdtQGxhYnMuaHR0LWNv bnN1bHQuY29tIj4NCiZsdDtyZ21AbGFicy5odHQtY29uc3VsdC5jb20mZ3Q7PC9hPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+RGF0ZTogVGh1cnNkYXksIDE0IEphbnVhcnkgMjAyMSBhdCAxNjowODxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VG86 IEVyaWMgVnluY2tlIDxhIGhyZWY9Im1haWx0bzpldnluY2tlQGNpc2NvLmNvbSI+DQombHQ7ZXZ5 bmNrZUBjaXNjby5jb20mZ3Q7PC9hPiwgJnF1b3Q7RXJpYyBWeW5ja2UgKGV2eW5ja2UpJnF1b3Q7 IDxhIGhyZWY9Im1haWx0bzpldnluY2tlPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnIj4NCiZs dDtldnluY2tlPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnJmd0OzwvYT4sIDxhIGhyZWY9Im1h aWx0bzpoaXBzZWNAaWV0Zi5vcmciPiZxdW90O2hpcHNlY0BpZXRmLm9yZyZxdW90OzwvYT4NCjxh IGhyZWY9Im1haWx0bzpoaXBzZWNAaWV0Zi5vcmciPiZsdDtoaXBzZWNAaWV0Zi5vcmcmZ3Q7PC9h PiwgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtaGlwLWRleEBpZXRmLm9yZyI+DQomcXVvdDtk cmFmdC1pZXRmLWhpcC1kZXhAaWV0Zi5vcmcmcXVvdDs8L2E+IDxhIGhyZWY9Im1haWx0bzpkcmFm dC1pZXRmLWhpcC1kZXhAaWV0Zi5vcmciPiZsdDtkcmFmdC1pZXRmLWhpcC1kZXhAaWV0Zi5vcmcm Z3Q7PC9hPiwgTWlpa2EgS29tdQ0KPGEgaHJlZj0ibWFpbHRvOm1paWthLmtvbXVAZXJpY3Nzb24u Y29tIj4mbHQ7bWlpa2Eua29tdUBlcmljc3Nvbi5jb20mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Q2M6IFJv bWFuIERhbnlsaXcgPGEgaHJlZj0ibWFpbHRvOnJkZEBjZXJ0Lm9yZyI+DQombHQ7cmRkQGNlcnQu b3JnJmd0OzwvYT4sIEVyaWMgUmVzY29ybGEgPGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSI+ Jmx0O2VrckBydGZtLmNvbSZndDs8L2E+LCBHb256YWxvIENhbWFyaWxsbw0KPGEgaHJlZj0ibWFp bHRvOmdvbnphbG8uY2FtYXJpbGxvQGVyaWNzc29uLmNvbSI+Jmx0O2dvbnphbG8uY2FtYXJpbGxv QGVyaWNzc29uLmNvbSZndDs8L2E+LA0KPGEgaHJlZj0ibWFpbHRvOnJlbmUuaHVtbWVuQGJlbGRl bi5jb20iPiZxdW90O3JlbmUuaHVtbWVuQGJlbGRlbi5jb20mcXVvdDs8L2E+IDxhIGhyZWY9Im1h aWx0bzpyZW5lLmh1bW1lbkBiZWxkZW4uY29tIj4NCiZsdDtyZW5lLmh1bW1lbkBiZWxkZW4uY29t Jmd0OzwvYT4sIEJlbmphbWluIEthZHVrIDxhIGhyZWY9Im1haWx0bzprYWR1a0BtaXQuZWR1Ij4m bHQ7a2FkdWtAbWl0LmVkdSZndDs8L2E+LCBFcmlrIEtsaW5lDQo8YSBocmVmPSJtYWlsdG86ZWsu aWV0ZkBnbWFpbC5jb20iPiZsdDtlay5pZXRmQGdtYWlsLmNvbSZndDs8L2E+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5T dWJqZWN0OiBSZTogW0hpcHNlY10gTmVlZCB0byBjbG9zZSBhbGwgZHJhZnQtaWV0Zi1oaXAtZGV4 LTIxIHBlbmRpbmcgaXNzdWVzLi4uIGJlZm9yZSAyMDIxLUphbi0xMy4uLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5JIGhhZCBob3BlZCB0byBnZXQgLTIzIG91dCBlbmQgb2YgbGFzdCB3ZWVr LCBhbmQgbWlzc2VkIG15IGN1dG9mZi4mbmJzcDsgSSBhbSBub3cgaW4gSUFDUidzIFJlYWwgV29y bGQgQ3J5cHRvLCB3aGVyZSBJIGhhdmUgZ290dGVuIGEgY291cGxlIHBvaW50ZXJzIGZvciBEUklQ IHdvcmsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkkgd2FzIHdhaXRpbmcgZm9yIHR3byBh bmFseXplcyB0aGF0IEkgZ290IEphbiA0LCBhbmQgaW5jb3Jwb3JhdGluZyB0aGVtIGluLiZuYnNw OyBJIGJlbGlldmUgdGhlc2UgU0hPVUxEIGFkZHJlc3MgbXVjaCBvZiBFS1IncyBxdWVzdGlvbnMu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkkgd2lsbCBoYXZlIGEgcnVuIG9mIDFNIERFWCBy YW5kb20gSElzIHRvIEhJVHMgZ2VuZXJhdGVkIHdpdGggbm8gZHVwbGljYXRlcyB0aGF0IEkgYWRk IGluIGFuIEFwcGVuZGl4IGFsb25nIHdpdGggdGhlIFB5dGhvbiBjb2RlLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5JIGFtIGFkZGluZyBhIEJFWC9ERVggY3J5cHRvIGNvc3QgaW50byAxLjIs IHByb2JhYmx5IDEuMi4xOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5Gb3IgYW4gSW5pdGlh dG9yLCBCRVggaXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjIgUEsgc2lnIHZhcmlmaWNh dGlvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij4xIFBLIHNpZyBnZW5lcmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+MSBESCBrZXlw YWlyIGdlbmVyYXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4xIERIIHNlY3JldCBkZXJpdmF0aW9uLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5ERVggaXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjEg REggc2VjcmV0IGRlcml2YXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkkgaGF2ZSBj eWNsZXMgZm9yIHRoZXNlIGFuZCBhIHBhcGVyIHRvIHJlZmVyZW5jZSwgZXhjZXB0IEVDREgga2V5 cGFpciBnZW5lcmF0aW9uLCBvbiBhbiA4IGJpdCBwcm9jZXNzIGFuZCB0aGUgbnVtYmVycyBhcmUg YmlnLiZuYnNwOyBCdXQgSSB0aGluayB0aGF0IHBhcnQgYmVsb25ncyBpbiBhbiBBcHBlbmRpeC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+U28gdW5saWtlbHkgRnJpZGF5LiZuYnNwOyBCdXQg ZWFybHkgdGhlIGZvbGxvd2luZyB3ZWVrLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPk9uIDEvMTIvMjEgNjoxOSBBTSwgRXJpYyBWeW5ja2UgKGV2eW5ja2UpIHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+VHdvIG1vbnRocyBhZnRlciB0aGUgZW1haWwgYmVsb3csIEkgc2VuZGluZyBhIGtp bmQgcmVtaW5kZXIgdG8gYXV0aG9ycyBhbmQgV0cuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PldpdGggdGhlIC0yMiwgYSBsb3Qgb2YgKGlmIG5vdCBhbGwgKSBTRUMgQURz4oCZIERJU0NVU1Mg cG9pbnRzIHNob3VsZCBoYXZlIGJlZW4gYWRkcmVzc2VkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij5BcyBmYXIgYXMgSSBjYW4gdGVsbCwgdGhlIG90aGVyIHJlbWFpbmluZyBpc3N1ZSB3YXMg RWty4oCZcyBvbmUgYWJvdXQgd2h5IGZvcmZlaXRpbmcgRlMgd2hlbiBzb21lIGFsZ29yaXRobSBj b3VsZCBkbyBpdCBpbiBhIHJlYXNvbmFibGUgdGltZS4gSW4gYW4gZW1haWwgdG8gYXV0aG9ycyBh bmQgQURzLCBFcmljIFIuIHdyb3RlIOKAnGl0IGRlZmluZXMgYSBzZXQgb2YNCiBwYXJhbWV0ZXJz ICh0aGUgTklTVCBjdXJ2ZXMpIHdoaWNoIGFyZSBzbG93ZXIgdy9vIEZTIHRoYW4gb3RoZXIgcGFy YW1ldGVycyAoWDI1NTE5KSBhcmUgdy8gRlMuIFRoaXMgZmFjdCBjYWxscyBpbnRvIHF1ZXN0aW9u IHRoZSBuZWVkIHRvIGRpc3BlbnNlIHdpdGggRlMu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPldoaWxlIDIgbW9udGhzIGFnbyBJIHB1dCBhIGRlYWRsaW5lIGZvciB0b21vcnJvdywgSSAo YXMgdGhlIHJlc3BvbnNpYmxlIEFEKSBhbSBmbGV4aWJsZSBvZiBjb3Vyc2UgYnV0IHdlIGNhbm5v dCBsaW5nZXIgYW55bW9yZS4gSSBrbm93IHRoYXQgYSAtMjMgaXMgaW4gdGhlIHdvcmsgZm9yIHdl ZWtzID0mZ3Q7IGxldOKAmXMgcHVibGlzaCBpdCBpbiB0aGUgY29taW5nIGRheXMuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPkVsc2UsIG5leHQgd2VlayB3ZSB3aWxsIG5lZWQgdG8gZWl0aGVy IGNoYW5nZSB0aGUgaW50ZW5kZWQgc3RhdHVzIHRvIGV4cGVyaW1lbnRhbCBvciBkZWNsYXJlIHRo ZSBkb2N1bWVudCBkZWFkIGJ5IGxhY2sgb2YgZW5lcmd5LiBUaGUgbGF0dGVyIGRvZXMgbm90IGhh dmUgbXkgcHJlZmVyZW5jZSBvYnZpb3VzbHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlJl Z2FyZHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LcOpcmljPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+RnJvbTogSGlwc2VjIDxhIGhyZWY9Im1haWx0bzpo aXBzZWMtYm91bmNlc0BpZXRmLm9yZyI+DQptYWlsdG86aGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+IG9uIGJlaGFsZiBvZiAmcXVvdDtFcmljIFZ5bmNrZSAoZXZ5bmNrZSkmcXVvdDsgPGEgaHJl Zj0ibWFpbHRvOmV2eW5ja2U9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmciPg0KbWFpbHRvOmV2 eW5ja2U9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5EYXRlOiBGcmlk YXksIDEzIE5vdmVtYmVyIDIwMjAgYXQgMTU6MzI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRvOiA8YSBocmVmPSJtYWls dG86aGlwc2VjQGlldGYub3JnIj4NCm1haWx0bzpoaXBzZWNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9 Im1haWx0bzpoaXBzZWNAaWV0Zi5vcmciPm1haWx0bzpoaXBzZWNAaWV0Zi5vcmc8L2E+LA0KPGEg aHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtaGlwLWRleEBpZXRmLm9yZyI+bWFpbHRvOmRyYWZ0LWll dGYtaGlwLWRleEBpZXRmLm9yZzwvYT4NCjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWhpcC1k ZXhAaWV0Zi5vcmciPm1haWx0bzpkcmFmdC1pZXRmLWhpcC1kZXhAaWV0Zi5vcmc8L2E+LCBSb2Jl cnQgTW9za293aXR6DQo8YSBocmVmPSJtYWlsdG86cmdtQGxhYnMuaHR0LWNvbnN1bHQuY29tIj5t YWlsdG86cmdtQGxhYnMuaHR0LWNvbnN1bHQuY29tPC9hPiwgTWlpa2EgS29tdQ0KPGEgaHJlZj0i bWFpbHRvOm1paWthLmtvbXVAZXJpY3Nzb24uY29tIj5tYWlsdG86bWlpa2Eua29tdUBlcmljc3Nv bi5jb208L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5DYzogUm9tYW4gRGFueWxpdyA8YSBocmVmPSJtYWlsdG86cmRk QGNlcnQub3JnIj4NCm1haWx0bzpyZGRAY2VydC5vcmc8L2E+LCBFcmljIFJlc2NvcmxhIDxhIGhy ZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPm1haWx0bzpla3JAcnRmbS5jb208L2E+LCBHb256YWxv IENhbWFyaWxsbw0KPGEgaHJlZj0ibWFpbHRvOmdvbnphbG8uY2FtYXJpbGxvQGVyaWNzc29uLmNv bSI+bWFpbHRvOmdvbnphbG8uY2FtYXJpbGxvQGVyaWNzc29uLmNvbTwvYT4sDQo8YSBocmVmPSJt YWlsdG86cmVuZS5odW1tZW5AYmVsZGVuLmNvbSI+bWFpbHRvOnJlbmUuaHVtbWVuQGJlbGRlbi5j b208L2E+IDxhIGhyZWY9Im1haWx0bzpyZW5lLmh1bW1lbkBiZWxkZW4uY29tIj4NCm1haWx0bzpy ZW5lLmh1bW1lbkBiZWxkZW4uY29tPC9hPiwgQmVuamFtaW4gS2FkdWsgPGEgaHJlZj0ibWFpbHRv OmthZHVrQG1pdC5lZHUiPg0KbWFpbHRvOmthZHVrQG1pdC5lZHU8L2E+LCBFcmlrIEtsaW5lIDxh IGhyZWY9Im1haWx0bzplay5pZXRmQGdtYWlsLmNvbSI+bWFpbHRvOmVrLmlldGZAZ21haWwuY29t PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+U3ViamVjdDogW0hpcHNlY10gTmVlZCB0byBjbG9zZSBhbGwgZHJhZnQt aWV0Zi1oaXAtZGV4LTIxIHBlbmRpbmcgaXNzdWVzLi4uIGJlZm9yZSAyMDIxLUphbi0xMy4uLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5EZWFyIEhJUCwgZGVhciBhdXRob3JzLDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaGlzIGRvY3VtZW50IHdhcyByZXF1ZXN0ZWQgZm9yIHB1Ymxp Y2F0aW9uIFsxXSBpbiBGZWJydWFyeSAyMDE4ICgyLjUgeWVhcnMgYWdvKSwgdGhlbiBpdHMgSUVT RyBldmFsdWF0aW9uIGhhcyBiZWVuIGRlZmVycmVkLCB0aGVuIEkgdG9vayBvdmVyIHRoaXMgZG9j dW1lbnQgZnJvbSBUZXJyeSBNYW5kZXJzb24gaW4gTWFyY2ggMjAxOSwgdGhlbiBpdCB3ZW50DQog YWdhaW4gdGhyb3VnaCBJRVNHIGV2YWx1YXRpb24gaW4gSnVseSAyMDIwIGFuZCB0aGVyZSBhcmUg c3RpbGwgRElTQ1VTUyBwb2ludHMgdG8gYmUgYWRkcmVzc2VkIGV2ZW4gYWZ0ZXIgYSBjb3VwbGUg b2YgcmV2aXNlZCBJLUQuLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+RGlmZmljdWx0IG5v dCB0byBvYnNlcnZlIHRoYXQgdGhpcyBkb2N1bWVudCBkb2VzIG5vdCBwcm9ncmVzcyB2ZXJ5IGZh c3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk1vcmVvdmVyLCB0aGlzIGRvY3VtZW50IGlz IGEgbm9ybWF0aXZlIHJlZmVyZW5jZSBmb3IgcmZjNDQyMy1iaXMgd2FpdGluZyBpbiB0aGUgUkZD IGVkaXRvciBxdWV1ZSBzaW5jZSBNYXJjaCAyMDE5Li4uIFNvLCBhbHNvIGJsb2NraW5nIHRoZSBI SVAtTkFUIGRvY3VtZW50IFsyXS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QWZ0ZXIgZGlz Y3Vzc2lvbiB3aXRoIHRoZSBISVAgY2hhaXIsIEdvbnphbG8gaW4gY2MsIHdlIGhhdmUgdGFrZW4g dGhlIGZvbGxvd2luZyBkZWNpc2lvbjogaWYgYSByZXZpc2VkIEktRCBhZGRyZXNzaW5nIHJlbWFp bmluZyBESVNDVVNTIHBvaW50cyArIEVrcuKAmXMgb25lcyBpcyBub3QgdXBsb2FkZWQgd2l0aGlu IDIgbW9udGhzICgxM3RoIG9mIEphbnVhcnkgMjAyMSksDQogdGhlbiBJIHdpbGwgcmVxdWVzdCB0 aGUgSElQIFdHIHRvIGFjY2VwdCB0aGUgY29tcGxldGUgcmVtb3ZhbCBvZiBzZWN0aW9uIEEuMy4z IG9mIHRoZSByZmM0NDIzLWJpcyBkb2N1bWVudCAoMSBwYWdlIGFib3V0IEhJUC1ERVggaW4gdGhl IGFwcGVuZGl4KSArIHRoZSByZWZlcmVuY2UgdG8gdGhlIEhJUC1ERVggZG9jdW1lbnQgWzNdLiBU aGlzIHdpbGwgYWxsb3cgdGhlIGltbWVkaWF0ZSBwdWJsaWNhdGlvbiBvZiB0aGUgcmZjNDQyMy1i aXMgYW5kDQogSElQLU5BVCBkb2N1bWVudHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRo ZSBISVAgREVYIGF1dGhvcnMgbWF5IGFsc28gc2VsZWN0IHRvIGNoYW5nZSB0aGUgaW50ZW5kZWQg c3RhdHVzIG9mIHRoZSBkb2N1bWVudCB0byDigJhleHBlcmltZW50YWzigJkgKGlmIHRoZSBISVAg V0cgYWdyZWVzKSBhcyB0aGlzIG1heSByZWR1Y2UgdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBi eSB0aGUgU0VDIEFEIGFuZCBFa3IuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkdvbnphbG8g YW5kIEkgYXJlIHN0aWxsIGhvcGluZyB0byBnZXQgYSByZXZpc2VkIEhJUC1ERVggc2hvcnRseSw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+UmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij4tw6lyaWM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+WzFdIDxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaGlwLWRleC9oaXN0b3J5LyI+ DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWhpcC1kZXgvaGlz dG9yeS88L2E+IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+WzJdIDxhIGhyZWY9Imh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL2NsdXN0ZXJfaW5mby5waHA/Y2lkPUMzODYiPg0KaHR0cHM6Ly93d3cucmZjLWVkaXRvci5v cmcvY2x1c3Rlcl9pbmZvLnBocD9jaWQ9QzM4NjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlszXSBhbmQgcG9zc2li bHkgSSB3aWxsIHNldCB0aGUgc3RhdGUgb2YgSElQLURFWCBhcyDigJhkZWFk4oCZIG9uIHRoZSBk YXRhdHJhY2tlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0t IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+Um9iZXJ0IE1vc2tvd2l0ejxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T3duZXI8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkhU VCBDb25zdWx0aW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5DOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzI0OC0yMTktMjA1OTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+RjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsyNDgtOTY4LTI4MjQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnJnbUBsYWJzLmh0dC1jb25zdWx0LmNvbSI+bWFp bHRvOnJnbUBsYWJzLmh0dC1jb25zdWx0LmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+VGhlcmUncyBubyBsaW1pdCB0byB3aGF0IGNhbiBiZSBhY2NvbXBsaXNoZWQgaWYgaXQgZG9l c24ndCBtYXR0ZXIgd2hvIGdldHMgdGhlIGNyZWRpdDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0651C53661F44B95A187EC8F7BFD058Dciscocom_-- From nobody Tue Jan 19 12:25:11 2021 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFAF3A15A3; Tue, 19 Jan 2021 07:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, 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 W_CkskqZKDdA; Tue, 19 Jan 2021 07:29:49 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 B4D8F3A15AC; Tue, 19 Jan 2021 07:29:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 107FB6247F; Tue, 19 Jan 2021 10:29:44 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UlVvh99SpE3a; Tue, 19 Jan 2021 10:29:16 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 80738623C1; Tue, 19 Jan 2021 10:29:15 -0500 (EST) To: "Eric Vyncke (evyncke)" , Robert Moskowitz , "hipsec@ietf.org" , "draft-ietf-hip-dex@ietf.org" , Miika Komu Cc: Roman Danyliw , Eric Rescorla , Gonzalo Camarillo , "rene.hummen@belden.com" , Benjamin Kaduk , Erik Kline , Adam Wiethuechter References: <68AF0368-8CB8-4DF3-A33E-0AA28E61B5F5@cisco.com> <45191baf-ee46-89b8-fe84-742c5c17aadc@labs.htt-consult.com> <41AFBFEA-7119-451B-BC54-46CBB41274CA@cisco.com> <5f52aa64-48aa-87d3-5225-1741ca87b89d@htt-consult.com> <0651C536-61F4-4B95-A187-EC8F7BFD058D@cisco.com> From: Robert Moskowitz Message-ID: Date: Tue, 19 Jan 2021 10:29:06 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <0651C536-61F4-4B95-A187-EC8F7BFD058D@cisco.com> Content-Type: multipart/alternative; boundary="------------268A4C22EEAEBE64A637EF6C" Content-Language: en-US Archived-At: X-Mailman-Approved-At: Tue, 19 Jan 2021 12:24:35 -0800 Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13... X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 15:29:53 -0000 This is a multi-part message in MIME format. --------------268A4C22EEAEBE64A637EF6C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/19/21 9:44 AM, Eric Vyncke (evyncke) wrote: > Standard > > Bob, > > Thank you for your reply. I took some time to review the points. Look > for EVY2> below but at first sight, this looks really good to me now. > Of course, Roman and Ben will have a final say. > > About Ekr’s comment, I am reading your latest email sent minutes ago, > and I am still unclear where, in the text, it is shown that FS is not > achievable. > 1.2 (and 1.2.1) cover it.  the cost of FS is beyond what 8-bit CPUs are reasonably able to handle. If some vendor is willing to pay the cost of BEX, it is always an option.  Time and battery (and code) are against vendors going that route (choosing BEX for FS over DEX). > Action plan: please apply the changes you have proposed below, post a > revised I-D, then on my side: > > * Launching an IETF Last Call for 2 weeks (as written below some > important changes have been made but I expect the LC eventless) > * Probing Ben & Roman to review whether their DISCUSS still hold > I am ready with the changes.  I have an ICAO call I really need to get ready for, then a DR appt.  After that I will submit what I have if no new comments. > * > > Regards, it seems that the conclusion is near ;-) > > -éric > > *From: *Robert Moskowitz > *Date: *Monday, 18 January 2021 at 17:06 > *To: *Eric Vyncke , Robert Moskowitz > , "hipsec@ietf.org" , > "draft-ietf-hip-dex@ietf.org" , Miika > Komu > *Cc: *Roman Danyliw , Eric Rescorla , > Gonzalo Camarillo , > "rene.hummen@belden.com" , Benjamin Kaduk > , Erik Kline , Adam Wiethuechter > > *Subject: *Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 > pending issues... before 2021-Jan-13... > > On 1/18/21 9:12 AM, Eric Vyncke (evyncke) wrote: > > TD ;LR : more work to be done, deadline this Thursday 21st > > Bob, > > Thank you for the -23 (and Adam W for the footwork)and I > understand that you are quite busy. > > Here is the link to the diff between -21 and -23: > https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 > > (i.e., the one used by July 2020 IESG evaluation and the latest one) > > After the July 2020 IESG evaluation based on -21, there were a > couple of points to be addressed(with some comments of mine as EVY>): > > 1.Roman: “Section 6.3.  Per the definition of IKM, when should > these two different derivations be used? " > > 1.EVY> indeed, IKMm and IKMp are both defined but nothing is said > which one to use in which case. > > >        IKM       IKMm for Master Key SA Input keying material >                  or >                  IKMp for Pair-wise Key SA Input keying material > >        IKMm      Kij | I_NONCE >        IKMp      Kij | I_NONCE | (concatenated random values of the >                      ENCRYPTED_KEY parameters in the same order as >                      the HITs with sort(HIT-I | HIT-R)) > > Seems clear that IKMm is for the Master Key SA and IKMp is for the > Pair-wise Key SA. > > EVY2> Suggest to add a pointer to section 2.3 (definitions) and > possibly create entries for the master key SA and pair-wise key SA > (perhaps a little extreme though) > > > > > 2.Roman "discuss-discuss" (read this as request for reply and > non-blocking) about " further implementation experience provides > better guidance" in sections 6 and 9. > > 1.EVY> this really pleads for experimental status > > > The only place this text exists anymore is in Appendix C: iESG > Considerations > > Perhaps I should delete it from there. > > EVY2> you can keep it the appendix, I guess this fixes Roman’s > “discuss-discuss” > > 2. > > 3.Benjamin on FOLD collisions > > 1.EVY> IMHO addressed in the new section 3.2.1 > > > I believe I have this covered.  We have the Python scripts for tests, > but this is a lot of code to put into the document. Right now it is > privately held by Adam and I.  If called on, we can find some > permanent home for it. > > > 2. > > 4.Benjamin on ACL to counter FOLD collisions in section 3.2.1 > > 1.EVY> still light on the ACL but the above should clear it > > > Sec 7.1 is referenced. > > > 2. > > 5.Benjamin "how is it known that the peer should be using DEX vs. BEX" > > 1.EVY> partially addressed in section 1.2 but should be repeated > in the security section > > > I can create a sec 9.1 (pushing down the current 9.1): > > 9.1 Caution on using HIP DEX rather than HIP BEX > >    Due to the substantially reduced security guarantees of HIP DEX >    compared to HIP BEX, HIP DEX MUST only be used when at least one of >    the two endpoints is a class 0 or 1 constrained device defined in >    Section 3 of [RFC7228]).  HIP DEX MUST NOT be used when both >    endpoints are class 2 devices or unconstrained. > > > Will this work? > > EVY2>  it works for me and hopefully for Ben as well > > 2. > > 6.Benjamin lack of discussion on the security consequences of > inadvertent counter reuse in AES-CTR > > > See sec 9.1 > > EVY2> Indeed, Ben’s ballot is dated March 2020 on the revision -13. It > seems to be fixed to me in the latest revisions. > > 7. > > 8.Benjamin "presence of a CSPRNG in order to obtain secure session > keys" > > > 9.  Security Considerations > > .... > >    *  The strength of the keys for both the Master and Pair-wise Key SAs >       is based on the quality of the random keying material generated by >       the Initiator and the Responder.  As either peer may be a sensor >       or an actuator device, there is a natural concern about the >       quality of its random number generator.  Thus at least a CSPRNG >       SHOULD be used. > > EVY2> indeed, I should have detected that Ben was not using the -21 > but the -13 😉Now, please expand CSPRNG at first use. > > 9. > > 10.Benjamin "usage of CMAC instead of HMAC" about KEYMAT algorithm > > 1.EVY> new reference to NIST papers seems to address this concern > > > Ben did agree in an email that the SP800-56C and 108 addressed the > concern.  I did not need to go further. > > EVY2> if Ben was happy, then I am happy. Thank you for the information. > > 2. > > 11.Ekr’s one about why forfeiting FS when some algorithm could do > it in a reasonable time. In an email to authors and ADs, Eric R. > wrote “it defines a set of parameters (the NIST curves) which are > slower w/o FS than other parameters (X25519) are w/ FS. This fact > calls into question the need to dispense with FS.” > > 1.EVY> the additional section 1.2.1 and the reference to a paywall > EfficientECC reference do not offer a conclusive motivation for an > IETF standards w/o FS. > > > Paywall?  Hmm.  I got it free.  I will have to check into this.  It > may be to some cookie I have on this system.  Or the DOI has the wrong > URL. > > Ah, that URL works for me because I am an IACR member.  For all else: > > https://link.springer.com/article/10.1007/s10623-015-0087-1 > > > So I will change the reference.  But please check this out.  I tried > it on another machine that should not have my IACR cookies, but... > > > > > 2. > > ***Bottom line, the document is not yet ready to be approved.*** > (even if big progress has been made) > > As written in November (see below), the situation has lingered for > too long and is blocking the HIP-NAT and rfc4423-bis documents. > > *** Therefore, I request the authors for a revised I-D addressing > the above (and noting again that a change to ‘experimental’ – as > there are no deployed implementations – could probably fix all of > them) before Thursday 21st of January midnight UTC else I will ask > the HIPSEC WG to agree removing the HIP-DEX section from the > architecture document. *** > > > Does the above address the open items? > > > All in all, there have been a couple of significant changes > (I_NONCE, some deleted ciphers) since the IETF last call (see > https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 > > ), so, another IETF Last Call is required but should not be a real > problem. > > -éric > > From: Robert Moskowitz > > > Date: Thursday, 14 January 2021 at 16:08 > > To: Eric Vyncke , > "Eric Vyncke (evyncke)" > , "hipsec@ietf.org" > > , "draft-ietf-hip-dex@ietf.org" > > , Miika Komu > > > Cc: Roman Danyliw , Eric > Rescorla , Gonzalo Camarillo > > , "rene.hummen@belden.com" > > , Benjamin Kaduk > , Erik Kline > > > Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 > pending issues... before 2021-Jan-13... > > I had hoped to get -23 out end of last week, and missed my > cutoff.  I am now in IACR's Real World Crypto, where I have gotten > a couple pointers for DRIP work. > > I was waiting for two analyzes that I got Jan 4, and incorporating > them in.  I believe these SHOULD address much of EKR's questions. > > I will have a run of 1M DEX random HIs to HITs generated with no > duplicates that I add in an Appendix along with the Python code. > > I am adding a BEX/DEX crypto cost into 1.2, probably 1.2.1: > > For an Initiator, BEX is: > > 2 PK sig varifications. > > 1 PK sig generation. > > 1 DH keypair generation. > > 1 DH secret derivation. > > DEX is: > > 1 DH secret derivation. > > I have cycles for these and a paper to reference, except ECDH > keypair generation, on an 8 bit process and the numbers are big.  > But I think that part belongs in an Appendix. > > So unlikely Friday.  But early the following week. > > On 1/12/21 6:19 AM, Eric Vyncke (evyncke) wrote: > > Two months after the email below, I sending a kind reminder to > authors and WG. > > With the -22, a lot of (if not all ) SEC ADs’ DISCUSS points > should have been addressed. > > As far as I can tell, the other remaining issue was Ekr’s one > about why forfeiting FS when some algorithm could do it in a > reasonable time. In an email to authors and ADs, Eric R. wrote “it > defines a set of parameters (the NIST curves) which are slower w/o > FS than other parameters (X25519) are w/ FS. This fact calls into > question the need to dispense with FS.” > > While 2 months ago I put a deadline for tomorrow, I (as the > responsible AD) am flexible of course but we cannot linger > anymore. I know that a -23 is in the work for weeks => let’s > publish it in the coming days. > > Else, next week we will need to either change the intended status > to experimental or declare the document dead by lack of energy. > The latter does not have my preference obviously. > > Regards > > -éric > > From: Hipsec mailto:hipsec-bounces@ietf.org > on behalf of "Eric Vyncke > (evyncke)" mailto:evyncke=40cisco.com@dmarc.ietf.org > > > Date: Friday, 13 November 2020 at 15:32 > > To: mailto:hipsec@ietf.org > mailto:hipsec@ietf.org , > mailto:draft-ietf-hip-dex@ietf.org > > mailto:draft-ietf-hip-dex@ietf.org > , Robert Moskowitz > mailto:rgm@labs.htt-consult.com , > Miika Komu mailto:miika.komu@ericsson.com > > > Cc: Roman Danyliw mailto:rdd@cert.org , Eric > Rescorla mailto:ekr@rtfm.com , Gonzalo > Camarillo mailto:gonzalo.camarillo@ericsson.com > , > mailto:rene.hummen@belden.com > mailto:rene.hummen@belden.com , > Benjamin Kaduk mailto:kaduk@mit.edu , Erik > Kline mailto:ek.ietf@gmail.com > > Subject: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending > issues... before 2021-Jan-13... > > Dear HIP, dear authors, > > This document was requested for publication [1] in February 2018 > (2.5 years ago), then its IESG evaluation has been deferred, then > I took over this document from Terry Manderson in March 2019, then > it went again through IESG evaluation in July 2020 and there are > still DISCUSS points to be addressed even after a couple of > revised I-D... > > Difficult not to observe that this document does not progress very > fast. > > Moreover, this document is a normative reference for rfc4423-bis > waiting in the RFC editor queue since March 2019... So, also > blocking the HIP-NAT document [2]. > > After discussion with the HIP chair, Gonzalo in cc, we have taken > the following decision: if a revised I-D addressing remaining > DISCUSS points + Ekr’s ones is not uploaded within 2 months (13th > of January 2021), then I will request the HIP WG to accept the > complete removal of section A.3.3 of the rfc4423-bis document (1 > page about HIP-DEX in the appendix) + the reference to the HIP-DEX > document [3]. This will allow the immediate publication of the > rfc4423-bis and HIP-NAT documents. > > The HIP DEX authors may also select to change the intended status > of the document to ‘experimental’ (if the HIP WG agrees) as this > may reduce the security requirements by the SEC AD and Ekr. > > Gonzalo and I are still hoping to get a revised HIP-DEX shortly, > > Regards > > -éric > > [1] https://datatracker.ietf.org/doc/draft-ietf-hip-dex/history/ > > > [2] https://www.rfc-editor.org/cluster_info.php?cid=C386 > > > [3] and possibly I will set the state of HIP-DEX as ‘dead’ on the > datatracker > > -- > > Robert Moskowitz > > Owner > > HTT Consulting > > C:      248-219-2059 > > F:      248-968-2824 > > E: mailto:rgm@labs.htt-consult.com > > There's no limit to what can be accomplished if it doesn't matter > who gets the credit > > > --------------268A4C22EEAEBE64A637EF6C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 1/19/21 9:44 AM, Eric Vyncke (evyncke) wrote:
Standard

Bob,

 

Thank you for your reply. I took some time to review the points. Look for EVY2> below but at first sight, this looks really good to me now. Of course, Roman and Ben will have a final say.

 

About Ekr’s comment, I am reading your latest email sent minutes ago, and I am still unclear where, in the text, it is shown that FS is not achievable.


1.2 (and 1.2.1) cover it.  the cost of FS is beyond what 8-bit CPUs are reasonably able to handle.

If some vendor is willing to pay the cost of BEX, it is always an option.  Time and battery (and code) are against vendors going that route (choosing BEX for FS over DEX).


 

Action plan: please apply the changes you have proposed below, post a revised I-D, then on my side:

  • Launching an IETF Last Call for 2 weeks (as written below some important changes have been made but I expect the LC eventless)
  • Probing Ben & Roman to review whether their DISCUSS still hold

I am ready with the changes.  I have an ICAO call I really need to get ready for, then a DR appt.  After that I will submit what I have if no new comments.

 

Regards, it seems that the conclusion is near ;-)

 

-éric

 

From: Robert Moskowitz <rgm@htt-consult.com>
Date: Monday, 18 January 2021 at 17:06
To: Eric Vyncke <evyncke@cisco.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, "hipsec@ietf.org" <hipsec@ietf.org>, "draft-ietf-hip-dex@ietf.org" <draft-ietf-hip-dex@ietf.org>, Miika Komu <miika.komu@ericsson.com>
Cc: Roman Danyliw <rdd@cert.org>, Eric Rescorla <ekr@rtfm.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "rene.hummen@belden.com" <rene.hummen@belden.com>, Benjamin Kaduk <kaduk@mit.edu>, Erik Kline <ek.ietf@gmail.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>
Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...

 

 

On 1/18/21 9:12 AM, Eric Vyncke (evyncke) wrote:

TD ;LR : more work to be done, deadline this Thursday 21st

 

Bob,

 

Thank you for the -23 (and Adam W for the footwork) and I understand that you are quite busy.

 

Here is the link to the diff between -21 and -23: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 (i.e., the one used by July 2020 IESG evaluation and the latest one)

 

After the July 2020 IESG evaluation based on -21, there were a couple of points to be addressed (with some comments of mine as EVY>):

1.       Roman: “Section 6.3.  Per the definition of IKM, when should these two different derivations be used? "

1.       EVY> indeed, IKMm and IKMp are both defined but nothing is said which one to use in which case.


       IKM       IKMm for Master Key SA Input keying material
                 or
                 IKMp for Pair-wise Key SA Input keying material

       IKMm      Kij | I_NONCE
       IKMp      Kij | I_NONCE | (concatenated random values of the
                     ENCRYPTED_KEY parameters in the same order as
                     the HITs with sort(HIT-I | HIT-R))

Seems clear that IKMm is for the Master Key SA and IKMp is for the Pair-wise Key SA.

 

EVY2> Suggest to add a pointer to section 2.3 (definitions) and possibly create entries for the master key SA and pair-wise key SA (perhaps a little extreme though)

 




2.       Roman "discuss-discuss" (read this as request for reply and non-blocking) about " further implementation experience provides better guidance" in sections 6 and 9.

1.       EVY> this really pleads for experimental status


The only place this text exists anymore is in Appendix C:  iESG Considerations

Perhaps I should delete it from there.

EVY2> you can keep it the appendix, I guess this fixes Roman’s “discuss-discuss”

2.        

3.       Benjamin on FOLD collisions

1.       EVY> IMHO addressed in the new section 3.2.1


I believe I have this covered.  We have the Python scripts for tests, but this is a lot of code to put into the document.  Right now it is privately held by Adam and I.  If called on, we can find some permanent home for it.


2.        

4.       Benjamin on ACL to counter FOLD collisions in section 3.2.1

1.       EVY> still light on the ACL but the above should clear it


Sec 7.1 is referenced.


2.        

5.       Benjamin "how is it known that the peer should be using DEX vs. BEX"

1.       EVY> partially addressed in section 1.2 but should be repeated in the security section


I can create a sec 9.1 (pushing down the current 9.1):

9.1 Caution on using HIP DEX rather than HIP BEX

   Due to the substantially reduced security guarantees of HIP DEX
   compared to HIP BEX, HIP DEX MUST only be used when at least one of
   the two endpoints is a class 0 or 1 constrained device defined in
   Section 3 of [RFC7228]).  HIP DEX MUST NOT be used when both
   endpoints are class 2 devices or unconstrained.


Will this work?

 

EVY2>  it works for me and hopefully for Ben as well

2.        

6.       Benjamin lack of discussion on the security consequences of inadvertent counter reuse in AES-CTR


See sec 9.1

EVY2> Indeed, Ben’s ballot is dated March 2020 on the revision -13. It seems to be fixed to me in the latest revisions.

 

7.        

8.       Benjamin "presence of a CSPRNG in order to obtain secure session keys"


9.  Security Considerations

....

   *  The strength of the keys for both the Master and Pair-wise Key SAs
      is based on the quality of the random keying material generated by
      the Initiator and the Responder.  As either peer may be a sensor
      or an actuator device, there is a natural concern about the
      quality of its random number generator.  Thus at least a CSPRNG
      SHOULD be used.

 

EVY2> indeed, I should have detected that Ben was not using the -21 but the -13 😉 Now, please expand CSPRNG at first use.

9.        

10.   Benjamin "usage of CMAC instead of HMAC" about KEYMAT algorithm

1.       EVY> new reference to NIST papers seems to address this concern


Ben did agree in an email that the SP800-56C and 108 addressed the concern.  I did not need to go further.

 

EVY2> if Ben was happy, then I am happy. Thank you for the information.

 

2.        

11.   Ekr’s one about why forfeiting FS when some algorithm could do it in a reasonable time. In an email to authors and ADs, Eric R. wrote “it defines a set of parameters (the NIST curves) which are slower w/o FS than other parameters (X25519) are w/ FS. This fact calls into question the need to dispense with FS.”

1.       EVY> the additional section 1.2.1 and the reference to a paywall EfficientECC reference do not offer a conclusive motivation for an IETF standards w/o FS.


Paywall?  Hmm.  I got it free.  I will have to check into this.  It may be to some cookie I have on this system.  Or the DOI has the wrong URL.

Ah, that URL works for me because I am an IACR member.  For all else:

https://link.springer.com/article/10.1007/s10623-015-0087-1

So I will change the reference.  But please check this out.  I tried it on another machine that should not have my IACR cookies, but...




2.        

 

***Bottom line, the document is not yet ready to be approved.*** (even if big progress has been made)

 

As written in November (see below), the situation has lingered for too long and is blocking the HIP-NAT and rfc4423-bis documents.

 

*** Therefore, I request the authors for a revised I-D addressing the above (and noting again that a change to ‘experimental’ – as there are no deployed implementations – could probably fix all of them) before Thursday 21st of January midnight UTC else I will ask the HIPSEC WG to agree removing the HIP-DEX section from the architecture document. ***


Does the above address the open items?


 

All in all, there have been a couple of significant changes (I_NONCE, some deleted ciphers) since the IETF last call (see https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-23&url1=draft-ietf-hip-dex-21 ), so, another IETF Last Call is required but should not be a real problem.

 

 

-éric

 

 

 

From: Robert Moskowitz <rgm@labs.htt-consult.com>

Date: Thursday, 14 January 2021 at 16:08

To: Eric Vyncke <evyncke@cisco.com>, "Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>, "hipsec@ietf.org" <hipsec@ietf.org>, "draft-ietf-hip-dex@ietf.org" <draft-ietf-hip-dex@ietf.org>, Miika Komu <miika.komu@ericsson.com>

Cc: Roman Danyliw <rdd@cert.org>, Eric Rescorla <ekr@rtfm.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "rene.hummen@belden.com" <rene.hummen@belden.com>, Benjamin Kaduk <kaduk@mit.edu>, Erik Kline <ek.ietf@gmail.com>

Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...

 

I had hoped to get -23 out end of last week, and missed my cutoff.  I am now in IACR's Real World Crypto, where I have gotten a couple pointers for DRIP work.

 

I was waiting for two analyzes that I got Jan 4, and incorporating them in.  I believe these SHOULD address much of EKR's questions.

 

I will have a run of 1M DEX random HIs to HITs generated with no duplicates that I add in an Appendix along with the Python code.

 

I am adding a BEX/DEX crypto cost into 1.2, probably 1.2.1:

 

For an Initiator, BEX is:

 

2 PK sig varifications.

1 PK sig generation.

1 DH keypair generation.

1 DH secret derivation.

 

DEX is:

 

1 DH secret derivation.

 

I have cycles for these and a paper to reference, except ECDH keypair generation, on an 8 bit process and the numbers are big.  But I think that part belongs in an Appendix.

 

So unlikely Friday.  But early the following week.

 

 

 

 

 

On 1/12/21 6:19 AM, Eric Vyncke (evyncke) wrote:

Two months after the email below, I sending a kind reminder to authors and WG.

 

With the -22, a lot of (if not all ) SEC ADs’ DISCUSS points should have been addressed.

 

As far as I can tell, the other remaining issue was Ekr’s one about why forfeiting FS when some algorithm could do it in a reasonable time. In an email to authors and ADs, Eric R. wrote “it defines a set of parameters (the NIST curves) which are slower w/o FS than other parameters (X25519) are w/ FS. This fact calls into question the need to dispense with FS.”

 

While 2 months ago I put a deadline for tomorrow, I (as the responsible AD) am flexible of course but we cannot linger anymore. I know that a -23 is in the work for weeks => let’s publish it in the coming days.

 

Else, next week we will need to either change the intended status to experimental or declare the document dead by lack of energy. The latter does not have my preference obviously.

 

Regards

 

-éric

 

 

From: Hipsec mailto:hipsec-bounces@ietf.org on behalf of "Eric Vyncke (evyncke)" mailto:evyncke=40cisco.com@dmarc.ietf.org

Date: Friday, 13 November 2020 at 15:32

To: mailto:hipsec@ietf.org mailto:hipsec@ietf.org, mailto:draft-ietf-hip-dex@ietf.org mailto:draft-ietf-hip-dex@ietf.org, Robert Moskowitz mailto:rgm@labs.htt-consult.com, Miika Komu mailto:miika.komu@ericsson.com

Cc: Roman Danyliw mailto:rdd@cert.org, Eric Rescorla mailto:ekr@rtfm.com, Gonzalo Camarillo mailto:gonzalo.camarillo@ericsson.com, mailto:rene.hummen@belden.com mailto:rene.hummen@belden.com, Benjamin Kaduk mailto:kaduk@mit.edu, Erik Kline mailto:ek.ietf@gmail.com

Subject: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...

 

Dear HIP, dear authors,

 

This document was requested for publication [1] in February 2018 (2.5 years ago), then its IESG evaluation has been deferred, then I took over this document from Terry Manderson in March 2019, then it went again through IESG evaluation in July 2020 and there are still DISCUSS points to be addressed even after a couple of revised I-D...

 

Difficult not to observe that this document does not progress very fast.

 

Moreover, this document is a normative reference for rfc4423-bis waiting in the RFC editor queue since March 2019... So, also blocking the HIP-NAT document [2].

 

After discussion with the HIP chair, Gonzalo in cc, we have taken the following decision: if a revised I-D addressing remaining DISCUSS points + Ekr’s ones is not uploaded within 2 months (13th of January 2021), then I will request the HIP WG to accept the complete removal of section A.3.3 of the rfc4423-bis document (1 page about HIP-DEX in the appendix) + the reference to the HIP-DEX document [3]. This will allow the immediate publication of the rfc4423-bis and HIP-NAT documents.

 

The HIP DEX authors may also select to change the intended status of the document to ‘experimental’ (if the HIP WG agrees) as this may reduce the security requirements by the SEC AD and Ekr.

 

Gonzalo and I are still hoping to get a revised HIP-DEX shortly,

 

Regards

 

-éric

 

[1] https://datatracker.ietf.org/doc/draft-ietf-hip-dex/history/

[2] https://www.rfc-editor.org/cluster_info.php?cid=C386

[3] and possibly I will set the state of HIP-DEX as ‘dead’ on the datatracker

 

 

--

Robert Moskowitz

Owner

HTT Consulting

C:      248-219-2059

F:      248-968-2824

E:      mailto:rgm@labs.htt-consult.com

 

There's no limit to what can be accomplished if it doesn't matter who gets the credit




--------------268A4C22EEAEBE64A637EF6C-- From nobody Tue Jan 19 12:25:15 2021 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0953A1652 for ; Tue, 19 Jan 2021 09:34:13 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=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=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 XHvxCUHtRHep for ; Tue, 19 Jan 2021 09:34:08 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 DAA2C3A1654 for ; Tue, 19 Jan 2021 09:34:07 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id 23so30193420lfg.10 for ; Tue, 19 Jan 2021 09:34:07 -0800 (PST) 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=isXQP3i6es55xH7a1PLoo5/EamWWrZC2y3GMvD6x6kY=; b=V7ol7LkgRh+igOFIuhFdsuUiN6svqBWdJoPtepkaazM5qPYWV9A+me5JgtGbEZOltt NrrG2EQHYDoVXOA0uqPxdWP2OTRZgx7RNLRliyna8ugxlKm7sTB8ituXR6OnymOFu+V0 7QeEfruEPmyenWavcDCzsA02eXOTeqJXXlp9qLfxZa45EB3CwDFH/IRvCRCI4Zs2h8Hz L3Z0h6IzEhPIMDc6snoia7+86F7MDIAFYSPwNCr2Q+T3n1Eb8YJKe5lhKRbDLhMi/4Yi 0w02RbrPtlv2rggaapu3FcZ9ekkQHrpl6XXQwzO7WMvCKplHxiYsXOgzBygdwkLFbETX BOvA== 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=isXQP3i6es55xH7a1PLoo5/EamWWrZC2y3GMvD6x6kY=; b=gg793XDcVuQMy9VTWU2YkGHr4cJyiJ3j2HdOsbUM3MYClWQ6Kr1t7LFVUzNL2eNPGy geiIxzoOPR6g6fXgRhQOIXiYlDj4P9Z0aw/2DPQPCADVA2ZYKsspwDDfdR7z4ZtP2hqK qE4zGVF+Kpz9yystiUvSdDVTB9Bu09RQgRHe4j76W909uDa5y7ov32vHZRO7KADUVR0J sqS/ZD6UrHb0pNDu9amlhQKcWWkJLRMYw91ByvH2C2ex4UaHJxZlcFQdVnkI6unu6SWD w9BoQA9SwSN+VnXh2zLf/HWioxoXQ810rWXF8EIgWLZRvWZ0Fdjeuyaszlzve29q8Kp2 ZVMA== X-Gm-Message-State: AOAM530/fWoO6cgqwHl6RblV/oV/sivFQKbk+1TKXzg0ndQ974Na459+ kbgyIWUvR3Du5FENGWcg2TMxR3NSpz0Qyq8osnajLg== X-Google-Smtp-Source: ABdhPJxLotIjvqqwztkTxqJxg3J/UMW0h0LwtssqoBpwJmCnqckZTaCCYNztlp1trTIH8o1rI9haVp6oYujI23oVDr4= X-Received: by 2002:a19:4f4b:: with SMTP id a11mr2309430lfk.579.1611077645813; Tue, 19 Jan 2021 09:34:05 -0800 (PST) MIME-Version: 1.0 References: <68AF0368-8CB8-4DF3-A33E-0AA28E61B5F5@cisco.com> <45191baf-ee46-89b8-fe84-742c5c17aadc@labs.htt-consult.com> <41AFBFEA-7119-451B-BC54-46CBB41274CA@cisco.com> <5f52aa64-48aa-87d3-5225-1741ca87b89d@htt-consult.com> <0651C536-61F4-4B95-A187-EC8F7BFD058D@cisco.com> In-Reply-To: From: Eric Rescorla Date: Tue, 19 Jan 2021 09:33:29 -0800 Message-ID: To: Robert Moskowitz Cc: "Eric Vyncke (evyncke)" , Robert Moskowitz , "hipsec@ietf.org" , "draft-ietf-hip-dex@ietf.org" , Miika Komu , Roman Danyliw , Gonzalo Camarillo , "rene.hummen@belden.com" , Benjamin Kaduk , Erik Kline , Adam Wiethuechter Content-Type: multipart/alternative; boundary="000000000000c8df0d05b9443eed" Archived-At: X-Mailman-Approved-At: Tue, 19 Jan 2021 12:24:35 -0800 Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13... X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 17:34:14 -0000 --000000000000c8df0d05b9443eed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 19, 2021 at 7:29 AM Robert Moskowitz wrote: > > > On 1/19/21 9:44 AM, Eric Vyncke (evyncke) wrote: > > Bob, > > > > Thank you for your reply. I took some time to review the points. Look for > EVY2> below but at first sight, this looks really good to me now. Of > course, Roman and Ben will have a final say. > > > > About Ekr=E2=80=99s comment, I am reading your latest email sent minutes = ago, and > I am still unclear where, in the text, it is shown that FS is not > achievable. > > > 1.2 (and 1.2.1) cover it. the cost of FS is beyond what 8-bit CPUs are > reasonably able to handle. > > If some vendor is willing to pay the cost of BEX, it is always an option. > Time and battery (and code) are against vendors going that route (choosin= g > BEX for FS over DEX). > I must say, I find this whole discussion baffling. To recap, the original rationale for this protocol was the one Bob makes above, namely that "the cost of FS is beyond what 8-bit CPUs are reasonably able to handle." However, this claim was presented without any actual requirements for what an acceptable cost was and the protocol as sent by the WGLC to the IESG included a wide range of cryptographic primitives, some of which would be comparable if not slower to a forward secure exchange with the best available algorithms (i.e., X25519) This implies one of three things: 1. The requirements are not known. 2. The requirements have quite a bit of headroom above a non-FS exchange with the best available algorithms and potentially could accommodate FS. 3. The original protocol did not in fact meet the requirements. The proper conclusion, in any case, is that we don't know whether we can fit a FS exchange into the requirements and we won't until a proper requirements analysis is done. Removing the NIST curves, as Bob proposes to do, merely removes the obvious inconsistency from the specification; it does not address the question of whether we need to abandon FS. -Ekr > > > > Action plan: please apply the changes you have proposed below, post a > revised I-D, then on my side: > > - Launching an IETF Last Call for 2 weeks (as written below some > important changes have been made but I expect the LC eventless) > - Probing Ben & Roman to review whether their DISCUSS still hold > > > I am ready with the changes. I have an ICAO call I really need to get > ready for, then a DR appt. After that I will submit what I have if no ne= w > comments. > > > - > > > > Regards, it seems that the conclusion is near ;-) > > > > -=C3=A9ric > > > > *From: *Robert Moskowitz > *Date: *Monday, 18 January 2021 at 17:06 > *To: *Eric Vyncke , Robert > Moskowitz , > "hipsec@ietf.org" , > "draft-ietf-hip-dex@ietf.org" > , Miika Komu > > *Cc: *Roman Danyliw , Eric Rescorla > , Gonzalo Camarillo > , > "rene.hummen@belden.com" > , Benjamin Kaduk , > Erik Kline , Adam Wiethuechter > > *Subject: *Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending > issues... before 2021-Jan-13... > > > > > > On 1/18/21 9:12 AM, Eric Vyncke (evyncke) wrote: > > TD ;LR : more work to be done, deadline this Thursday 21st > > > > Bob, > > > > Thank you for the -23 (and Adam W for the footwork) and I understand that > you are quite busy. > > > > Here is the link to the diff between -21 and -23: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-dex-23&url1=3Ddraft-ie= tf-hip-dex-21 (i.e., > the one used by July 2020 IESG evaluation and the latest one) > > > > After the July 2020 IESG evaluation based on -21, there were a couple of > points to be addressed (with some comments of mine as EVY>): > > 1. Roman: =E2=80=9CSection 6.3. Per the definition of IKM, when sh= ould > these two different derivations be used? " > > 1. EVY> indeed, IKMm and IKMp are both defined but nothing is said > which one to use in which case. > > > IKM IKMm for Master Key SA Input keying material > or > IKMp for Pair-wise Key SA Input keying material > > IKMm Kij | I_NONCE > IKMp Kij | I_NONCE | (concatenated random values of the > ENCRYPTED_KEY parameters in the same order as > the HITs with sort(HIT-I | HIT-R)) > > Seems clear that IKMm is for the Master Key SA and IKMp is for the > Pair-wise Key SA. > > > > EVY2> Suggest to add a pointer to section 2.3 (definitions) and possibly > create entries for the master key SA and pair-wise key SA (perhaps a litt= le > extreme though) > > > > > > > 2. Roman "discuss-discuss" (read this as request for reply and > non-blocking) about " further implementation experience provides better > guidance" in sections 6 and 9. > > 1. EVY> this really pleads for experimental status > > > The only place this text exists anymore is in Appendix C: iESG > Considerations > > Perhaps I should delete it from there. > > EVY2> you can keep it the appendix, I guess this fixes Roman=E2=80=99s > =E2=80=9Cdiscuss-discuss=E2=80=9D > > 2. > > 3. Benjamin on FOLD collisions > > 1. EVY> IMHO addressed in the new section 3.2.1 > > > I believe I have this covered. We have the Python scripts for tests, but > this is a lot of code to put into the document. Right now it is privatel= y > held by Adam and I. If called on, we can find some permanent home for it= . > > > 2. > > 4. Benjamin on ACL to counter FOLD collisions in section 3.2.1 > > 1. EVY> still light on the ACL but the above should clear it > > > Sec 7.1 is referenced. > > > 2. > > 5. Benjamin "how is it known that the peer should be using DEX vs. > BEX" > > 1. EVY> partially addressed in section 1.2 but should be repeated > in the security section > > > I can create a sec 9.1 (pushing down the current 9.1): > > 9.1 Caution on using HIP DEX rather than HIP BEX > > Due to the substantially reduced security guarantees of HIP DEX > compared to HIP BEX, HIP DEX MUST only be used when at least one of > the two endpoints is a class 0 or 1 constrained device defined in > Section 3 of [RFC7228]). HIP DEX MUST NOT be used when both > endpoints are class 2 devices or unconstrained. > > > Will this work? > > > > EVY2> it works for me and hopefully for Ben as well > > 2. > > 6. Benjamin lack of discussion on the security consequences of > inadvertent counter reuse in AES-CTR > > > See sec 9.1 > > EVY2> Indeed, Ben=E2=80=99s ballot is dated March 2020 on the revision -1= 3. It > seems to be fixed to me in the latest revisions. > > > > 7. > > 8. Benjamin "presence of a CSPRNG in order to obtain secure session > keys" > > > 9. Security Considerations > > .... > > * The strength of the keys for both the Master and Pair-wise Key SAs > is based on the quality of the random keying material generated by > the Initiator and the Responder. As either peer may be a sensor > or an actuator device, there is a natural concern about the > quality of its random number generator. Thus at least a CSPRNG > SHOULD be used. > > > > EVY2> indeed, I should have detected that Ben was not using the -21 but > the -13 =F0=9F=98=89 Now, please expand CSPRNG at first use. > > 9. > > 10. Benjamin "usage of CMAC instead of HMAC" about KEYMAT algorithm > > 1. EVY> new reference to NIST papers seems to address this concern > > > Ben did agree in an email that the SP800-56C and 108 addressed the > concern. I did not need to go further. > > > > EVY2> if Ben was happy, then I am happy. Thank you for the information. > > > > 2. > > 11. Ekr=E2=80=99s one about why forfeiting FS when some algorithm could= do it > in a reasonable time. In an email to authors and ADs, Eric R. wrote =E2= =80=9Cit > defines a set of parameters (the NIST curves) which are slower w/o FS tha= n > other parameters (X25519) are w/ FS. This fact calls into question the ne= ed > to dispense with FS.=E2=80=9D > > 1. EVY> the additional section 1.2.1 and the reference to a paywall > EfficientECC reference do not offer a conclusive motivation for an IETF > standards w/o FS. > > > Paywall? Hmm. I got it free. I will have to check into this. It may b= e > to some cookie I have on this system. Or the DOI has the wrong URL. > > Ah, that URL works for me because I am an IACR member. For all else: > > https://link.springer.com/article/10.1007/s10623-015-0087-1 > > So I will change the reference. But please check this out. I tried it o= n > another machine that should not have my IACR cookies, but... > > > > > 2. > > > > ***Bottom line, the document is not yet ready to be approved.*** (even if > big progress has been made) > > > > As written in November (see below), the situation has lingered for too > long and is blocking the HIP-NAT and rfc4423-bis documents. > > > > *** Therefore, I request the authors for a revised I-D addressing the > above (and noting again that a change to =E2=80=98experimental=E2=80=99 = =E2=80=93 as there are no > deployed implementations =E2=80=93 could probably fix all of them) before= Thursday > 21st of January midnight UTC else I will ask the HIPSEC WG to agree > removing the HIP-DEX section from the architecture document. *** > > > Does the above address the open items? > > > > > All in all, there have been a couple of significant changes (I_NONCE, som= e > deleted ciphers) since the IETF last call (see > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-dex-23&url1=3Ddraft-ie= tf-hip-dex-21 > ), so, another IETF Last Call is required but should not be a real proble= m. > > > > > > -=C3=A9ric > > > > > > > > From: Robert Moskowitz > > > Date: Thursday, 14 January 2021 at 16:08 > > To: Eric Vyncke , "Eric Vyncke > (evyncke)" > , "hipsec@ietf.org" > , "draft-ietf-hip-dex@ietf.org" > > , Miika Komu > > > Cc: Roman Danyliw , Eric Rescorla > , Gonzalo Camarillo > , > "rene.hummen@belden.com" > , Benjamin Kaduk , > Erik Kline > > Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending > issues... before 2021-Jan-13... > > > > I had hoped to get -23 out end of last week, and missed my cutoff. I am > now in IACR's Real World Crypto, where I have gotten a couple pointers fo= r > DRIP work. > > > > I was waiting for two analyzes that I got Jan 4, and incorporating them > in. I believe these SHOULD address much of EKR's questions. > > > > I will have a run of 1M DEX random HIs to HITs generated with no > duplicates that I add in an Appendix along with the Python code. > > > > I am adding a BEX/DEX crypto cost into 1.2, probably 1.2.1: > > > > For an Initiator, BEX is: > > > > 2 PK sig varifications. > > 1 PK sig generation. > > 1 DH keypair generation. > > 1 DH secret derivation. > > > > DEX is: > > > > 1 DH secret derivation. > > > > I have cycles for these and a paper to reference, except ECDH keypair > generation, on an 8 bit process and the numbers are big. But I think tha= t > part belongs in an Appendix. > > > > So unlikely Friday. But early the following week. > > > > > > > > > > > > On 1/12/21 6:19 AM, Eric Vyncke (evyncke) wrote: > > Two months after the email below, I sending a kind reminder to authors an= d > WG. > > > > With the -22, a lot of (if not all ) SEC ADs=E2=80=99 DISCUSS points shou= ld have > been addressed. > > > > As far as I can tell, the other remaining issue was Ekr=E2=80=99s one abo= ut why > forfeiting FS when some algorithm could do it in a reasonable time. In an > email to authors and ADs, Eric R. wrote =E2=80=9Cit defines a set of para= meters > (the NIST curves) which are slower w/o FS than other parameters (X25519) > are w/ FS. This fact calls into question the need to dispense with FS.=E2= =80=9D > > > > While 2 months ago I put a deadline for tomorrow, I (as the responsible > AD) am flexible of course but we cannot linger anymore. I know that a -23 > is in the work for weeks =3D> let=E2=80=99s publish it in the coming days= . > > > > Else, next week we will need to either change the intended status to > experimental or declare the document dead by lack of energy. The latter > does not have my preference obviously. > > > > Regards > > > > -=C3=A9ric > > > > > > From: Hipsec mailto:hipsec-bounces@ietf.org on > behalf of "Eric Vyncke (evyncke)" > mailto:evyncke=3D40cisco.com@dmarc.ietf.org > > > Date: Friday, 13 November 2020 at 15:32 > > To: mailto:hipsec@ietf.org mailto:hipsec@ietf.org > , mailto:draft-ietf-hip-dex@ietf.org > mailto:draft-ietf-hip-dex@ietf.org > , Robert Moskowitz > mailto:rgm@labs.htt-consult.com , Miika Komu > mailto:miika.komu@ericsson.com > > Cc: Roman Danyliw mailto:rdd@cert.org , Eric Rescorla > mailto:ekr@rtfm.com , Gonzalo Camarillo > mailto:gonzalo.camarillo@ericsson.com , > mailto:rene.hummen@belden.com > mailto:rene.hummen@belden.com , Benjamin Kaduk > mailto:kaduk@mit.edu , Erik Kline mailto:ek.ietf@gmail.com > > > Subject: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending > issues... before 2021-Jan-13... > > > > Dear HIP, dear authors, > > > > This document was requested for publication [1] in February 2018 (2.5 > years ago), then its IESG evaluation has been deferred, then I took over > this document from Terry Manderson in March 2019, then it went again > through IESG evaluation in July 2020 and there are still DISCUSS points t= o > be addressed even after a couple of revised I-D... > > > > Difficult not to observe that this document does not progress very fast. > > > > Moreover, this document is a normative reference for rfc4423-bis waiting > in the RFC editor queue since March 2019... So, also blocking the HIP-NAT > document [2]. > > > > After discussion with the HIP chair, Gonzalo in cc, we have taken the > following decision: if a revised I-D addressing remaining DISCUSS points = + > Ekr=E2=80=99s ones is not uploaded within 2 months (13th of January 2021)= , then I > will request the HIP WG to accept the complete removal of section A.3.3 o= f > the rfc4423-bis document (1 page about HIP-DEX in the appendix) + the > reference to the HIP-DEX document [3]. This will allow the immediate > publication of the rfc4423-bis and HIP-NAT documents. > > > > The HIP DEX authors may also select to change the intended status of the > document to =E2=80=98experimental=E2=80=99 (if the HIP WG agrees) as this= may reduce the > security requirements by the SEC AD and Ekr. > > > > Gonzalo and I are still hoping to get a revised HIP-DEX shortly, > > > > Regards > > > > -=C3=A9ric > > > > [1] https://datatracker.ietf.org/doc/draft-ietf-hip-dex/history/ > > [2] https://www.rfc-editor.org/cluster_info.php?cid=3DC386 > > [3] and possibly I will set the state of HIP-DEX as =E2=80=98dead=E2=80= =99 on the > datatracker > > > > > > -- > > Robert Moskowitz > > Owner > > HTT Consulting > > C: 248-219-2059 > > F: 248-968-2824 > > E: mailto:rgm@labs.htt-consult.com > > > > There's no limit to what can be accomplished if it doesn't matter who get= s > the credit > > > > > --000000000000c8df0d05b9443eed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 19, 2021 at 7:29 AM Rober= t Moskowitz <rgm@htt-consult.com<= /a>> wrote:
=20 =20 =20


On 1/19/21 9:44 AM, Eric Vyncke (evyncke) wrote:
=20 =20 =20 =20

Bob,

=C2=A0

Thank you for your reply. I took some time to review the points. Look for EVY2> below but at first sight, this looks really good to me now. Of course, Roman and Ben will have a final say.<= u>

=C2=A0

About Ekr=E2=80=99s com= ment, I am reading your latest email sent minutes ago, and I am still unclear where, in the text, it is shown that FS is not achievable.


1.2 (and 1.2.1) cover it.=C2=A0 the cost of FS is beyond what 8-bit CPU= s are reasonably able to handle.

If some vendor is willing to pay the cost of BEX, it is always an option.=C2=A0 Time and battery (and code) are against vendors going tha= t route (choosing BEX for FS over DEX).

I must say, I find this whole discussion baffling.

<= /div>
To recap, the original rationale for this protocol was the one Bo= b makes above, namely that "the cost of FS is beyond what 8-bit CPUs are reasonably able to handle." However, this claim was presented = without any actual requirements for what an acceptable cost was and the pro= tocol as sent by the WGLC to the IESG included a wide range of cryptographi= c primitives, some of which would be comparable if not slower to a forward = secure exchange with the best available algorithms (i.e., X25519)=C2=A0 Thi= s implies one of three things:

1. The requirements= are not known.
2. The requirements have quite a bit of headroom = above a non-FS exchange with the best available algorithms and potentially = could accommodate FS.
3. The original protocol did not in fac= t meet the requirements.

The proper conclusion, in= any case, is that we don't know whether we can fit a FS exchange into = the requirements and we won't until a proper requirements analysis is d= one. Removing the NIST curves, as Bob proposes to do, merely removes the ob= vious inconsistency from the specification; it does not address the questio= n of whether we need to abandon FS.

-Ekr
=





=C2=A0

Action plan: please apply the changes you have proposed below, post a revised I-D, then on my side:

  • Launching an I= ETF Last Call for 2 weeks (as written below some important changes have been made but I expect the LC eventless)
  • Probing Ben &a= mp; Roman to review whether their DISCUSS still hold

I am ready with the changes.=C2=A0 I have an ICAO call I really need to get ready for, then a DR appt.=C2=A0 After that I will submit what I ha= ve if no new comments.

  • =

=C2=A0

Regards, it seems that the conclusion is near ;-)

=C2=A0

-=C3=A9ric

=C2=A0

From: Robert Moskowitz <rgm@htt-consult.com>
Date: Monday, 18 January 2021 at 17:06
To: Eric Vyncke <evyncke@cisco.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, "hi= psec@ietf.org" <hipsec@ietf.org>, "draft-ietf-hip-dex@ietf.org" <draft-ietf-hip-dex@ietf.org>, Miika Komu = <miika.komu@ericsson.com>
Cc: Roman Danyliw <rdd@cert.org>, Eric Rescorla &l= t;ekr@rtfm.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, &= quot;rene.hummen@belden.com" <rene.hummen@belden.com>, Benjamin Kaduk <kaduk@mit.edu>, Erik Kline <ek= .ietf@gmail.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>
Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...

=C2=A0

=C2=A0

On 1/18/21 9:12 AM, Eric Vyncke (evyncke) wrote:

TD=C2=A0;LR=C2= =A0: more work to be done, deadline this Thursday 21st

=C2=A0<= u>

Bob,

=C2=A0

Thank y= ou for the -23 (and Adam W for the footwork) and I understand that you are quite busy.

=C2=A0

Here is the link to the diff between -21 and -23: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-dex-23&url1=3Ddraft-= ietf-hip-dex-21 (i.e., the one used by July 2020 IESG evaluation and the latest one)

=C2=A0

After the July 2020 IESG evaluation based on -21, there were a couple of points to be addressed (with some comments of mine as EVY>):

1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Roman: =E2=80=9CSection 6.3.=C2=A0 Per the definition of IKM, when should these two different derivations be used? "

1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EVY> indeed, IKMm and IKMp are both defined but nothing is said which one to use in which case.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IKM=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 IKMm for Master Key SA Input keying material
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IKMp for Pair-wise Key SA Input keying material

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IKMm=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Kij | I_NONCE
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IKMp=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Kij | I_NONCE | (concatenated random values of the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ENCRYPTED_KEY par= ameters in the same order as
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the HITs with sor= t(HIT-I | HIT-R))

Seems clear that IKMm is for the Master Key SA and IKMp is for the Pair-wise Key SA.

=C2=A0

EVY2> Suggest to add a pointer to section 2.3 (definitions) and possibly create entries for the master key SA and pair-wise key SA (perhaps a little extreme though)

=C2=A0




2.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Roman "discuss-discuss" (read this as request for reply a= nd non-blocking) about " further implementation experience provides better guidance" in sections 6 and 9.=

1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EVY> this really pleads for experimental status


The only place this text exists anymore is in Appendix C:=C2=A0 iESG Considerations

Perhaps I should delete it from there.

EVY2> you can keep i= t the appendix, I guess this fixes Roman=E2=80=99s =E2=80=9Cdiscu= ss-discuss=E2=80=9D

2.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0

3.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Benjamin on FOLD collisions

1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EVY> IMHO addressed in the new section 3.2.1<= /p>


I believe I have this covered.=C2=A0 We have the Python scripts f= or tests, but this is a lot of code to put into the document.=C2=A0 Right now it is privately held by Adam and I.=C2=A0 If called on, we can find some permanent home for it.


2.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0

4.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Benjamin on ACL to counter FOLD collisions in section 3.2.1=

1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EVY> still light on the ACL but the above should clear it


Sec 7.1 is referenced.


2.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0

5.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Benjamin "how is it known that the peer should be using DEX vs. BEX"

1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EVY> partially addressed in section 1.2 but should be repeated in the security section


I can create a sec 9.1 (pushing down the current 9.1):

9.1 Caution on using HIP DEX rather than HIP BEX

=C2=A0=C2=A0 Due to the substantially reduced security guarantees= of HIP DEX
=C2=A0=C2=A0 compared to HIP BEX, HIP DEX MUST only be used when = at least one of
=C2=A0=C2=A0 the two endpoints is a class 0 or 1 constrained devi= ce defined in
=C2=A0=C2=A0 Section 3 of [RFC7228]).=C2=A0 HIP DEX MUST NOT be u= sed when both
=C2=A0=C2=A0 endpoints are class 2 devices or unconstrained.


Will this work?

=C2=A0

EVY2> =C2=A0it works= for me and hopefully for Ben as well

2.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0

6.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Benjamin lack of discussion on the security consequences of inadvertent counter reuse in AES-CTR


See sec 9.1

EVY2> Indeed, Ben=E2= =80=99s ballot is dated March 2020 on the revision -13. It seems to be fixed to me in the latest revisions.

=C2=A0

7.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0

8.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Benjamin "presence of a CSPRNG in order to obtain secure session keys"


9.=C2=A0 Security Considerations

....

=C2=A0=C2=A0 *=C2=A0 The strength of the keys for both the Master= and Pair-wise Key SAs
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is based on the quality of the ran= dom keying material generated by
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the Initiator and the Responder.= =C2=A0 As either peer may be a sensor
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or an actuator device, there is a = natural concern about the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 quality of its random number gener= ator.=C2=A0 Thus at least a CSPRNG
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHOULD be used.

=C2=A0

EVY2> indeed, I should have detected that Ben was not using the -21 but the -13 =F0=9F=98=89 Now, please expand CSPRNG at first use.

9.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0

10.= =C2=A0=C2=A0 Benjamin "usage of CMAC instead of HMAC" about KEYMAT algori= thm

1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EVY> new reference to NIST papers seems to address this concern=


Ben did agree in an email that the SP800-56C and 108 addressed the concern.=C2=A0 I did not need to go further.

=C2=A0

EVY2> if Ben was happy, then I am happy. Thank you for the information.

=C2=A0

2.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0

11.= =C2=A0=C2=A0 Ekr=E2=80=99s one about why forfeiting FS when some algorithm could do it in a reasonable time. In an email to authors and ADs, Eric R. wrote =E2=80=9Cit defines = a set of parameters (the NIST curves) which are slower w/o FS than other parameters (X25519) are w/ FS. This fact calls into question the need to dispense with FS.=E2=80=9D

1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EVY> the additional section 1.2.1 and the reference to a paywall EfficientECC reference do not offer a conclusive motivation for an IETF standards w/o FS.=


Paywall?=C2=A0 Hmm.=C2=A0 I got it free.=C2=A0 I will have to che= ck into this.=C2=A0 It may be to some cookie I have on this system.=C2=A0= Or the DOI has the wrong URL.

Ah, that URL works for me because I am an IACR member.=C2=A0 For all else:

https://link.springer.com/article/10.1007/s10623-0= 15-0087-1

So I will change the reference.=C2=A0 But please check this out.= =C2=A0 I tried it on another machine that should not have my IACR cookies, but...




2.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0

=C2=A0

***Bottom line= , the document is not yet ready to be approved.*** (even if big progress has been made)

=C2=A0<= u>

As written in = November (see below), the situation has lingered for too long and is blocking the HIP-NAT and rfc4423-bis documents.

=C2=A0<= u>

*** Therefore,= I request the authors for a revised I-D addressing the above (and noting again that a change to =E2=80=98experimental=E2=80=99 =E2=80=93 as there a= re no deployed implementations =E2=80=93 could probably fix all of them) bef= ore Thursday 21st of January midnight UTC else I will ask the HIPSEC WG to agree removing the HIP-DEX section from the architecture document. ***


Does the above address the open items?


=C2=A0<= u>

All in all, th= ere have been a couple of significant changes (I_NONCE, some deleted ciphers) since the IETF last call (see https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-dex-23&url1=3Ddraft-= ietf-hip-dex-21 ), so, another IETF Last Call is required but should not be a real problem.

=C2=A0<= u>

=C2=A0<= u>

-=C3=A9ric

=C2=A0<= u>

=C2=A0<= u>

=C2=A0

From: Robert Moskowitz <rgm@labs.htt-consult.com>

Date: Thursday, 14 January 2021 at 16:08

To: Eric Vyncke <evyncke@cisco.com>, "Eric Vyncke (evyncke)&qu= ot; <evyncke=3D40cisco.com@dmarc.ietf.org>, "hipsec@ietf.org" <hipsec= @ietf.org>, "draft-ietf-hip-dex@ietf.org" <draft-ietf-hip-dex@ietf= .org>, Miika Komu &l= t;miika.komu@ericsson.com>

Cc: Roman Danyliw <rdd@cert.org>, Eric Rescorla <ekr@rtfm.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, &qu= ot;rene.hummen@belden.com" <rene.hummen@belden.com>, Benjamin Kaduk <kaduk@mit.edu>, Erik Kline <ek.i= etf@gmail.com>

Subject: Re: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...

=C2=A0

I had hoped to get -23 out end of last week, and missed my cutoff.=C2=A0 I = am now in IACR's Real World Crypto, where I have gotten a couple pointers for DRIP work.

=C2=A0

I was waiting for two analyzes that I got Jan 4, and incorporating them in.=C2=A0 I believe these SHOULD address much of EKR's questions.

=C2=A0

I will have a run of 1M DEX random HIs to HITs generated with no duplicates that I add in an Appendix along with the Python code.

=C2=A0

I am adding a BEX/DEX crypto cost into 1.2, probably 1.2.1:

=C2=A0

For an Initiator, BEX is:

=C2=A0

2 PK sig varifications.

1 PK sig generation.

1 DH keypair generation.

1 DH secret derivation.

=C2=A0

DEX is:

=C2=A0

1 DH secret derivation.

=C2=A0

I have cycles for these and a paper to reference, except ECDH keypair generation, on an 8 bit process and the numbers are big.=C2=A0 But I think that part belongs in an Appendix.=

=C2=A0

So unlikely Friday.=C2=A0 But early the following week.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On 1/12/21 6:19 AM, Eric Vyncke (evyncke) wrote:

Two months after the email below, I sending a kind reminder to authors and WG.

=C2=A0

With the -22, a lot of (if not all ) SEC ADs=E2=80=99 DISCUSS points sho= uld have been addressed.

=C2=A0

As far as I can tell, the other remaining issue was Ekr=E2=80=99s one about= why forfeiting FS when some algorithm could do it in a reasonable time. In an email to authors and ADs, Eric R. wrote =E2=80=9Cit defines a set of parameters (the NIST curves) which are slower w/o FS than other parameters (X25519) are w/ FS. This fact calls into question the need to dispense with FS.=E2=80=9D

=C2=A0

While 2 months ago I put a deadline for tomorrow, I (as the responsible AD) am flexible of course but we cannot linger anymore. I know that a -23 is in the work for weeks =3D> let=E2=80=99s publish it in the coming days.

=C2=A0

Else, next week we will need to either change the intended status to experimental or declare the document dead by lack of energy. The latter does not have my preference obviously.=

=C2=A0

Regards

=C2=A0

-=C3=A9ric

=C2=A0

=C2=A0

From: Hipsec mailto:hipsec-bounces@ietf.org on behalf of "Eric Vyncke (evyncke)" mailto:evyncke=3D40cisco.com@dmarc.ietf.org=

Date: Friday, 13 November 2020 at 15:32

To: mailto:hipsec@ietf.org mailto:hipsec@ietf.org, mailto:draft-ietf-hip-dex@ietf.org mailto:draft-ietf-hip-dex@ietf.org, Robert Moskowitz m= ailto:rgm@labs.htt-consult.com, Miika Komu ma= ilto:miika.komu@ericsson.com

Cc: Roman Danyliw mailto:rdd@cert.org, Eric Rescorla mailto:ekr@rtfm.com, Gonzalo Camarillo mailto:gonzalo.camarillo@ericsson.com, mai= lto:rene.hummen@belden.com mailto:rene.hummen@belden.com, Benjamin Kaduk mailto:kaduk@mit.edu, Erik Kline mailto:ek.ietf@gmail.com

Subject: [Hipsec] Need to close all draft-ietf-hip-dex-21 pending issues... before 2021-Jan-13...

=C2=A0

Dear HIP, dear authors,

=C2=A0

This document was requested for publication [1] in February 2018 (2.5 years ago), then its IESG evaluation has been deferred, then I took over this document from Terry Manderson in March 2019, then it went again through IESG evaluation in July 2020 and there are still DISCUSS points to be addressed even after a couple of revised I-D...

=C2=A0

Difficult not to observe that this document does not progress very fast.

=C2=A0

Moreover, this document is a normative reference for rfc4423-bis waiting in the RFC editor queue since March 2019... So, also blocking the HIP-NAT document [2].

=C2=A0

After discussion with the HIP chair, Gonzalo in cc, we have taken the following decision: if a revised I-D addressing remaining DISCUSS points + Ekr=E2=80=99s ones is not uploaded w= ithin 2 months (13th of January 2021), then I will request the HIP WG to accept the complete removal of section A.3.3 of the rfc4423-bis document (1 page about HIP-DEX in the appendix) + the reference to the HIP-DEX document [3]. This will allow the immediate publication of the rfc4423-bis and HIP-NAT documents.

=C2=A0

The HIP DEX authors may also select to change the intended status of the document to =E2=80=98experimental=E2=80=99 (if the HIP WG agree= s) as this may reduce the security requirements by the SEC AD and Ekr.<= /u>

=C2=A0

Gonzalo and I are still hoping to get a revised HIP-DEX shortly,<= /u>

=C2=A0

Regards

=C2=A0

-=C3=A9ric

=C2=A0

[1] https://datatracker.ietf.org/doc/draft-ietf-hip-dex/history/ =

[2] https://www.rfc-editor.org/cluster_info.php?cid=3DC386=

[3] and possibly I will set the state of HIP-DEX as =E2=80=98dead=E2=80= =99 on the datatracker

=C2=A0

=C2=A0

--

Robert Moskowitz

Owner

HTT Consulting

C:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0248-219-2059

F:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0248-968-2824

E:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0mailto:rgm= @labs.htt-consult.com

=C2=A0

There's no limit to what can be accomplished if it doesn't matter who gets the credit




--000000000000c8df0d05b9443eed-- From nobody Tue Jan 19 15:38:01 2021 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8133A0366; Tue, 19 Jan 2021 15:37:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: hipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: hipsec@ietf.org Message-ID: <161109947311.1702.14611250206322839212@ietfa.amsl.com> Date: Tue, 19 Jan 2021 15:37:53 -0800 Archived-At: Subject: [Hipsec] I-D Action: draft-ietf-hip-dex-24.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 23:37:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol WG of the IETF. Title : HIP Diet EXchange (DEX) Authors : Robert Moskowitz Rene Hummen Miika Komu Filename : draft-ietf-hip-dex-24.txt Pages : 64 Date : 2021-01-19 Abstract: This document specifies the Host Identity Protocol Diet EXchange (HIP DEX), a variant of the Host Identity Protocol Version 2 (HIPv2) and specifically developed for use on low end processors. The HIP DEX protocol design aims at reducing the overhead of the employed cryptographic primitives by omitting public-key signatures and cryptographic hash functions. The HIP DEX protocol is primarily designed for computation or memory- constrained sensor/actuator devices. Like HIPv2, it is expected to be used together with a suitable security protocol such as the Encapsulated Security Payload (ESP) for the protection of upper layer protocol data. Unlike HIPv2, HIP DEX does not support Forward Secrecy (FS), and MUST only be used on devices where FS is prohibitively expensive. In addition, HIP DEX can also be used as a keying mechanism for security primitives at the MAC layer, e.g., for IEEE 802.15.4 networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-hip-dex-24.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-24 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 19 15:45:12 2021 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987313A03F1 for ; Tue, 19 Jan 2021 15:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, 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 qAb1cSQaofDA for ; Tue, 19 Jan 2021 15:45:08 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 72C1E3A0408 for ; Tue, 19 Jan 2021 15:45:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 5FFC06247F for ; Tue, 19 Jan 2021 18:45:07 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Rkj+DHuzFMvd for ; Tue, 19 Jan 2021 18:45:01 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id CB11E623C1 for ; Tue, 19 Jan 2021 18:44:58 -0500 (EST) To: hipsec@ietf.org References: <161109947311.1702.14611250206322839212@ietfa.amsl.com> From: Robert Moskowitz Message-ID: Date: Tue, 19 Jan 2021 18:44:49 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <161109947311.1702.14611250206322839212@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-dex-24.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 23:45:11 -0000 More fine-tuning. Please look at the diffs. Please note, that I have not been able to find any energy consumption numbers to go along with the cycles for the EdDSA signing and verifying.  I do not believe it is trivial; not from conversations I have had.  Also I am not sure you can simply convert cycles to wall time.  This was my experience when working on ZWave. For whatever reason, wall time was higher than simple cycle counting predicted. Happy reading!  Or at least diffs.  Maybe diff -21 with -24... On 1/19/21 6:37 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Host Identity Protocol WG of the IETF. > > Title : HIP Diet EXchange (DEX) > Authors : Robert Moskowitz > Rene Hummen > Miika Komu > Filename : draft-ietf-hip-dex-24.txt > Pages : 64 > Date : 2021-01-19 > > Abstract: > This document specifies the Host Identity Protocol Diet EXchange (HIP > DEX), a variant of the Host Identity Protocol Version 2 (HIPv2) and > specifically developed for use on low end processors. The HIP DEX > protocol design aims at reducing the overhead of the employed > cryptographic primitives by omitting public-key signatures and > cryptographic hash functions. > > The HIP DEX protocol is primarily designed for computation or memory- > constrained sensor/actuator devices. Like HIPv2, it is expected to > be used together with a suitable security protocol such as the > Encapsulated Security Payload (ESP) for the protection of upper layer > protocol data. Unlike HIPv2, HIP DEX does not support Forward > Secrecy (FS), and MUST only be used on devices where FS is > prohibitively expensive. In addition, HIP DEX can also be used as a > keying mechanism for security primitives at the MAC layer, e.g., for > IEEE 802.15.4 networks. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-hip-dex-24.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-24 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From nobody Wed Jan 20 06:48:42 2021 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F12EC3A141E; Wed, 20 Jan 2021 06:48:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk CC: Gonzalo Camarillo , draft-ietf-hip-dex@ietf.org, evyncke@cisco.com, gonzalo.camarillo@ericsson.com, hip-chairs@ietf.org, hipsec@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <161115411446.925.13438084676436304288@ietfa.amsl.com> Date: Wed, 20 Jan 2021 06:48:34 -0800 Archived-At: Subject: [Hipsec] Last Call: (HIP Diet EXchange (DEX)) to Proposed Standard X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2021 14:48:35 -0000 The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'HIP Diet EXchange (DEX)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-02-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the Host Identity Protocol Diet EXchange (HIP DEX), a variant of the Host Identity Protocol Version 2 (HIPv2) and specifically developed for use on low end processors. The HIP DEX protocol design aims at reducing the overhead of the employed cryptographic primitives by omitting public-key signatures and cryptographic hash functions. The HIP DEX protocol is primarily designed for computation or memory- constrained sensor/actuator devices. Like HIPv2, it is expected to be used together with a suitable security protocol such as the Encapsulated Security Payload (ESP) for the protection of upper layer protocol data. Unlike HIPv2, HIP DEX does not support Forward Secrecy (FS), and MUST only be used on devices where FS is prohibitively expensive. In addition, HIP DEX can also be used as a keying mechanism for security primitives at the MAC layer, e.g., for IEEE 802.15.4 networks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc6261: Encrypted Signaling Transport Modes for the Host Identity Protocol (Experimental - IETF stream) From nobody Wed Jan 20 07:09:54 2021 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5D93A144A; Wed, 20 Jan 2021 07:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=a0XOfDoJ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lWrbl4+/ 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 KW3TMJUMys4n; Wed, 20 Jan 2021 07:09:50 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083D13A144D; Wed, 20 Jan 2021 07:09:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4842; q=dns/txt; s=iport; t=1611155390; x=1612364990; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0fG9VeFIGQSWhnWhupCFZkksXrYgtGpSjo3Uj5wy33U=; b=a0XOfDoJSkVzBpXLH1fd2sdKI3JLMntYTVjK3JxnboaXE/eWzT6AWUo+ zI2O0ena4SB+YaKoXvGQntBM7xArC/U5T2iF3M3lVEB6v4UTfH+uYTH81 0w4s3hYyRXEwe/xtx6jrdZ2xue1gAwijKa3VCDOguGhXCPlspnCQtQRDQ 0=; IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AZ2Dr/6ktxUf2UX3sGIE/TXMCE1fpDfP7gW?= =?us-ascii?q?dD5ilNYBxZY6WkvuiUtrAyyQL0hDENWHsphNCHP+26TWnB8INuiLNxAZ6LZy?= =?us-ascii?q?OjnGezNolt4c/ZwzPmEzDj7eI178ldWoBEIpnLAVB+5PyU3CCRGdwt2cTC1a?= =?us-ascii?q?iui/vXwXsFd3AUV4hLxW5Ce2GmO2dxQxRLAod8NLf03LsGmxOLf3MLYsOnQl?= =?us-ascii?q?wMWOber9PG/aiWHyIuLRgh9QWIkHeU87b8CReVxVMzVDlIzLck/wH+4k/Ez4?= =?us-ascii?q?+ktOy2zQKZ6n/L4/1t6Zrc4/ZgJOjJsMgaLT3wlh2lDb4AZ5SutC04ydvfk2?= =?us-ascii?q?oCv8LLp34bTqFOwlPXOlq4uB78nzTnuQxel0PK7X+9rT/drdfiRDQ8YvAxx7?= =?us-ascii?q?5xVhfC8UIvsJVd/ctwrhiknqFaBx/BgyjxjuKgP3oB+ybEwgtBrccpg3NSSo?= =?us-ascii?q?cYYrNKxLZvgX99KosKHy7x9ekcYY9TJfzc//pffBe7aH3UrwBUsaSRd0kzBR?= =?us-ascii?q?uPTww+vNWU2VFt7QlE5nYfrfZv+ksoxdYYcd1p9u7EOqNnmPVlVckNd59wA+?= =?us-ascii?q?8HXI+eFnHNaQikChPWHX3XUIU8f17doZ/+57s4oMuwfoYT8Zc0kJPdFHtFqG?= =?us-ascii?q?8JfV70A8Hm5uwOzjn9BEGGGRj9wMBX4JZ0/pfmQqDwDCGFQFcy1+ytvusYGc?= =?us-ascii?q?+ef/qoIppZD7vCIALVaMF09jy7f6MXBWgVUcUTtNp+cUmJuNj3JorjsfGef+?= =?us-ascii?q?3UILbrDDY4SmLyCnYOR1HIVZx9x3HufkW9rAnaWnvrdEC614l3CrLm8+8az5?= =?us-ascii?q?VINoAkiHlMtX2JouWwbRFSuK0/e0VzZJn9lLmgmGWw9WHUq2FgOh9XCFdJ8K?= =?us-ascii?q?ztOkk6/jMiAgfRS/Iuqt+fcWdd0D+sPRlkVf7bFwZZuhBw4qK4L5uZwCg4EN?= =?us-ascii?q?K5OmeGj38ezUj6Cas0q+mm34PIa5k4BpEpVOhaDgPQDSF4ng5stSNecgMeX1?= =?us-ascii?q?TeETnvkK2hi5QRCIjkBoNBqTbuBfQRhWPUtE2aq81qe2ASWCS2V9WLxSw0QS?= =?us-ascii?q?BPu1F3+6gDobaJlDq1M1EjiOAgPFAkUhXLPJt2SCC+IKRdgPTCZRx5R2biv0?= =?us-ascii?q?3qtzgDPk7Rs3g0qkOkByuOYv3PCkdaoRljo9bX2WIxUH6ccUJ2Ym19qqtnGw?= =?us-ascii?q?39yypO+N7OQLav2G2MbVZH5ecRPFj+EGUvCzIr4cyr3xiInzvHL1Ea/9EFO+?= =?us-ascii?q?zQC6lLScCN5lqkNJCImaYaH/Vd4ZZiM5T0vvUWVP+EEjXlXg/QF/kkwEicqH?= =?us-ascii?q?ojJUBP2QoZuOKt1xv/4Gei2nkjRfLUPVR9XrkeZ8qR9m7+Wp+zodlEpMNwue?= =?us-ascii?q?u7KWPqbNGajanRcj5YMxvWyFTGBd0AuNRRvagosqF0EISeWTzU1Gtf1BF7KM?= =?us-ascii?q?vvjksRTOB657/GU7UfMvA6amZc/lAzks6II1ZuugvqAvUmdVVolmTFJbqykv?= =?us-ascii?q?P1gKtqBlfEqBr7OFGZ/SEY9/DZXzGb3bpfD64rO2xZZEU19XwKxpLMS6TATA?= =?us-ascii?q?GxM+1T9luzNXGwNKVQT6WIAr0cpBd36dPgpZ7dSwPonATL+TdrKKNH9GiqBd?= =?us-ascii?q?6oCAWXAOhS7pi0P0+PjqbC2r/8sB7nDT+gL0IWio1OeRZOMoBNijw+gJY21S?= =?us-ascii?q?b3QKrtuU4hm0Zf5zYillOF4PnQ3E7LWUVddQveidFKWDMWNH6Ch8HM6/KZ23?= =?us-ascii?q?Tw+yIt4+iKKG5AOtVVX8ENRY32JTp0IccevLS077Mi6x4zFCsGHio5knThxO?= =?us-ascii?q?to0reyxeXKV+DjAXnuP0gd+TQtPP8DogU77Wdac8a/6pqhYgIYUu4QasFPk7?= =?us-ascii?q?xruTdinFj//jQgRh1mvAAwy8XJJlvoI3xzGcHV7PTLqRACruyL90BuqHJMml?= =?us-ascii?q?mulVGbvBzvk9yovmcvxle9kiZusq/YQDcqmi5Wukp8waJnOmeQSmKEex24GV?= =?us-ascii?q?vtxu8zNXVhYFpB98wikAfDI64Xlpq30mpjqnAhDjItxqywf1yvOwm6H9eYFk?= =?us-ascii?q?HMKP2+Btlub/FNfmoPRkTGdCjskJI2Ux7OZZNl3hKjhn8BCcG1S92bSQiaC4?= =?us-ascii?q?QA+7FVJrflRJSQidyL2g9S8XwTqIyTsw3HoNth68SHKglg9c8saqQBAHbqwA?= =?us-ascii?q?502saeNDi/RLQ/7SPUqyj66SpeLMIL2Ah9+yknjCgKHifAPaLXemhgo3ocx4?= =?us-ascii?q?btVGkEz6+6OKpomGPMu0SotnWTNA38CjjXZ5QI43YksBnMW5jbuV/SQcuyCz?= =?us-ascii?q?lI9PuhEbi0mEPBvmewzbjs/Vqu1C9Fym9SSQ44zA2YRr0qegrr5loHOBlhHA?= =?us-ascii?q?4EqnvF5oMB42BqjUJhcjsdSNhrxlSQNTnADjbpjDmVOD1o94tvaR4NucFVuR?= =?us-ascii?q?Nz8yYfsUMPQa85npuCr0rFTBY2ci9cg9URkAeAj8o7SjB3PFLwKvP9vJyxL9?= =?us-ascii?q?2txYoyJUHR0twVaPl4YD9Ik7Tb+a3WTj9CdR2R2d5ovFD30wB561gogMk+sk?= =?us-ascii?q?78xIPeYzjo+bds8qoIT7X8iCx2TvFXfrBF3jGzKdsF8rIvnETl6cfBnyope6?= =?us-ascii?q?etuRFNRT+xTMQqQmB/UV6Cw/Z9mcOcqiCTdZxk4rbAzCUgcP7TcXIz55r7I3?= =?us-ascii?q?pO6rg+qe+iK7jmL3jQso1CHeMa3hDK4QA10Gz3g5j2DIm7LluwkCubRHVPMv?= =?us-ascii?q?cLIGVmXuXAAJRotLEjmRRQjON7OhtenP54Yi6b6Z4RvjblgpVGq41FmjAcZK?= =?us-ascii?q?qBsVR1vT5gH/yUt4kpn3nHznw5h/PEiqQ666S3CqQBPFOFG41wLPsAuN/eYp?= =?us-ascii?q?iEAmPFUTxx1oVEeleVBTCEgRpp1LNxeDgQk7l4buIzkKsi7qtFqkvENSvEC0?= =?us-ascii?q?0kPrjvfMBh6KQVAM2mmhkxXnWfzPGxbx0s2ow571EERJcGh/+of7d4n0sx0s?= =?us-ascii?q?ZxpeuztMdqbs4HnZ23JAL2uXLYrWPXWlCaPsyHTSZLTiRGSz2E8xrQLwC9FH?= =?us-ascii?q?fPgJ570kRHv2M8EGbdocinjHn8Z+T1i3Ad3zDfeCJA+dCLru5hwk39/06sk7?= =?us-ascii?q?43DPaOPKr3Reux7TJW0Nx5gK6e1JTMmqjECOxPw9Fuo7V+auZzjn+D28eVYK?= =?us-ascii?q?BopRSmedNo6rpnAUy+/Ckst9zA7sTpI7a3xTsVwNDCnwyhPI/dVTOadPlQAo?= =?us-ascii?q?OJWlpiezNBa/Yh0xYgAXwoylmdRWpnZ0vC8rmHD6kubFraNzc+Qta9RHadVq?= =?us-ascii?q?g5QVWC6MLJLZrZV99KBT1OHnvyO5LwvJGDuFKsIEz/DEyOvRsOFDiyyTXpy5?= =?us-ascii?q?Lm+Ivqm56gY3eLoeEINozEky+8eUzgOwn4v9U8Lz+qrCWoD4edg1lqYFYvdd?= =?us-ascii?q?i7jL0FXvGZOJOfnvllWfaUDRk6hwrMZSrDnQ7zQ2Cgz2YUDaprK0n4j+twAJ?= =?us-ascii?q?+gGV5amKW4eLeRRlAR8HrAePImqSXZojRyM9QS17ibAYIttxsaQLWBHIwVgZ?= =?us-ascii?q?h7aAMbQ5UutFJJa2YQae7Y0uVRMm+qj1T1Jw90BeP0cW5MAnnrSOLoS3DN4T?= =?us-ascii?q?UdT2NgL3NJ45xUQGl3Mjlx1+vhE5Cfw2e7tXynAsOJqUwSE48oENd/U0yzD5?= =?us-ascii?q?iV4wqitU4LhlzhxpppBKHFBO/CBHac+Dwfsljl2sk/9YPSSl6bw41HKOR7FI?= =?us-ascii?q?LgDw=3D=3D?= IronPort-PHdr: =?us-ascii?q?A9a23=3AY5/BzRZ6d6LDSSZ93YT+b1n/LTDfhN3EVjU94?= =?us-ascii?q?4c7i79IbqWo9ojjO0qa//h2kVvVRu3z6v9YhazRqa+zEWAD4JPUtncEfdQMU?= =?us-ascii?q?hIekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutZlDOrDu19zFBU?= =?us-ascii?q?hn6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0m?= =?us-ascii?q?XP0?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHCwAIRwhg/5FdJa1ZCR4BAQsSDEC?= =?us-ascii?q?DIlEHdlsvL4RAg0gDjWAlA5kTglMDVAsBAQENAQElCAIEAQGESgIXgWACJTg?= =?us-ascii?q?TAgMBAQsBAQUBAQECAQYEcYVhDIVzAQEBBCMRDAEBLAsBCwQCAQgRAwECAwI?= =?us-ascii?q?mAgICMBQBCAgCBAENBRSDEgGCVQMuAQ6lRwKKJXaBMoMFAQEGgTcCDkGDCxi?= =?us-ascii?q?CEQMGgQ4qgnaEAYZCCB4bgUE/gREnDBCCVj6CXQICAQEVgRosgxk0giyBTwk?= =?us-ascii?q?8LmYEJyyBFz0rERkGkzWlKwqCd4kvkjkDH4MqijKVEpQbixyRfgOEMwICAgI?= =?us-ascii?q?EBQIOAQEGgW0jgVdwFWUBgj5QFwINjiELGBSDOoUUhUR0NwIGAQkBAQMJfIp?= =?us-ascii?q?hXwEB?= X-IronPort-AV: E=Sophos;i="5.79,361,1602547200"; d="scan'208";a="828598734" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Jan 2021 15:09:48 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 10KF9mUI014807 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jan 2021 15:09:48 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 20 Jan 2021 09:09:48 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Wed, 20 Jan 2021 09:09:47 -0600 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 20 Jan 2021 09:09:47 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KjQkWyXItNlNLTNoUd1YyUYrFSAnNaWoBnZht9fGjaC7zbIlCYzgwyPRoZ3pAgMnoVQrspdaMGsFBo+6SXR+Z8nUbrtFWBYYV3sDZ40DN+hhXChGuH6HZv9JN/AV1ZPW+TgoU1esllsTq4NgnFSp/+rojLYpZ9dzruhOUJb+h3lxH6H9qfxPorz8wz0fAhJaEDSPXAxhrATo0lkDvttsvOsWYEe2xZgoLC/94J/H1nyGAvSgdMUFodmfbolH4sIedW/PBEOJa6j4hysJtg+WKeDMX4FZm2cMaX3AvSuKH2DisDx3K1FWwxVWVJrg+N+FFg85GvVvw6rSOAIv5rX8fQ== 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=0fG9VeFIGQSWhnWhupCFZkksXrYgtGpSjo3Uj5wy33U=; b=k1cEW5/T1Q09g4oAm2JIyuXztQXfxGUH5YCw1yEL7qERak6igruc0SP5/PQ4XPtdrSt46VmUl35HzG2jeXoHjXcx29EgOMIPHQCeqaKFPdxO7dQ0GJlEw6ZI1R5FC41CxJeEGoc2Nq3HcBwhKlk4HnE2ylir5+Iwa8WE56eY4wQABa1E6XnXHs+vG3Ml0JvObVlql/8Ypi6fw54iUjdc5Wb4PEEGuk5IPm1DcUI4bERzHvnMECyacID3i4mVmMwtsH7AwTTqMsyfG6F9gvzkfGpBhTopBto7zInA/UsB62xxWRUOVq63mmcmweOLspqdyw4OJOVINSEuPyZFTimAtA== 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=0fG9VeFIGQSWhnWhupCFZkksXrYgtGpSjo3Uj5wy33U=; b=lWrbl4+/ZbZ7sioER+Zmf6Pe1IZWC/eE0swJ7r8gw8+MWT9DOqw+jAbDijRFQhsH6hWvVz5ExgYWNp+mkTvu+tJaVXu8bzBfaQUrHiMnHeeKuf6JT6FqqbGfAwphdLj8+cbL02bUR2D5fCu+2PnMi0iPSlCkFB16hzmac5bxVdI= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5110.namprd11.prod.outlook.com (2603:10b6:510:3f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.10; Wed, 20 Jan 2021 15:09:46 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b%3]) with mapi id 15.20.3763.014; Wed, 20 Jan 2021 15:09:46 +0000 From: "Eric Vyncke (evyncke)" To: "last-call@ietf.org" , IETF-Announce CC: "draft-ietf-hip-dex@ietf.org" , "hip-chairs@ietf.org" , "hipsec@ietf.org" Thread-Topic: Last Call: (HIP Diet EXchange (DEX)) to Proposed Standard Thread-Index: AQHW7ztdVt2Qx4OZQ0yDlYVclSBuRKowruAA Date: Wed, 20 Jan 2021 15:09:46 +0000 Message-ID: <29AAD2A6-3AE1-4356-A444-7BFC9291C8CB@cisco.com> References: <161115411446.925.13438084676436304288@ietfa.amsl.com> In-Reply-To: <161115411446.925.13438084676436304288@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.45.21011103 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:61b3:36cb:af41:f268] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b51742e4-9a8f-427f-d026-08d8bd556ce3 x-ms-traffictypediagnostic: PH0PR11MB5110: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mXb1h2Dv/gBZYsr7WrqybXIi0bAYPEnTfJ4b+91v6/vFjiSODkkj9wpaEB8Hp3VEpNKzwIvCSMAcAftlAQDB4nFURNfgkHpUDFFYccq+3W6CX7UJgkkT0MC/nB8EMC7KYeTRuct1SeRgP2B9cicME+Pu9qmbDNnVrQ7OOFW8wgLiNmPvqIon56BULQ4i1I52MFhqJKd6RPrfz33EHrnkazdkSUh5HyyOAfSZL2sQmMMc/+Zw2GIC1HcrktTGvdI6I6LQGSnbrYpIzfScAjJQsdNzeHqwPRCb4X7XQ94Xzr8WJ37pN6joW1ftCr2kA0rdvxHVspDa/ZY5z6hs5Z9QG66trNLYFexpTcPtSM+GTa/aOInXTMej7BqHwAsVuMoljbLITbW9869SXVbS78z1AAkH5nTWIc8GSDVKmEfwaPf7teBQoMgFDcMbmqEBbz2sER7pQulkab9FtJhUBV5hhOjBM4CsxStQ3LWjqFF/bmlX59z2Cc3ZPD09BftDAkwBFgEJv1t//dsQoFmvF4DYbQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(376002)(396003)(346002)(366004)(66946007)(66476007)(64756008)(2906002)(478600001)(83380400001)(91956017)(76116006)(6512007)(2616005)(66446008)(5660300002)(86362001)(6486002)(66556008)(186003)(450100002)(36756003)(8676002)(33656002)(8936002)(4326008)(316002)(71200400001)(110136005)(966005)(6506007)(53546011)(54906003)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?aFUxdzEweGwvRGlIUDQ5OElsMnFNYVByRHk5VjNxaEJ5TFdZNHQzZExhSDJr?= =?utf-8?B?dFM1U0JMd2V5UVJRS3hGbHErSElueG15MmIxQTJCVVNPLzI3ekZsUEZBVFE0?= =?utf-8?B?cmExTlJQTXMyT2xyYXlCaEtMeVlVRjJIdXZjeDZIREE5a3pwdGRnN3FUUkJU?= =?utf-8?B?WmVZSFJWTlZubVQyQVRZTmVVYjVOVndycmtDSUNtSXdtU0g1Z1B3OU1ENWZi?= =?utf-8?B?eGFnaXNreTcxNnBFb3pFNStOMlJnWS9lWTRJekZ0Z0ZUYlJIeTlyUWIva1p2?= =?utf-8?B?OHVTM0RwU2JJM1RnS2pJR2NRVEV5OEVMMU5SdEkzSmRNZnRVcEsrNFF5aW9P?= =?utf-8?B?UkJFYkdXNnZtWnNQbnJZbmJPVHdwb3J5cXVZUi84UW1yY3FwMi9LMk5YSmJk?= =?utf-8?B?TmpEdDBKbVRCWFo2SGtNTGRsaFFjSWdCMytlTEwrTGI5UHlLdWdFbDZkNW9x?= =?utf-8?B?Wkt0djZrZ2hJVUJNeVNRL1VOaFdzS2NyWHg5dWNpOXBYV0FWZ0g3YmlYdlRJ?= =?utf-8?B?KzZVSTFiYkVTL3BzMHM0MUF3clFXWGVLZU5BZDZVWllNOEhISjJGbHhKQ2hG?= =?utf-8?B?V2pjYk1xSjEyWU5VbkluMXdVTzVsLzhuYytpaHBpM0UwSDJkNGpYS3RKNkZw?= =?utf-8?B?a3N6elVXTzlrUWdHK1dubmxkVUxlMjlCc290cW0vOVpHekkwOThBNGxwWG9u?= =?utf-8?B?TkxHcnF5WWIrKzJ5cW0yU0QvZXBFTFh3dHNKekpOek9zTmJaa25qeEFWcHJs?= =?utf-8?B?SDI1NHFPelFyNGRTaTRRaEpnODBLVWRWTXpSbk1ZK09NWk1Kb3NDdWxmK1Bs?= =?utf-8?B?RXgxencvaFpFa3E3cGlkTkVUOGhvZFB6MWtlZFQxOUJwdm9DclpyeG80ekhZ?= =?utf-8?B?NjZwZ2syY0k1bFpiYmVPRmUvOXVZYnI2L3Q1YmVGUG5xREFJbTBENXgyU1hE?= =?utf-8?B?cGNIUE5pVmNoZ2pxMis5TllkQXdlMzJRQzhqcmlPTnZLTEVsb3BIUThMMnBY?= =?utf-8?B?WUJZeWxsWWtIQ0xZOGpac2ZYcUFsMkNiRVJJQVJNWGhGVnM4cC9tcUFSQWVk?= =?utf-8?B?SHlSOUpnaW51Yzhva3Q2TlRPbU85Y0hJK2I1N3lUUTNUR0pDazVZTmJkOEht?= =?utf-8?B?WTZDaVlSWWhzbCtCcVNZT3gyR3dISDRBK05ZanphWGtTd3ZMaDczU284UTA5?= =?utf-8?B?RzBCSDhtSDJFODkvNzhZVTRXR1ZxQlN2V3NZOUJFcHNBeEJrYXFIdEFTdWsw?= =?utf-8?B?VGJldE1sb3pldThaMEdxbyt0UG5JZnUrMkk2TStUbkdGdzNoQ0VCRVhpc2ps?= =?utf-8?B?Rm0wMUpKUmErbGh0ZXZGNUgvTWtjUEZ5NXZ2ZWN6Z0JiR0tiNVdMRUdBL2ZD?= =?utf-8?B?REZWMEpDeEpFeS9IQWVvSThIM3drd0ZDc2dkVHAyUUhzUUNnRlJHemd1WkV1?= =?utf-8?Q?DNG/qTIE?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b51742e4-9a8f-427f-d026-08d8bd556ce3 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2021 15:09:46.8768 (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: 4jAMZEMm/v8VLHY5jg2JShtk4rxHagUeuEGQcs4XZD14WFrdTBIoRVFDLkRlqFfuPNgSt5UZIXsSYXGybD4xYw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5110 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [Hipsec] Last Call: (HIP Diet EXchange (DEX)) to Proposed Standard X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2021 15:09:52 -0000 VGhlcmUgaGF2ZSBiZWVuIHNldmVyYWwgb2YgKnNpZ25pZmljYW50KiBjaGFuZ2VzICBzaW5jZSB0 aGUgSUVURiBsYXN0IGNhbGwgaW4gTm92ZW1iZXIgMjAxOSBvbiB0aGUgLTExIHJldmlzaW9uLCBz bywgYXMgdGhlIHJlc3BvbnNpYmxlIEFELCBJIGFtIGFza2luZyB0aGUgSUVURiBjb21tdW5pdHkg Zm9yIDNyZCByZXZpZXcgb24gdGhlIGxhdGVzdCByZXZpc2lvbiAtMjQuDQoNClRoZSBjaGFuZ2Vz IGluY2x1ZGUgYXQgbGVhc3Q6IGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50LCB1c2Ugb2YgdGhlIEZP TEQgZnVuY3Rpb24sIElfTk9OQ0UsIGlucHV0IGtleWluZyBtYXRlcmlhbCBmb3IgbWFzdGVyL3Bh aXItd2lzZSBrZXkgZ2VuZXJhdGlvbiwgc2VjdXJpdHkgc2VjdGlvbiwgc29tZSBkZWxldGVkIERI IGdyb3VwcyBhbmQgY2lwaGVycy4NCg0KRm9yIHlvdXIgY29udmVuaWVuY2UgdGhlIGRpZmYgYmV0 d2VlbiB0aGUgdHdvIHZlcnNpb25zOiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi1oaXAtZGV4LTI0JnVybDE9ZHJhZnQtaWV0Zi1oaXAtZGV4LTExIA0KDQpUaGFu ayB5b3UgaW4gYWR2YW5jZSBmb3IgeW91ciB2YWx1YWJsZSBjb21tZW50cyBiZWZvcmUgdGhlIDNy ZCBvZiBGZWJydWFyeSAyMDIxLA0KDQotw6lyaWMgdnluY2tlDQoNClBTOiB0aGFuayB5b3UgZm9y IHRoZSBwcmV2aW91cyByZXZpZXdlcnMsIHlvdXIgY29tbWVudHMgaGF2ZSBoZWxwZWQgdGhlIGF1 dGhvcnMgdG8gaW1wcm92ZSB0aGUgZG9jdW1lbnQuIFRoYW5rIHlvdSBhcyB3ZWxsIHRvIHRoZSBh dXRob3JzIGZvciBsaXN0ZW5pbmcgdG8gdGhvc2UgY29tbWVudHMuDQoNCu+7vy0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiA8aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc+IG9uIGJlaGFs ZiBvZiBUaGUgSUVTRyA8aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc+DQpSZXBseS1UbzogImxhc3Qt Y2FsbEBpZXRmLm9yZyIgPGxhc3QtY2FsbEBpZXRmLm9yZz4NCkRhdGU6IFdlZG5lc2RheSwgMjAg SmFudWFyeSAyMDIxIGF0IDE1OjQ4DQpUbzogSUVURi1Bbm5vdW5jZSA8aWV0Zi1hbm5vdW5jZUBp ZXRmLm9yZz4NCkNjOiBHb256YWxvIENhbWFyaWxsbyA8Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nz b24uY29tPiwgImRyYWZ0LWlldGYtaGlwLWRleEBpZXRmLm9yZyIgPGRyYWZ0LWlldGYtaGlwLWRl eEBpZXRmLm9yZz4sIEVyaWMgVnluY2tlIDxldnluY2tlQGNpc2NvLmNvbT4sICJnb256YWxvLmNh bWFyaWxsb0Blcmljc3Nvbi5jb20iIDxnb256YWxvLmNhbWFyaWxsb0Blcmljc3Nvbi5jb20+LCAi aGlwLWNoYWlyc0BpZXRmLm9yZyIgPGhpcC1jaGFpcnNAaWV0Zi5vcmc+LCAiaGlwc2VjQGlldGYu b3JnIiA8aGlwc2VjQGlldGYub3JnPg0KU3ViamVjdDogTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1o aXAtZGV4LTI0LnR4dD4gKEhJUCBEaWV0IEVYY2hhbmdlIChERVgpKSB0byBQcm9wb3NlZCBTdGFu ZGFyZA0KDQoNCiAgICBUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gdGhlIEhv c3QgSWRlbnRpdHkgUHJvdG9jb2wgV0cgKGhpcCkgdG8NCiAgICBjb25zaWRlciB0aGUgZm9sbG93 aW5nIGRvY3VtZW50OiAtICdISVAgRGlldCBFWGNoYW5nZSAoREVYKScNCiAgICAgIDxkcmFmdC1p ZXRmLWhpcC1kZXgtMjQudHh0PiBhcyBQcm9wb3NlZCBTdGFuZGFyZA0KDQogICAgVGhlIElFU0cg cGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRoZSBuZXh0IGZldyB3ZWVrcywgYW5kIHNvbGlj aXRzIGZpbmFsDQogICAgY29tbWVudHMgb24gdGhpcyBhY3Rpb24uIFBsZWFzZSBzZW5kIHN1YnN0 YW50aXZlIGNvbW1lbnRzIHRvIHRoZQ0KICAgIGxhc3QtY2FsbEBpZXRmLm9yZyBtYWlsaW5nIGxp c3RzIGJ5IDIwMjEtMDItMDMuIEV4Y2VwdGlvbmFsbHksIGNvbW1lbnRzIG1heQ0KICAgIGJlIHNl bnQgdG8gaWVzZ0BpZXRmLm9yZyBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxlYXNlIHJldGFp biB0aGUgYmVnaW5uaW5nDQogICAgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0 ZWQgc29ydGluZy4NCg0KICAgIEFic3RyYWN0DQoNCg0KICAgICAgIFRoaXMgZG9jdW1lbnQgc3Bl Y2lmaWVzIHRoZSBIb3N0IElkZW50aXR5IFByb3RvY29sIERpZXQgRVhjaGFuZ2UgKEhJUA0KICAg ICAgIERFWCksIGEgdmFyaWFudCBvZiB0aGUgSG9zdCBJZGVudGl0eSBQcm90b2NvbCBWZXJzaW9u IDIgKEhJUHYyKSBhbmQNCiAgICAgICBzcGVjaWZpY2FsbHkgZGV2ZWxvcGVkIGZvciB1c2Ugb24g bG93IGVuZCBwcm9jZXNzb3JzLiAgVGhlIEhJUCBERVgNCiAgICAgICBwcm90b2NvbCBkZXNpZ24g YWltcyBhdCByZWR1Y2luZyB0aGUgb3ZlcmhlYWQgb2YgdGhlIGVtcGxveWVkDQogICAgICAgY3J5 cHRvZ3JhcGhpYyBwcmltaXRpdmVzIGJ5IG9taXR0aW5nIHB1YmxpYy1rZXkgc2lnbmF0dXJlcyBh bmQNCiAgICAgICBjcnlwdG9ncmFwaGljIGhhc2ggZnVuY3Rpb25zLg0KDQogICAgICAgVGhlIEhJ UCBERVggcHJvdG9jb2wgaXMgcHJpbWFyaWx5IGRlc2lnbmVkIGZvciBjb21wdXRhdGlvbiBvciBt ZW1vcnktDQogICAgICAgY29uc3RyYWluZWQgc2Vuc29yL2FjdHVhdG9yIGRldmljZXMuICBMaWtl IEhJUHYyLCBpdCBpcyBleHBlY3RlZCB0bw0KICAgICAgIGJlIHVzZWQgdG9nZXRoZXIgd2l0aCBh IHN1aXRhYmxlIHNlY3VyaXR5IHByb3RvY29sIHN1Y2ggYXMgdGhlDQogICAgICAgRW5jYXBzdWxh dGVkIFNlY3VyaXR5IFBheWxvYWQgKEVTUCkgZm9yIHRoZSBwcm90ZWN0aW9uIG9mIHVwcGVyIGxh eWVyDQogICAgICAgcHJvdG9jb2wgZGF0YS4gIFVubGlrZSBISVB2MiwgSElQIERFWCBkb2VzIG5v dCBzdXBwb3J0IEZvcndhcmQNCiAgICAgICBTZWNyZWN5IChGUyksIGFuZCBNVVNUIG9ubHkgYmUg dXNlZCBvbiBkZXZpY2VzIHdoZXJlIEZTIGlzDQogICAgICAgcHJvaGliaXRpdmVseSBleHBlbnNp dmUuICBJbiBhZGRpdGlvbiwgSElQIERFWCBjYW4gYWxzbyBiZSB1c2VkIGFzIGENCiAgICAgICBr ZXlpbmcgbWVjaGFuaXNtIGZvciBzZWN1cml0eSBwcmltaXRpdmVzIGF0IHRoZSBNQUMgbGF5ZXIs IGUuZy4sIGZvcg0KICAgICAgIElFRUUgODAyLjE1LjQgbmV0d29ya3MuDQoNCg0KDQoNCg0KICAg IFRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWENCiAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWhpcC1kZXgvDQoNCg0KDQogICAgTm8gSVBSIGRlY2xhcmF0 aW9ucyBoYXZlIGJlZW4gc3VibWl0dGVkIGRpcmVjdGx5IG9uIHRoaXMgSS1ELg0KDQoNCiAgICBU aGUgZG9jdW1lbnQgY29udGFpbnMgdGhlc2Ugbm9ybWF0aXZlIGRvd253YXJkIHJlZmVyZW5jZXMu DQogICAgU2VlIFJGQyAzOTY3IGZvciBhZGRpdGlvbmFsIGluZm9ybWF0aW9uOiANCiAgICAgICAg cmZjNjI2MTogRW5jcnlwdGVkIFNpZ25hbGluZyBUcmFuc3BvcnQgTW9kZXMgZm9yIHRoZSBIb3N0 IElkZW50aXR5IFByb3RvY29sIChFeHBlcmltZW50YWwgLSBJRVRGIHN0cmVhbSkNCg0KDQoNCg0K DQo= From nobody Wed Jan 20 16:05:41 2021 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EF23A1611 for ; Wed, 20 Jan 2021 16:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 3UszP9j1lzYX for ; Wed, 20 Jan 2021 16:05:37 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 C933F3A1610 for ; Wed, 20 Jan 2021 16:05:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 965946247F for ; Wed, 20 Jan 2021 19:05:36 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id W9NUCwTvC1s9 for ; Wed, 20 Jan 2021 19:05:28 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id B2B8B622C2 for ; Wed, 20 Jan 2021 19:05:21 -0500 (EST) To: HIP From: Robert Moskowitz Message-ID: Date: Wed, 20 Jan 2021 19:05:18 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------F4DE2633CD9021286C635B27" Content-Language: en-US Archived-At: Subject: [Hipsec] New Version Notification for draft-moskowitz-hip-new-crypto-08.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2021 00:05:40 -0000 This is a multi-part message in MIME format. --------------F4DE2633CD9021286C635B27 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Much improved with use of Xoodyak for a lightweight crypto. NIST's LWC has another year to run.  I would like it if Xoodyak is the selection, but... So this is in part to generally specify use of SHA-3 derived functions, EdDSA/x25519, and how a LWC really shakes things up! -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-hip-new-crypto-08.txt Date: Wed, 20 Jan 2021 15:47:11 -0800 From: internet-drafts@ietf.org To: Stuart W. Card , Adam Wiethuechter , Robert Moskowitz , Stuart Card A new version of I-D, draft-moskowitz-hip-new-crypto-08.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-hip-new-crypto Revision: 08 Title: New Cryptographic Algorithms for HIP Document date: 2021-01-20 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/archive/id/draft-moskowitz-hip-new-crypto-08.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/ Html: https://www.ietf.org/archive/id/draft-moskowitz-hip-new-crypto-08.html Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-08 Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-new-crypto-08 Abstract: This document provides new cryptographic algorithms to be used with HIP. The Edwards Elliptic Curve and the Keccak sponge functions are the main focus. The HIP parameters and processing instructions impacted by these algorithms are defined. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------F4DE2633CD9021286C635B27 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Much improved with use of Xoodyak for a lightweight crypto.

NIST's LWC has another year to run.  I would like it if Xoodyak is the selection, but...

So this is in part to generally specify use of SHA-3 derived functions, EdDSA/x25519, and how a LWC really shakes things up!

-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-hip-new-crypto-08.txt
Date: Wed, 20 Jan 2021 15:47:11 -0800
From: internet-drafts@ietf.org
To: Stuart W. Card <stu.card@axenterprize.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart Card <stu.card@axenterprize.com>



A new version of I-D, draft-moskowitz-hip-new-crypto-08.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-hip-new-crypto
Revision: 08
Title: New Cryptographic Algorithms for HIP
Document date: 2021-01-20
Group: Individual Submission
Pages: 16
URL: https://www.ietf.org/archive/id/draft-moskowitz-hip-new-crypto-08.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/
Html: https://www.ietf.org/archive/id/draft-moskowitz-hip-new-crypto-08.html
Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-08
Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-new-crypto-08

Abstract:
This document provides new cryptographic algorithms to be used with
HIP. The Edwards Elliptic Curve and the Keccak sponge functions are
the main focus. The HIP parameters and processing instructions
impacted by these algorithms are defined.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--------------F4DE2633CD9021286C635B27-- From nobody Thu Jan 28 14:37:52 2021 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13873A17B8 for ; Thu, 28 Jan 2021 14:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 vRanrMmLzkUK for ; Thu, 28 Jan 2021 14:37:48 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 EC1233A0C43 for ; Thu, 28 Jan 2021 14:37:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 21C61625FC for ; Thu, 28 Jan 2021 17:37:47 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Sx3vDcX4+Z0P for ; Thu, 28 Jan 2021 17:37:42 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id E241362543 for ; Thu, 28 Jan 2021 17:37:41 -0500 (EST) To: HIP From: Robert Moskowitz Message-ID: Date: Thu, 28 Jan 2021 17:37:40 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------3A32B9CABB3FC0AF716FC0CE" Content-Language: en-US Archived-At: Subject: [Hipsec] FWD: New Version Notification for draft-moskowitz-hip-new-crypto-09.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2021 22:37:51 -0000 This is a multi-part message in MIME format. --------------3A32B9CABB3FC0AF716FC0CE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Some fine tuning of use of Xoodyak based on comments from the Keccak team. -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-hip-new-crypto-09.txt Date: Thu, 28 Jan 2021 14:34:48 -0800 From: internet-drafts@ietf.org To: Stuart W. Card , Adam Wiethuechter , Robert Moskowitz , Stuart Card A new version of I-D, draft-moskowitz-hip-new-crypto-09.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-hip-new-crypto Revision: 09 Title: New Cryptographic Algorithms for HIP Document date: 2021-01-28 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/archive/id/draft-moskowitz-hip-new-crypto-09.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/ Html: https://www.ietf.org/archive/id/draft-moskowitz-hip-new-crypto-09.html Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-09 Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-new-crypto-09 Abstract: This document provides new cryptographic algorithms to be used with HIP. The Edwards Elliptic Curve and the Keccak sponge functions are the main focus. The HIP parameters and processing instructions impacted by these algorithms are defined. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------3A32B9CABB3FC0AF716FC0CE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Some fine tuning of use of Xoodyak based on comments from the Keccak team.



-------- Forwarded Message --------
Subject: New Version Notification for draft-moskowitz-hip-new-crypto-09.txt
Date: Thu, 28 Jan 2021 14:34:48 -0800
From: internet-drafts@ietf.org
To: Stuart W. Card <stu.card@axenterprize.com>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart Card <stu.card@axenterprize.com>



A new version of I-D, draft-moskowitz-hip-new-crypto-09.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-hip-new-crypto
Revision: 09
Title: New Cryptographic Algorithms for HIP
Document date: 2021-01-28
Group: Individual Submission
Pages: 16
URL: https://www.ietf.org/archive/id/draft-moskowitz-hip-new-crypto-09.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/
Html: https://www.ietf.org/archive/id/draft-moskowitz-hip-new-crypto-09.html
Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-09
Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-new-crypto-09

Abstract:
This document provides new cryptographic algorithms to be used with
HIP. The Edwards Elliptic Curve and the Keccak sponge functions are
the main focus. The HIP parameters and processing instructions
impacted by these algorithms are defined.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--------------3A32B9CABB3FC0AF716FC0CE--