Re: [Secdispatch] [Ace] EDHOC
Benjamin Kaduk <kaduk@mit.edu> Fri, 18 January 2019 17:27 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A206A131250; Fri, 18 Jan 2019 09:27:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu
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 aKxvv009qbPP; Fri, 18 Jan 2019 09:27:23 -0800 (PST)
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680127.outbound.protection.outlook.com [40.107.68.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC171312A1; Fri, 18 Jan 2019 09:27:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YxZaBgy1cBfsEXP6EUvsIVLJOMxBvm1FjAKA/XmdGdg=; b=fTqpdQ5MVHbjQfy8cq/VswYzxq5JBIqF8rGSB2CRTi/72tQfedK+lBGrTUoipGSkbp1O4lYuH7CvyDlC80A94XVB5LLgk+UBbTBVag41ITNKRbYRS4vLjWh0rwE+ZYNItOU7/L6On3C4oubJFLIcdvxYcUb2uR/cacd88Kmp0Vw=
Received: from MWHPR01CA0045.prod.exchangelabs.com (2603:10b6:300:101::31) by BL0PR01MB4804.prod.exchangelabs.com (2603:10b6:208:7c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.24; Fri, 18 Jan 2019 17:27:19 +0000
Received: from BY2NAM03FT053.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::209) by MWHPR01CA0045.outlook.office365.com (2603:10b6:300:101::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1537.26 via Frontend Transport; Fri, 18 Jan 2019 17:27:19 +0000
Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu;
Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT053.mail.protection.outlook.com (10.152.84.186) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Fri, 18 Jan 2019 17:27:18 +0000
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0IHREpB022782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Jan 2019 12:27:16 -0500
Date: Fri, 18 Jan 2019 11:27:14 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Richard Barnes <rlb@ipv.sx>
CC: Göran Selander <goran.selander@ericsson.com>, "secdispatch@ietf.org" <secdispatch@ietf.org>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, John Mattsson <john.mattsson@ericsson.com>, Francesca Palombini <francesca.palombini@ericsson.com>, "ace@ietf.org" <ace@ietf.org>
Message-ID: <20190118172714.GJ81907@kduck.mit.edu>
References: <D629D980-C059-474F-B259-2700F2EEAE41@ericsson.com> <79FD6563-8ADA-4D73-B8D5-C3D70604CD76@gmail.com> <F72354EF-2FB7-41C0-BCA1-6D4511A410B2@ericsson.com> <47F03C99-68C1-4ADB-873D-F01987D66849@ipv.sx>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <47F03C99-68C1-4ADB-873D-F01987D66849@ipv.sx>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(346002)(39860400002)(136003)(376002)(396003)(2980300002)(189003)(199004)(104016004)(11346002)(2486003)(956004)(76176011)(229853002)(426003)(4326008)(1076003)(446003)(966005)(478600001)(476003)(66574012)(6916009)(36906005)(7696005)(54906003)(8936002)(23676004)(8676002)(316002)(5660300001)(305945005)(106002)(786003)(486006)(26826003)(58126008)(246002)(93886005)(126002)(14444005)(33656002)(356004)(75432002)(86362001)(106466001)(47776003)(186003)(26005)(6306002)(336012)(6246003)(39060400002)(50466002)(88552002)(2906002)(2870700001)(55016002)(53416004)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR01MB4804; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1;
X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT053; 1:Mkce/fAipa6qrx50A9JxlGeRNBJzXUYEfouhOm9rDufftZ0T55VIVk9HrgZxqOBUDxnij3iipllIJK+uuE0U3nqTYU0QUZ+c4abAMmZcnf5yyr3RyMY6Bggk8e/CM1Ux
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: f6f14c4b-e062-47f6-f042-08d67d6a3298
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060); SRVR:BL0PR01MB4804;
X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4804; 3:evWMfACv0v7TFlUpxZ9td0nDdkapJQrPksMhDMqSjdc4t804dqXKOda2Zls0qNxqJxjqctzA9n7P6jF5EpwliC+NKeixCsAuBWyCM9Z45jjf1pdMN4IPUN2Y3NR8GXlukh8KqYw5HMsOkwMGNqjloiXLONwjclq+lA1RGlel/cj1KmqiOxvMBODpn+33gZNDm1z08FwQD4jyyrYNY7mekRPKTSW4fDF9qMUzh76hYWBoT2BInk39u6hpard6jkBUByevQTm1mzfSLqD8beMIRXSh8z0sjW8d6y+Kme97inuUf3LywkH5KqSqy2tRQRxZlKeDNEDyxYrP8v/W2QldQv5ZvTywCj6ohUy9/DS9xhOAQVufdrToR8VK/UXFEjbP; 25:h7J4dUNk4GZrAQqsc6FQXPIJcFuDZ6mXZNYEesEnO19itPQRV9R0lO/8NbTUqFQWwC+UyzLPGqyhopNi4XAcpjROL0dDWNuWSY7SkKlsF8iUlFBJhW0P/tc2bPbzrbzUDEypWOYtGzb9PD2sApZ16iaRPZoi+mADbMuoEaeepDYuQiZ7JKYkXNM95civNZeWJHE8gt/hAY9qxXWcV4ailzkQobK2YzjYOJJyGkX0sF56vVJa/26k+ZQ2JZ75z0VxtQlWT/DKDtobZhtoXEQgp3GJD3ankXL+pnQEqINuy3cXyolh/w8f2DL1pKjNx2jqvT//rWqkFDLFmOr5igHYXA==
X-MS-TrafficTypeDiagnostic: BL0PR01MB4804:
X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4804; 31:CgBSD1jBfsz22k4XnmPmEjdgZPJKuDBH2Eg87qZbb/OmPXDBnF2SfuLFaz5GkZAciYAkxTCqiAoCsi8mLT28H/5YUVzynRwboinNEIO7CZ1KkDW7vzeB6W86pxIClVh1k8mXBwRVn1rFwS/WhYyCbp5rWKEqNAEfAb8zdLvCFxkpuWuR8jtsu4XEX1UGvRSTbSVDDUHe8i/6c3mB/HjTVdUoCqwsT5cFDUefwaGZBxs=; 20:HqkpouJWpJI0fJB2fa2t53QIORl2oVg7NO0M4ALyQmn7rUO7l4+j/SZ0KoCrDeCnp5YVivoEp5wQacDN+vRTqEiIHB1j4wLR0l+OVS5tTH17HCA2kXbQZpZAc1/K99mNizU+giyU3PGxe0/Mg3xiuDq4PE0JLaGkwP2wKrS5oF1yNAk6R79gOGwNgd/nTz6G25LUg4UCuWJtDoWgnGc/vxFHc3UEpZ72HpjKOQwJ67/C/ZmuzxmsvYjwKmWVk3jF+5JVgxrrR4oUhC26jveoWnx6surszmQWtLeE9Qhdh3fYtpQHrS4HIWUMa8TEdTk7L34gkE8aE1nyCnX729vuE0u+fOcKEtYHb04AC3uGa1oEsA/MXV41z3Oh6TV/RjuD+2fmydn8fJ/MH/fwI62iTt+NVjhjzZHl8JMhDNOebY6NvSugwod4qgXoBnlzPCrf4HSu+Kn7wmf0h7YY93ARonECQLD3nEXxIsVWElo8bfYH8mh50kSzpst7kj1AeJtQaysrtP1XQDY5+oQ6aK1NIdV829blKkv0NRAC7AOLBH9Ok4KiaaajK0nmg1mf3PipSDf5+l89A0DfqwWaQn8TvQL93pUyQriuBnaqug9X6JI=
X-Microsoft-Antispam-PRVS: <BL0PR01MB48048177D47C06EAE8543D33A09C0@BL0PR01MB4804.prod.exchangelabs.com>
X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4804; 4:+9U5ri9M1Upo1pTaNIpCjiSz5MbiuFPzLhd2gcfTV+SKJzGeRRtQqG33oAnnf2BySvpro3CTfMfaDU1WiuUGjgQZqaFeikQ4kkVwyFVcf431a0RJKom0cFicv4qr7pQHZlk3KU53rJUtsO4wFEjdEVqz6S1eFfg9BjsBZibxpMwWNa/rclVRVf5RnheDSdnTI1DRgmwjy0lRmk2gnyeQPEgs8X12+AtWwEzcqff96FF65NjQI4aX33iTUjKBxMFhsDRryTymoUPdG2WRtmQeaGHqJeqDnuRBltxP9GGJaeqhuBOZ8UOYQIeMw5uyjFq2
X-Forefront-PRVS: 0921D55E4F
X-Microsoft-Exchange-Diagnostics: 1;BL0PR01MB4804;23:ueoWraCP/waq0ysCsHKtzNenrJzFgy0Y+KLOxhtttDXmuIX7l6cOtOuRAZIulN0XcTEB1eOTueqKymgA67NIJjJ1+0QjHUwJwMvXhZmQ3SvEU75ioHaVSFX1Ek76Z+7ngPpZxur01WqcKR4tB5CuNoHO8ZRQORwtibponSkvnBOx5OjIqpoXEvtFhYlbbEWiOJHr7zeuuGyu39C3FwSb5wH5Ritf+W4ea6a01MTaM/KA1lR/dbiYDDf8kwYKseZr6UFhehf3w9uJV0czYCvOLjAFUFmeHHEfs6Y+ruZxupGhy/FysNxKojyIsJO203akT+YOwoSbZc7M0VWMc6X3fJtgpBCgbRhIlOLa99NPR+FicLCgkf2Kjqo0FgXOfjwad+/1wD28IIXOq96phORkiHbD3czELjedmRR8QND/0S2w5og3zBPVg5R73sdG4qut0dBd6h97bn9c2cdBb37IBE6dF8xupYsFLzGeJUHdIDxUM2+iSSnA5p2NSEWcI1iMkEIC3blbMFpLqyNgaiCpdLHyk49kEzWmG5lKJAZz3bV3XNAIV/s93D3c19vfZrzBHbluWDh5kzGVCTmvRq7IoIwnEkeVwuQ3fSTSl2qDpspmLM+RYyRWOES4NF9rUz06VkBHIgbS2fLZKkKKUe66nJ22UKNB7/tgcK0tRfEUegpZnpr/Jjc5Zz86vW3rZ4yV6tlwW2IV8VBCF/L8RRQqBiZP06XWmVpZQbnnQH/w+B0gMPVKOYJY7DZbIE+7kIeds1+q7JCK23hXB/+fFn6GuF/wEkZv3jMMLMzpvMlwu+yMFSV+qjCtubwRVtWwa1PX8yrZ3WIlM1zgU+V+0LraJxJAZ4xOgXZXRi8fakw1iMGoSl3AUdwfiKJ5aphqz+0ygd9XcN6WeaE59ZoEkjHJVuxuc36AWFYsNr4/0oGOFwzEIg426RjqO/X1fU+pE8O4VlwhUptGO5gnT/CmxwuDr2DwS3oz1DB0aeSVukTOjNV5o/Gu5UAiQbu9iI8INyY+RDp22IMeG18goj9EDeWh6L9alz5qUjCDEISa8/ZzgrQ9+SNnZRC/Stew1xDLRapCxfP6zsdP6pYGsc+UGxF44vGCqYefK/P5yUQDe2CBYgIEL98JFlDYOnvI4n96TlriK7edeaEd+YN3X8/V74DA1ND3F6jaro81vYIa1M2QNsTXUPsK9BM9CjT5VcDthYkSN9uVpzAU+OUALrrqKvifHgZMaajD2CGIIMmgCj58b3IzRhv/ok4EEVohPaxLW7FzueuwTOquZ4r8r3+6cV6oQXq1qyqBc/x2WCJnHvbbVsA=
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: +xTwEDD5ZyorEVaUqVtPdJ0gMY7nlLLkHYKwGDc3HBAylW6J9aBn9gT6sEpc9Flkyjdi4I7oUyzSjDOZt31poORDaBQEZoCa2z27dTCFYN6yvNNlHGz0QaxDS0txxuyff0Zr3xUpIb3wwCOnLqX2LZteIBZIiklxtyDrGfU82dH/Y+dJkdQOO2gPPlYW7GUiMU5BCIVjqI+13l6fb5EnkxsvNJ8OLevpb6x9eeMGsRLYnghxrOLF1HBPbcL8peRRmPqAHeyxZ3ED05jJloFDQgz3T5npPqiw6aqtvwnvOz1OuIEgnGhsBHwM3V827Qg0BNpC+m0TkFX0mY60RhmGWt1dUeRtBB4Ek1Mun9kbuJWtQBZo3CbrsdP6N0jsrxsFyLS329iueFEDuX6wguH9nYScTQvH18B2COnCquGO7l4=
X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4804; 6:3WyA6ntPUpg+hNUevK3KyZLNYin71JRmXMnIue6pczjxQg05f8sdsj5XvCPZA+8AUqXJJ7IIMhLPO6/fM1XFar1gkFG3EgLFEwFrB7smUr8uCmwWMDQGIJz3kV3NQwhhpapFZMySTZrLvHO90IdpB9/UJH99rH9QkN70x01Img1QlalYqR3TW09byRxl54GEN/iyRfRnHeQt5+QGZRqSnSTP7sZIchquyZofsCk1PZkYzZUoDqw9n/ZNrDVYKVkpffApY2kkn1IEeJTHxjyxqmR7ZDzmS7rBtwD5kyTqvUvTNo7iW3lTbi5BCXYKBxcobM7FvKF/ImgvcSL1S/IaykDlTQNUNprDDLFa3MuuUPyPIv74DaMAy0yBFiOBDA83co5zZmcIGRAOXSUoUU+Tk9gyRa0KgmOFCfdr7tXwmd8FRry8NsfMRpraIomY3Mnz2HdgCTFkikAqNddQen85kw==; 5:NP7XtjkpXfvBpP0PTHos6waB1V+E/xPt0kUmzYoReaB8w/gKielNTQH84OpF/uFwc1vEhGk3cuUSSOqmCxAoRJSmVk8UBByDr3tpwnnPlo4NL9Ujn40rcJpB9JWQfrMzaLCCX2a9NcC/rEEACvaRvB0g2btSc/chrzVmaHdruRgN6aZ7S+gLFdHuytSVSX2zeDG84siC3njvhTye2exYqA==; 7:/0P9tOajLArRzrjPo53rqu7WV8TjS5E6wKeXeXdljff1lx6g7teQ4gVrJhtP4YrZ6WenlNmNZhbuGMwPDlU+jb3FGr94iEnhjEQ9aKgCK8TZnKuLE2lhrKffqUlxl1Aj7Ee/NY1m7PsxpReO+0vcFA==
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2019 17:27:18.4486 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f6f14c4b-e062-47f6-f042-08d67d6a3298
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR01MB4804
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/RsEeDdJua72YjpiANQJCbEzRIXs>
Subject: Re: [Secdispatch] [Ace] EDHOC
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jan 2019 17:27:29 -0000
On Fri, Jan 18, 2019 at 11:54:58AM -0500, Richard Barnes wrote: > Let me provide some additional context. When the chairs and ADs discussed this in BKK, it seemed pretty clear that EDHOC is not within the current charter of ACE — after all, ACE is targeted at authentication and authorization, not key exchange. Since ACE would need to recharter to accept this work in any case, and because EDHOC overlapped with the interests of other working groups, it seemed to make sense to have the conversation in a broader venue. ACE's charter is ... messy. More below. > Göran: Your email starting this thread seems like an abbreviated summary of the past discussion of this draft. Since this is a new audience, it would be helpful if you could start from the underlying requirements (“we need an AKE with certain constraints”) and lay out why new protocol work is needed, vs. profiling existing protocols (as has been done, e.g., in DICE). There seem to be several interleaved issues at play, here, and I agree that some clear/consolidated background would be helpful. I particularly call out the security proof that has been presented elsewhere, which I think would be interesting to several readers (but I don't have the link handy). Some thoughts of my own... There is clear demand for a lightweight key-exchange protocol for use in IoT protocols, especially OSCORE. EDHOC has been around for a while, and even discussed in ACE with some frequency. That said, there are several reasons to prefer asking secdispatch to just calling for adoption in ACE directly, including but not limited to: (a) designing secure authenticated key exchange protocols is hard! It takes a lot of energy from smart people to design and analyze a protocol to have confidence that it is secure and fulfils the advertised functions. Starting from well-known/well-analyzed foundations like SIGMA is a great start, but hardly a guarantee of success. Secdispatch gets us some better visibility, and insight into where work can be done that will have sufficient expertise (both within and outside the IETF, as well as what has been done already vs. what remains to be done) to be confident in the result. (b) ACE has a pretty complicated charter, that seems to place restrictions on how it can adopt new protocol work without rechartering. We find things in the charter like "existing authentication and authorization protocols will be evaluated and used where applicable [...]. Some functionality, however, may not be available in existing protocols, in which case the solution may involve new protocol work." This would seem to require a clear criteria for how to determine whether or not existing technology is applicable, plus evidence that existing protocols do not meet the bar. In particular, "make the key exchange messages as small as possible" is not a clear criterion, as that would always argue for a new protocol over an existing one, as we come up with new ways to eke out space. (c) A clear and substantial difference between key exchange/handshake size between EDHOC and even minimized DLTS could be compelling enough for secdispatch to decide that the work is usable, and find an appropriate home, independently of the question of rechartering ACE and meeting the additional barrier described in the previous point. Jim and several others have done some good work looking into tabulating message overheads in various scenarios (e.g., https://www.diva-portal.org/smash/get/diva2:1156483/FULLTEXT01.pdf, https://jimsch.github.io/randomDrafts/draft-schaad-ace-tls-cbor-handshake.html) that will be helpful as we consider this topic. In addition to just comparing the byte count for handshake/key exhchange messages in various methods, it would probably also be good to think about things in terms of the constraints in the current ACE charter. That is, someone could (1) pick a (class of) device(s), (2) show that it has wide deployment/potential thereof, (3) give hard numbers about what it's (not) capable of, and (4) show that DTLS falls on the wrong side of that cutoff, using the handshake numbers we already have. In particular, I don't remember seeing anything touching on (3), previously. An analysis like this would not only give some context for interpreting the gap between EDHOC and DLTS, but could also be compelling in support of the need for the more lightweight solution. > If it would be helpful to keep this moving, we could certainly arrange a virtual > interim on this topic. That seems likely to be useful, though I suppose we should wait to see more indication that people would show up and have a productive discussion. -Ben
- [Secdispatch] EDHOC Göran Selander
- Re: [Secdispatch] EDHOC Kathleen Moriarty
- Re: [Secdispatch] EDHOC Göran Selander
- Re: [Secdispatch] EDHOC Richard Barnes
- Re: [Secdispatch] EDHOC Kathleen Moriarty
- Re: [Secdispatch] EDHOC Richard Barnes
- Re: [Secdispatch] EDHOC Kathleen Moriarty
- Re: [Secdispatch] [Ace] EDHOC Benjamin Kaduk
- Re: [Secdispatch] [Ace] EDHOC Roman Danyliw
- Re: [Secdispatch] EDHOC Roman Danyliw
- Re: [Secdispatch] [Ace] EDHOC Richard Barnes
- Re: [Secdispatch] [Ace] EDHOC Göran Selander
- Re: [Secdispatch] [Ace] EDHOC Göran Selander
- Re: [Secdispatch] [Ace] EDHOC Kathleen Moriarty
- Re: [Secdispatch] [Ace] EDHOC Kathleen Moriarty
- Re: [Secdispatch] [Ace] EDHOC Roman Danyliw
- Re: [Secdispatch] [Ace] EDHOC Kathleen Moriarty
- Re: [Secdispatch] [Ace] EDHOC Bret Jordan
- Re: [Secdispatch] [Ace] EDHOC Roman Danyliw
- Re: [Secdispatch] EDHOC Roman Danyliw