Re: [Secdispatch] [EXTERNAL]Re: Problem statement for post-quantum multi-algorithm PKI

"Panos Kampanakis (pkampana)" <pkampana@cisco.com> Fri, 13 September 2019 01:40 UTC

Return-Path: <pkampana@cisco.com>
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 F0D6B120154 for <secdispatch@ietfa.amsl.com>; Thu, 12 Sep 2019 18:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=OSahVxKN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=PRWezEqn
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 UMD1G-ul8Ctq for <secdispatch@ietfa.amsl.com>; Thu, 12 Sep 2019 18:40:53 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E2C120090 for <secdispatch@ietf.org>; Thu, 12 Sep 2019 18:40:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12132; q=dns/txt; s=iport; t=1568338853; x=1569548453; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=c8cGysbqrJV4V00TNcParR6cJoOKr0JKPX47wC9/UcU=; b=OSahVxKNh8F/FYkB0adgnz42QBfRWacQWqysX4iMgrHXIpxKk/CVTmLO 6gnGQpgnG5I8N4ep1xoR5zhLMP6xOmf3id0vIrtxJ8WntMXoFPWUQUFr1 ISXxIvDNyyYnG9Z6EIfO7FOr+xZCGYMowew74HTmLU5WygPu0Q6cZusoO A=;
IronPort-PHdr: 9a23:kJ84aRUy3Ptvb1rjWRLlnEvEKCTV8LGuZFwc94YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTFdE7KdehAk8GIiAAEz/IuTtankiH81HTFZj9lmwMFNeH4D1YFiB6nA=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ANBgDG8npd/4gNJK1jAxwBAQEEAQEHBAEBgWeBRSQsA21WIAQLKoQhg0cDimtNgg9+lnKCUgNUCQEBAQwBARgLCgIBAYFLgi9FAheCRiM4EwIDCQEBBAEBAQIBBgRthS4MhUoBAQEBAgEBARAREQwBASwMBAcCAgIBCBEEAQEBAgImAgICFBELFQgIAgQBEggMBweDAYFqAw4PAQIMoBUCgTiIYXOBMoJ9AQEFgQYBP0GDAxiCFgMGBYEHKIo1gUMYgUA/gRFGghc1PoJhAQECAQGBNhEYFQomgkQygiaMYC8BAoIunB1uCoIhhwGFDYkEgjSHQI8WhEaJOYgEkGoCBAIEBQIOAQEFgWkhN4EIEQhwFTuCbIFJeQwXFYM6hRSFCAE2c4EpjCuCVAEB
X-IronPort-AV: E=Sophos;i="5.64,499,1559520000"; d="scan'208";a="325199197"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Sep 2019 01:40:51 +0000
Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x8D1epN8031371 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Sep 2019 01:40:51 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Sep 2019 20:40:50 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Sep 2019 21:40:49 -0400
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 12 Sep 2019 20:40:49 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kYBnrLfKHuL2BOhMkojqqNVa2c5AZvU+Vcb1MZ9UTB3NBTVOfOUSQ9ykRNJ2L4vnOnJh6iKwTiOE7RFXvUvNX+2ftDhYJ2Slsrh1sufK8s08top865GeLBSkPGkLsAdi9H9xyCo7Fmw/5m6xwupDoriFRGfTKWU8qqTeBTHTjenDzBLrxO8oOiwxJdq9e1uUKI4qnGyp5STNcsN9H3hwPNvdGbNDvtDXM29b8aL7SNFuxPe04HMXZJH3EXNXDQIFMPx3K+9X5+q1NhwsAf0dlQsN5yvT0dvmGL8NMUexjE0PLSzqBdFHOHP/KkU6lM/AAOGNBIscvtLgW+7oE81UHw==
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=c8cGysbqrJV4V00TNcParR6cJoOKr0JKPX47wC9/UcU=; b=YUnvuJpxYnwLt+bCSYy3Tf26hGRK3obth1PHc2DrWoQl4Vxb1uIxPPKjU5nh/lbu8auLlM9JLzGCSAIDBtwZIhoRhQ4XKgFu2DvKzlXg1mM1kHWpIBacRzuAh4x8F5tq6r3d4F2X2msP3tYYoaTzKSToqEhtliYml5bRcF9CCLwq6Msl7QVDMRpTSf///9SAopGnNDQgKM62Nmmb6thGz6LpI9mY8RYv98Ik8YMFvjwHEJgUtKgqtz9suMMun2j1N42RA1RDCHwR1zQznPwkrZgouAsLDD3pYnW7bqlOJMHBuQ4vtl3HoVprt25i6gsUrNcgGN9RNIfh1C6aBeab5A==
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=c8cGysbqrJV4V00TNcParR6cJoOKr0JKPX47wC9/UcU=; b=PRWezEqnRTqZx1KBPNc9CzAkz5B0kvGPekVq6Rej6WmHgarHOTzTY2evXbsFqJYTuvcuTIQMHNEPjQ4CVMd+RWrsTTMmN/nNOxlFeA9NskvNNYhWXzjspg2RXr1G9i4lstDypL/kc4Iws03CM8ArVYxrdh2NgMM1NMOxat0KrGg=
Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2625.namprd11.prod.outlook.com (52.135.242.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.17; Fri, 13 Sep 2019 01:40:48 +0000
Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::20df:b3df:537d:fd20]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::20df:b3df:537d:fd20%7]) with mapi id 15.20.2263.016; Fri, 13 Sep 2019 01:40:48 +0000
From: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
To: Mike Ounsworth <Mike.Ounsworth@entrustdatacard.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>, "Dr. Pala" <madwolf@openca.org>, "secdispatch@ietf.org" <secdispatch@ietf.org>
Thread-Topic: [Secdispatch] [EXTERNAL]Re: Problem statement for post-quantum multi-algorithm PKI
Thread-Index: AQHVaaLo3tFFwI2ExUmqy34JmS70Haco1O7w
Date: Fri, 13 Sep 2019 01:40:47 +0000
Message-ID: <BN7PR11MB25476A57B5E9F3C3E151908AC9B30@BN7PR11MB2547.namprd11.prod.outlook.com>
References: <a2e32c33-8589-f3fb-97e5-c5977dfc64b4@openca.org> <BL0PR11MB317285DF599EC58CCF26FD5EC1B00@BL0PR11MB3172.namprd11.prod.outlook.com> <87ef491b-0faa-06b4-e0f4-61673cba3914@cs.tcd.ie> <aaf03217f920480589eb396a6fbf6e43@PMSPEX05.corporate.datacard.com>
In-Reply-To: <aaf03217f920480589eb396a6fbf6e43@PMSPEX05.corporate.datacard.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com;
x-originating-ip: [2001:420:c0c4:1005::c3]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ea89238a-4709-4ba7-17c4-08d737eb66f3
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2625;
x-ms-traffictypediagnostic: BN7PR11MB2625:
x-ms-exchange-purlcount: 4
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BN7PR11MB262587EED84B1C9033DC7DB3C9B30@BN7PR11MB2625.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0159AC2B97
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(366004)(346002)(136003)(396003)(189003)(199004)(13464003)(2501003)(14454004)(446003)(6506007)(46003)(11346002)(76116006)(66556008)(6246003)(52536014)(53546011)(66476007)(561944003)(33656002)(76176011)(8936002)(2906002)(64756008)(966005)(186003)(66446008)(102836004)(66946007)(7696005)(53936002)(9686003)(256004)(8676002)(305945005)(5660300002)(478600001)(71200400001)(486006)(14444005)(6306002)(81166006)(55016002)(81156014)(99286004)(25786009)(6436002)(229853002)(74316002)(476003)(316002)(86362001)(45080400002)(110136005)(6116002)(71190400001)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2625; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: /7qshrMjpNWtmJIxHXzVNNxJQ1jXqBvL72poIm5wCFhGgGwnO1ss0LOK3S6A3/ujx/K6cNdbbf3YwEn55NGxQCpbZfcdE1lcgPrzILKDeXsJyQl2mUHQ1HxdcyiGq5E2MfOS3A6h/Scq2CTGzXVKxqTu7vfvpRaGwYQZ6fGwDvSLla1TAI4NamKQrVTYs7KTu7RTUTRCXUcwMso2wBfsADAEbnEYC4Dg8S/r1j5ROTFvK75OlGe0ceLdy6Re9RpsHsKXfhj+D64L0O+CtEv+MMLvxHmAXGGtK23g25ujei5TC2mK827YZbmAW09SWCUTsx/54kfQawWmQJIsHB/G6za89+j/IsO7mDdQLfUPI3RytFWlb0tlyH0Q5UxcXX+5Cq+z1QatBIZcy+qF/cMK+7mdioEbDUfpSegF5j/9zyw=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ea89238a-4709-4ba7-17c4-08d737eb66f3
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2019 01:40:47.6736 (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: 8mRVz/6sUjtz2UovHsRofACnp+nY+9FuOUu+MmW94jN4qUQUizc4pUuwC4DF7Iy2DpHUl9Mtbl6eB2zI+NfKbA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2625
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/cZQ3F5gQIBj58v5zQ4MuOM5qils>
Subject: Re: [Secdispatch] [EXTERNAL]Re: Problem statement for post-quantum multi-algorithm PKI
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, 13 Sep 2019 01:40:56 -0000

> I also think it seems a bit mad to consider x.509 as the main thing to consider so I'm not at all keen on seeing this problem space as being one where all we need is yet another sticking plaster for x.509. That said, I do get that people invested in x.509-based PKI may reasonably prefer less-change to more-change, I just think we may be sad if we miss another opportunity to move on leaving behind some of this 1980's baggage.

X.509-based PKI may reasonably prefer less-change to more-change. That would be almost all usecases. I am not sure I can realistically envision a PQ world that does authentication completely differently than how the world has been doing it for decades. 

Based on detailed experiments (and a paper to be published soon) I am convinced that two of the PQ signature candidates in the NIST PQ competition could be viable for the way PKIX works today. And based on reports I have seen from Google, Cloudflare, AWS and Microsoft and based on the NIST KEM algorithm candidates characteristics there are key exchange options that could play ok in almost all usecases of secure tunnels today. 

Before we boil the ocean although it has been boiled already, we need to be sure it needs boiling. I am not convinced it does. 

Panos

-----Original Message-----
From: Secdispatch <secdispatch-bounces@ietf.org> On Behalf Of Mike Ounsworth
Sent: Thursday, September 12, 2019 3:47 PM
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>; Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com>; Dr. Pala <madwolf@openca.org>; secdispatch@ietf.org
Subject: Re: [Secdispatch] [EXTERNAL]Re: Problem statement for post-quantum multi-algorithm PKI

Hi Stephen,

That's an exciting solution space that's orthogonal to the ones that I wrote up in my Problem Statement draft. Do you have some concretes on what such a "replace X.509" proposal might look like?

I suggest that even with full support for such a proposal, it would still make sense to standardize a "less change to the 1980s baggage" so that existing systems have something they can do in the short term. Speaking as a PKI vendor, this is starting to be an uncomfortably hot issue with our customers who are deploying 20 year lifetime devices and want post-quantum protection on them like now with like no code changes.

So exactly as you say "people invested in x.509-based PKI may reasonably prefer less-change to more-change" :P

- - -
Mike Ounsworth | Office: +1 (613) 270-2873

-----Original Message-----
From: Secdispatch <secdispatch-bounces@ietf.org> On Behalf Of Stephen Farrell
Sent: Thursday, September 12, 2019 2:28 PM
To: Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com>; Dr. Pala <madwolf@openca.org>; secdispatch@ietf.org
Subject: [EXTERNAL]Re: [Secdispatch] Problem statement for post-quantum multi-algorithm PKI


Hiya,

On 12/09/2019 20:08, Scott Fluhrer (sfluhrer) wrote:
> I agree that this is an important problem to solve.

Depending, on the "this," I agree or disagree:-)

Discussion of how to get what PKI offers in a world where current asymmetric algorithms might be weak and where quantum-resistant, but new, algorithms are emerging, is an excellent topic to start to consider.

I also think it seems a bit mad to consider x.509 as the main thing to consider so I'm not at all keen on seeing this problem space as being one where all we need is yet another sticking plaster for x.509. That said, I do get that people invested in x.509-based PKI may reasonably prefer less-change to more-change, I just think we may be sad if we miss another opportunity to move on leaving behind some of this 1980's baggage.

Cheers,
S.

> 
> One might think we have plenty of time, given that Real Quantum 
> Computers are, more than likely, more than 10 years away, and even 
> once you have one, you cannot use your Quantum Computer to break the 
> authentication of recorded conversations.
> 
> On the other hand, authentication also brings in additional issues; 
> instead of having a two party system (where as long as both the client 
> and the server support a postquantum algorithm, they can negotiate 
> it), we now have an (at least) three party system, the client, the 
> server, and the CA.  this additional party makes the upgrade path more 
> complicated.  So, while we have more time, we may need it.
> 
> I don’t think it’s too early to start thinking about the issues..
> 
> From: Secdispatch <secdispatch-bounces@ietf.org> On Behalf Of Dr.
> Pala Sent: Thursday, September 12, 2019 10:39 AM To:
> secdispatch@ietf.org Subject: Re: [Secdispatch] Problem statement for 
> post-quantum multi-algorithm PKI
> 
> 
> Hi SecDispatch, Mike,
> 
> Our industry (Cable) is working on this problem already - some of our 
> members have started investigating few things in the post-quantum 
> field and in particular how to protect our PKIs in this uncertain 
> environment.
> 
> With few billions certificates issued across the industry, we heavily 
> rely on certificates for device authentication and, therefore, we need 
> to work on a solution today.
> 
> For us, the use of Composite Crypto is quite an interesting path to 
> pursue because it provides an easy way to protect today our PKIs 
> against the factorization threat (not only certificates, but all the 
> data structures for PKIX) thus allowing to verify the authentication 
> with Post-Quantum algorithms when we will need to make the switch 
> (deferred Algorithm Agility).
> 
> We intend to support this idea and actively deploy it for our PKIs and 
> eventually expand the adoption of this approach in other environments 
> we are engaged in (e.g., medical devices, cellular networks, WiFi 
> Alliance and WBA, etc.)
> 
> Looking forward to find a good home for this project within the IETF
> - a simple but powerful tool for our "PKI toolboxes"
> 
> Cheers, Max
> 
> 
> 
> Hi SecDispatch,
> 
> 
> 
> This got bounced here from LAMPS because the scope is potentially more 
> than a "limited" pkix change, and because this needs multi-WG 
> visibility to decide on a category of solution.
> 
> 
> 
> 
> 
> 
> 
> Background / history
> 
> --------------------
> 
> 
> 
> The Post-Quantum community (for example, surrounding the NIST PQC 
> competition), is pushing for "hybridized" crypto that combines RSA/ECC 
> with new primitives in order to hedge our bets against both quantum 
> adversaries, and also algorithmic / mathematical breaks of the new 
> primitives.
> 
> 
> 
> 
> 
> A year and a half ago, a draft was put to LAMPS for putting PQ public 
> key and signatures into X.509v3 extensions. This draft has been 
> allowed to expire, but is being pursued at the ITU.
> 
> https://datatracker.ietf.org/doc/draft-truskovsky-lamps-pq-hybrid-x509
> /
>
> 
> 
> 
> 
> 
> Earlier this year, a new draft was put to LAMPS for defining 
> "composite" public key and signature algorithms that, essentially, 
> concatenate multiple crypto algorithms into a single key or signature 
> octet string. This draft stalled in LAMPS over whether it is the 
> correct overall approach.
> 
> https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/
> 
> 
> 
> 
> 
> Now I'm taking a step back and submitting a draft that acts as a 
> semi-formal problem statement, and an overview of the three main 
> categories of solutions.
> 
> https://datatracker.ietf.org/doc/draft-pq-pkix-problem-statement/
> 
> 
> 
> 
> 
> 
> 
> 
> 
> My Opinion
> 
> ----------
> 
> 
> 
> Personally, I'm fairly agnostic to the chosen solution, but feel that 
> we need some kind of standard(s) around the post-quantum transition 
> for certificates and PKI. Personally, I feel that Composite is mature 
> enough as an idea to standardize as a tool in our toolbox for contexts 
> where it makes sense, even if a different mechanism is preferred for 
> TLS and IPSEC/IKE.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Requested action from SECDISPATCH
> 
> ---------------------------------
> 
> 
> 
> 1. Feedback on the problem statement draft.
> https://datatracker.ietf.org/doc/draft-pq-pkix-problem-statement/
> 
> 
> 
> 2. Discussion of how to progress this.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> PS I'm a new IETF'er, please be gentle :P
> 
> 
> 
> Thanks,
> 
> - - -
> 
> Mike Ounsworth | Software Security Architect
> 
> Entrust Datacard
> 
> -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director [OpenCA 
> Logo]
> 
> 
> _______________________________________________ Secdispatch mailing 
> list Secdispatch@ietf.org 
> https://www.ietf.org/mailman/listinfo/secdispatch
> 
_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch