From nobody Wed Nov 10 10:51:02 2021 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245453A1290 for ; Wed, 10 Nov 2021 10:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.89 X-Spam-Level: X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_GOV_DKIM_AU=-1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uwe.nsa.gov 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 shQj3bjk_1zw for ; Wed, 10 Nov 2021 10:50:56 -0800 (PST) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl0gcc02on2061b.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d05::61b]) (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 AF3763A128C for ; Wed, 10 Nov 2021 10:50:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i+Rgh+faRTMlJ8e1HxSw5OFCJm91d4taGfJYuG7hhyuAD/EUFbuyt7tjs3HQQ8WR2cI+4rCCkr6fp+xbG9A10Sjer3g/c/eR0o5zSpp0SQTiycDX9aP+99QIUpy7agCm6ggYfHuWohfAm6DsBaTr10SlyihEfCbeQ9xeVxzqWFr3845L1jf1YV6Y1BD4uuh6YyjV9g2+MDfXE6Ox936br5xFTMwFGeHAaK3QTfV9Q5IZvXkOLrOab6k9/XXaTZe7zzYfwBrtMXGQyyvERBbSSkkavZqpK4+Kc8a4JNG0bWypUtHf3pPO8BhVM6WIAQgXSVVUfMQ66C99ZDuMEU7YVg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rNGDhLWgzdoRqCeajB+FNvpWZk5HAsqvmDuczcBnZX0=; b=S2EQ4sdczo4NxvnWhsNHzunY3yh7Gfux846hBI+si4D4BEOGG3lX7LsgqV7C6KKapOdYujdzuTpF/ULGkzEH0yVKFUs/AEE/n7Lqz9mi46AX5o97xakoWu0kpRnzFb7Ia/qhsa1/cxF7ahP6eB/eI6FQ6N8GeApQGP932nczko7XghDtCz0e3pUNj3pS+mPMr7rcGpjYLiZqrC2UeZfhXkdyT/1koZR0VRqCcjpVYzSq+DivdR68IcV1umdCmuqJyCiWbP+2y5fom1kfiO4YV3AModZGYSuD3p8xYMGUrbiFLFq471HgLmte6w1E8J3WrikwvSWAWaXP+7gmd5XuFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uwe.nsa.gov; dmarc=pass action=none header.from=uwe.nsa.gov; dkim=pass header.d=uwe.nsa.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uwe.nsa.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rNGDhLWgzdoRqCeajB+FNvpWZk5HAsqvmDuczcBnZX0=; b=YREUUHZs76bMCRehT8Rc6EnZMEsllIxfvX91CQqLYivC39jULPPE5wJGMFXUUasG1dkwBVZbqkwyDGcjkZWB/Shwwomn+QN9dAP5NmhKvuBn5LYwNIVRqyrySoKXVh3xkDfNLKLaJuld6e8DqdQEZzV5s6Fowq4vY3/AqSpYWO26W+dn179F4sXTCgoxYv8Gxj1UoSUyDoXXB+9PNpGzMBQyWeII7VGKfjfB3StNSPh+Q5ToHfdq6AyxToWojUFwQ0GUleHOhnPPn9vCLWX1V2uvSS/mmbbUMgrm2D6qwpXKPIGmhnteBTSKXRKJnPBP9Kw/b8UTtTmZiXcIbSqKVQ== Received: from SA0PR09MB7241.namprd09.prod.outlook.com (2603:10b6:806:7a::24) by SA0PR09MB7081.namprd09.prod.outlook.com (2603:10b6:806:7d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.16; Wed, 10 Nov 2021 18:50:48 +0000 Received: from SA0PR09MB7241.namprd09.prod.outlook.com ([fe80::bdc1:81d4:2722:39bf]) by SA0PR09MB7241.namprd09.prod.outlook.com ([fe80::bdc1:81d4:2722:39bf%7]) with mapi id 15.20.4690.016; Wed, 10 Nov 2021 18:50:48 +0000 From: "aebecke@uwe.nsa.gov" To: Mike Ounsworth , LAMPS WG Thread-Topic: Hybrid-for-the-sake-of-security, and Composite vs Non-Composite Thread-Index: AdfVsjPJvhmRyNYwSd+PO+jOYyc/rAArT1E3 Date: Wed, 10 Nov 2021 18:50:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: d7802686-f4fd-d427-2bfb-ba7c386a6fa1 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=uwe.nsa.gov; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c7bb5ad6-d583-4295-29e5-08d9a47b0308 x-ms-traffictypediagnostic: SA0PR09MB7081: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9PEOrKI8wi+oP54849BWdOj35XgP9Fx6sxIEkjy3ADWQVWI3zeEekK/QDd2CsgcGcqtN53gN00WjLJuceNSq2gUjnqZpgnpNB3lrYrosIWubR3ELIWiQKpejjez1BRVHG447uVrNhfWNHNXcNRziGAC0hJwX07Wcg/TeSn0uLc6PMIOHEHx6u/2oonvgHUqpv0FfGQ9DoCqP1WyhnP6oOCi1hOJ3OcZyjbQ+uj8ugR+cE3dlegt4kUt1YwNNPTNUv7kjkHs+Y2TLAhkTTZ/f9c59jigmjWnq7p5ghLgCbNn6pbThk8M7ccoJyjA+Xxi4lynIT9wfF4v0J0jxkWGBkIBpaKYM6Twn1HvaE5gw5xVegYsktYw0FGgV/k9lYaa4TvSQT+6xyoaicEcK9yZ2w4M+TemTxbtdLHa4OGboOWPjyoWC9AupjQ1BesrarQWGf9kSde578AL6Hcuok0o3HBGOpm1EAs2LCvJBvhHjJ7oUFYnV41W5ffxtj93vPing3Mub8Z7lrsVC/UuhHmuTANsnfhLxo0WtJs6tYhLGeJghDD/j04ZNYkMNZ+j7NyaMtjbM6SVTB6Q/+4RwcY5fuGxgx7UOx01U1FiAw0msECKEowKFcyOsNyDOtijGdLy7yXEPFb6kN8Z4e8pqgKV/2Op/a9jZtyAjaVckHo0sPxArBR9gemT44MwhvIXzY/dQBCRhbhaboVLbv2Vez5jgDYoRAnBNWLOVZeVfFZOzBZ8VMD+Ylr2L01JfFyW5MJfLYTxicYcko7iT+49IuaTesQ/ZOYd7pnKput2+u9G91t4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR09MB7241.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(82960400001)(45080400002)(5660300002)(7696005)(186003)(15650500001)(166002)(26005)(19627405001)(52536014)(8676002)(76116006)(91956017)(55016002)(6506007)(53546011)(66946007)(8936002)(9686003)(83380400001)(110136005)(66556008)(64756008)(66446008)(66476007)(508600001)(122000001)(38100700002)(2906002)(71200400001)(316002)(66574015)(38070700005)(86362001)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?7kBa2TTAENMTP1ZibzLV43egJsEdKOOjQa72lCZ4G6VgmmHztofMM5x4?= =?Windows-1252?Q?0/NZDt+/dk0DTi/2OdbojupWq7kzZPpkW4YxaWgCXiM40t6YA5NeFAYl?= =?Windows-1252?Q?BSfvbSe72x/hrpxuf5Lfs8DvsbyMM2HnNdbrsesoa6JKBpwmDEdxp05g?= =?Windows-1252?Q?U94mZf/aPGtT/zNmMU3VDf/XN+aX8QO6Fjdp1G2kekLiIXuAEG2sXbyR?= =?Windows-1252?Q?u6KQsbX/u1d0Zrvk+Zg0SoCe07itk9M2pJiTuYixAlBZFfSLKvOZ+QSY?= =?Windows-1252?Q?8g243D3mprhgfEPp1rFSxgYtogtJ1f21Jcvh44GUlRhT+yFB9pW2XELS?= =?Windows-1252?Q?HaR//A71KvNIF8Y9BhPHdllQSZQxBTsCHIhWFIsxKZcUSOQ/QIvhQhlJ?= =?Windows-1252?Q?P6Hyz/JfizaWUJ+lc5IuNlwa6epAUB5mbW7bg0aMpm4voXQfw77bxRSp?= =?Windows-1252?Q?Q55zoH4BAodKjL4MJJahy43d8/Nj2VZFULRyLm+uFFDLXOH7h6dQvi4p?= =?Windows-1252?Q?/etVd9777r2a140c7iKF8ZAOoiQ9mcOO/J+z6aAvT3o6p0d5DsVl8hg+?= =?Windows-1252?Q?DEEfOeUD5B2dluyK3oW9mIH6XZ9xzLSp3uJSFvY0GMCebPkVi5ZnTJhs?= =?Windows-1252?Q?5EVjyEQilZEfTQ0onLgNYA4JOHAYtc96o3mThu72DJAJWjh5SZtpOiuE?= =?Windows-1252?Q?Zakhc49EK0gBckkKrkq1frSpUxRGdm74Yw89bo1G9DuX6Kk22qx0uMIv?= =?Windows-1252?Q?GT3jtm+MVM9BMfmWmmauyeeOcG5rkK21AWYhSGuHtl9wFkAfTqvuB73b?= =?Windows-1252?Q?Bn8Iie2sszHkGRazS+8yOFou4CzdzhFCGEN7Gozhqd9Z8DrWOHMIiO91?= =?Windows-1252?Q?V2jI7lPF2ZpLycRtEzzyQLCI4TCcZUaS1DWx4wQS96Dx1M3WIuCsqQVB?= =?Windows-1252?Q?wvZ2Ltqxe3wk/ua4MyPfrxs4XhUxPYmMQ5KnNPPn7PBmoNi2KLqKK1Ss?= =?Windows-1252?Q?hZiah96J9G9bGIMyI2pxMVj+OGQcMnZa7VjYMTGU5j2KJYGHag+k0l8G?= =?Windows-1252?Q?ZJ9q/JZdszZ0aZolRnr/yKjwZuQnwYtwuMtOVvjeJPWYNcLjPSFMaMpf?= =?Windows-1252?Q?z5w4oCSynnULXDB8HZCdMu/mCkbNZgExqblfgoZjAxAm/+Me/10xvECd?= =?Windows-1252?Q?UEtRWYMyuk68C/FYGEVs3gQCWvmckAuZQHiNQwvBb2/RHv9rflGmQGy3?= =?Windows-1252?Q?r9al/izfi3+Yp42B4Ka1E6LZZAOxbxnVpDygHdHioCqm6rsoMZ7VuRIt?= =?Windows-1252?Q?3U4+2PTOdiE/4/5tInlHXndzemyDgtlEzF7tDcVYykfDEUsLINxp2b4n?= =?Windows-1252?Q?a4MPJIZVngJMraE5/vhBq6IqGMAFlgdilgk=3D?= Content-Type: multipart/alternative; boundary="_000_SA0PR09MB72412AF3E7DDBF2EA66179EBF1939SA0PR09MB7241namp_" MIME-Version: 1.0 X-OriginatorOrg: uwe.nsa.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA0PR09MB7241.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c7bb5ad6-d583-4295-29e5-08d9a47b0308 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2021 18:50:48.7917 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d61e9a6f-fc16-4f84-8a3e-6eeff33e136b X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR09MB7081 Archived-At: Subject: Re: [lamps] Hybrid-for-the-sake-of-security, and Composite vs Non-Composite X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2021 18:51:01 -0000 --_000_SA0PR09MB72412AF3E7DDBF2EA66179EBF1939SA0PR09MB7241namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Mike! Great to hear your feedback! The quantum-resistant algorithms resulting fro= m the NIST program are well-vetted, and NSA has no concerns in this area re= garding their security. Based on our analysis and experience, NSA has decid= ed that the NSS path forward is toward strictly-PQ solutions, and thus we r= equire flexibility in the architecture of hybrid protocols. We understand o= ther users may have security-based concerns that are satisfied by using hyb= rid solutions, but we believe there to be no difference between the securit= y of composite vs. non-composite solutions. Non-composite solutions can sat= isfy those concerns, as well as provide built-in interoperability with stri= ctly-PQ solutions. As you pointed out, implementation errors in current cryptographic algorith= ms are quite common, and the statistics you provided on CVEs for 2020 are t= elling that issue is prevalent even today, with well-established algorithms= . As such, if implementation errors are your largest concern, doubling up o= n algorithms introduces a larger surface for error. I will emphasize that our non-composite approach does propose changes to ex= isting protocol logic; however, in most instances this is primarily a matte= r of duplicating existing processes, and not introducing entirely new struc= ture. There will most certainly be varied levels of readiness to PQ-migrati= on, thus a strong framework that allows for strictly-PQ implementations and= inherits straightforward backwards and forwards compatibility is necessary= . Essentially, there should not be a conflict between migratability and cry= ptographic strength; we want to ensure a flexible migration environment tha= t maintains crypto-agility. To your question regarding use of composite and non-composite certs togethe= r (i.e., EC and PQ in the PQ cert)- it is an essential characteristic of a = non-composite approach that the traditional and PQ entities are distinct fr= om one another. The idea is not to alter the existing structure of the indi= vidual certs, and avoid adding complexity or altering the signing or valida= tion process (other than the required alterations for a PQ signature that b= oth composite and non-composite approaches will require). If the protocol i= s validating both certs, there is no need to include a traditional algorith= m in the PQ cert, as it has already been included via a separate certificat= e. Regarding offline protocols, we agree, and we hope others will also partici= pate! Cheers! Alie ----- Alison Becker, PhD Center for Cybersecurity Standards National Security Agency ________________________________ From: Spasm on behalf of Mike Ounsworth Sent: Tuesday, November 9, 2021 4:38 PM To: LAMPS WG Subject: [lamps] Hybrid-for-the-sake-of-security, and Composite vs Non-Comp= osite Thanks Dr. Alison Becker (Ali?) for the presentation on your framework. It= =92s great to have some independent analysis here to guide the design discu= ssions! Point #1: Risk model: First, I=92m struggling to understand the risk model that underpins your se= cond slide, which gives the conclusion that hybrid is not for security; onl= y for backwards compatibility. Could you please expand on how you reached that conclusion? I=92ll explain = how we got to the conclusion that Hybrid-for-the-sake-of-security is highly= desirable. I understand that by the end of the NIST =93competition=94, theoretical con= fidence in the winning algorithms will be high. Theoretically, in a perfect= world well vetted algorithms won=92t contain any overlooked weaknesses, an= d standards bodies will produce precise specifications that everyone will i= mplement perfectly. In the real world there were 18,000 CVEs filed in 2020 = because somebody overlooked something in an implementation. Once there are = FIPS specs for the PQ algorithms, how many open and closed source implement= ations will we be written? How many of those will have buffer overflows or = timing-invariance issues or other bugs that can lead to key leakage, plaint= ext leakage, signature forgery, etc? How many XMSS or LMS implementations w= ill have race-conditions or poorly thought-out backup and restore procedure= s that lead to private state re-use in some bizarre corner-case? How long u= ntil we stop seeing new CVEs in both PQ crypto implementations and applicat= ions that (mis)use them? If Bleichenbacher=92s oracle attack against RSA PK= CS#1 v1.5 padding can provide a historical example, that was published in 1= 998, and 19 years later, a new research effort (https://robotattack.org) found a pile of implementations that were still vulnerable b= ecause implementors (and many of the big-name ones) didn=92t follow the spe= c perfectly. I guess I=92m arguing that Hybrid-for-the-sake-of-security would increase t= he chances of closed- and open-source PQ implementations getting the maturi= ng time the time they need without a devastating breach in the meantime. Ex= pect bugs, design in some defense-in-depth to give us time to patch the bug= s that come up. I think dual signatures and hybrid encryption is the optima= l place to build in that resiliency. And yes, I would propose applying this equally across PQ algorithms; just b= ecause we like hash functions doesn=92t mean that SPHINCS+ is immune from i= mplementation error, and strong hybrid modes would also mitigate the conseq= uences of bungling the state-management of your XMSS private key; yes if yo= u produced two signatures with the same state then you would still need to = revoke it for key compromise, but with a layer of EC, you would have days = =96 weeks to safely notice and take action as opposed to hours. I also understand that backwards compatibility, ease-of-migration, ease-of-= adoption, etc are in fact security goals themselves (fewer reasons to stay = on the old broken stuff), so in a conflict between migratibility and crypto= graphic strength, migratibility wins. But I don=92t believe there is a conf= lict here; I don=92t believe it=92s Composite VS Multi-Cert; I believe the = two play harmoniously together, which brings me to the next point. Point #2: Are composite and multi-cert competing or complementary in TLS an= d IKE? I would like to clarify what I (speaking for myself, not necessarily my co-= authors) see as the posture for composite public keys, signatures, and cont= ent encryption: The point is well-taken that negotiated protocols want full flexibility to = negotiate and don=92t want to send large PQ keys to legacy clients who won= =92t use them. Really though, nobody is proposing doing that (at least not = since draft-truskovsky-lamps-pq-hybrid-x509, which was abandoned in 2018). I think we=92re all imagining a similar thing where TLS servers are provisi= oned with multiple certs, for example an RSA cert chain + a PQ cert chain; = runtime negotiation gets to choose to use one or the other or both. The que= stion is whether the PQ cert chain should itself be composite, ie PQ :=3D {= EC, PQ} to protect against the cryptologic and implementation risks that I = outline above until we have confidence in both the algorithms and their imp= lementations. So in my mind composite and multi-cert are complementary: do multi-cert for= backwards compatibility, and bury an Ed25519 inside your PQ cert for good = measure. Given the size and CPU of most PQ algs, you won=92t even notice it= =92s there. Point #3: Offline protocols As mentioned in the LAMPS meeting, I would love to see your analysis extend= ed to cover offline protocols (aka non-negotiated, or what I think Russ cal= led =93Sign-and-store=94 or =93encrypt-and-store=94). I propose that good s= ubjects for this analysis are: the Microsoft X.509-based code-signing infra= structure, document (PDF) signing infrastructures, and S/MIME infrastructur= es. For this section I=92m going to assume a risk model that a code-signed bina= ry or a signed/encrypted document has a security shelf-life of 30 years, du= ring which time we can expect RSA to fall to quantum computers, or the part= icular PQ alg used to have a bug found in it, or both (though the =93both= =94 case is a bit hopeless unless you want to go to hybrid models with more= than 2 algs). Research / design questions for offline use-cases: In the signing case, how does a recipient know that there should be two sig= natures when it only sees one? (aka stripping attacks, assuming one alg is = vulnerable to forgery attacks due to the above risks). With PQ hybrid content-encryption (I hate that PQ has overloaded this term.= . maybe =93multi-key encryption=94 would be better?), the big risk I see is= that it is not the key-holder who gets to decide security, but the sender.= Ex.: it is not responsible-disclosure@megacorp.com that gets to choose how its encryption public keys are= used, but rather the mail client that whitehat.dude@gmail.com used to encrypt the super-secret email. In fact, the re= cipient doesn=92t even know that somebody is using their keys until the enc= rypted content has already crossed the internet. If we=92re proposing a mul= ti-cert model here, then how does the sender know that the recipient actual= ly has two certificates that are expected be used together? You could imagi= ne cross-linking certs (or CAs) with some kind of extension, but A) nobody,= as of yet, has proposed a spec for that, and B) that would count as new ce= rt verification logic, which I think goes against your =93Non-Composite PRO= : Computational processes remain unchanged (but perhaps multiple iterations= )=94. I would love to see your analysis framework extended to cover these sorts o= f long shelf-life non-negotiated protocols because these are the ones that = I feel benefit the most from composite certs. --- Mike Ounsworth Software Security Architect, Entrust Any email and files/attachments transmitted with it are confidential and ar= e intended solely for the use of the individual or entity to whom they are = addressed. If this message has been sent to you in error, you must not copy= , distribute or disclose of the information it contains. Please notify Entr= ust immediately and delete the message from your system. --_000_SA0PR09MB72412AF3E7DDBF2EA66179EBF1939SA0PR09MB7241namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Mike! 

Great to hear your feedback! The quantum-resistant algorithms resulting from the NIST program are well-vett= ed, and NSA has no concerns in this area regarding their security. Based on our analysis and = experience, NSA has decided&nb= sp;that the NSS path forward is toward strictly-PQ s= olutions, and thus we require flexibility in the architecture of hybrid protocols. We understand other users ma= y have security-based concerns that are satisfied=  by using hybrid solutions, but we believe there to be no difference between the security o= f composite vs. non-composite solutions. Non-compo= site solutions can satisfy those concerns, as well as provide built-in interoperability with strictly-PQ = solutions. 


As you pointed out, implementation errors in current cryptographic algorithms= are quite common, and the statistics you provided on CVEs for 2020 are tel= ling that issue is prevalent even today, with well-established algorithms. = As such, if implementation errors are your largest concern, doubling up on algorithms introduces a larger su= rface for error.  


I will emphasize that our non-composite approach does propose changes to exi= sting protocol logic; however, in most instances this is primarily a matter of duplicating existing proce= sses, and not introducing entirely new structure. There will most certainly= be varied levels of readiness to PQ-migration, thus a strong framework tha= t allows for strictly-PQ implementations and inherits straightforward backwards and forwards compatibility is neces= sary. Essentially, there should not be a conflict between migratability and cryptographic strength; we want to ensure a flexible migration environment= that maintains crypto-agility.  


To your question regarding use of composite and non-composite certs together<= /span> (i.e., EC and PQ in the PQ cert)- it is an essential characteristic of a non-composite approach that the tra= ditional and PQ entities are distinct from one another. The idea is&n= bsp;not to alter the existing structure of the individual certs, <= span class=3D"NormalTextRun SCXW195047569 BCX8" style=3D"margin:0px;user-se= lect:text">and avoid adding complexity or altering the signing or validation process (other than the required alterations for a PQ signature= that both composite and non-composite approaches will require). If = the protocol is validating both certs, there is no need to include a traditional algorithm in the PQ cert, as it has al= ready been included via a separate certificate.  


Regarding offline protocols, we agree, and we hope others will also participate!&nb= sp;


Cheers! 
Alie 

-----
Alison Becker, PhD 
Center for Cybersecurity Standards 
National Security Agency

From: Spasm <spasm-bounc= es@ietf.org> on behalf of Mike Ounsworth <Mike.Ounsworth=3D40entrust.= com@dmarc.ietf.org>
Sent: Tuesday, November 9, 2021 4:38 PM
To: LAMPS WG <spasm@ietf.org>
Subject: [lamps] Hybrid-for-the-sake-of-security, and Composite vs N= on-Composite
 

Thanks Dr. Alison Becker (Ali?) for the presentation on your framework. It= =92s great to have some independent analysis here to guide the design discu= ssions!

 

 

 

 

Point #1: Risk model:

 

First, I=92m struggling to understand the risk model that underpins your se= cond slide, which gives the conclusion that hybrid is not for security; onl= y for backwards compatibility.

Could you please expand on how you reached that conclusion? I=92ll explain = how we got to the conclusion that Hybrid-for-the-sake-of-security is highly= desirable.

 

I understand that by the end of the NIST =93competition=94, theoretical con= fidence in the winning algorithms will be high. Theoretically, in a perfect= world well vetted algorithms won=92t contain any overlooked weaknesses, an= d standards bodies will produce precise specifications that everyone will implement perfectly. In the real world t= here were 18,000 CVEs filed in 2020 because somebody overlooked something i= n an implementation. Once there are FIPS specs for the PQ algorithms, how m= any open and closed source implementations will we be written? How many of those will have buffer overflows or timing= -invariance issues or other bugs that can lead to key leakage, plaintext le= akage, signature forgery, etc? How many XMSS or LMS implementations will ha= ve race-conditions or poorly thought-out backup and restore procedures that lead to private state re-use in some bi= zarre corner-case? How long until we stop seeing new CVEs in both PQ crypto= implementations and applications that (mis)use them? If Bleichenbacher=92s= oracle attack against RSA PKCS#1 v1.5 padding can provide a historical example, that was published in 1998,= and 19 years later, a new research effort (https://robotattack.org) found a pile of implementations that were still vulnerable because impleme= ntors (and many of the big-name ones) didn=92t follow the spec perfectly.

 

I guess I=92m arguing that Hybrid-for-the-sake-of-security would increase t= he chances of closed- and open-source PQ implementations getting the maturi= ng time the time they need without a devastating breach in the meantime. Ex= pect bugs, design in some defense-in-depth to give us time to patch the bugs that come up. I think dual signatures an= d hybrid encryption is the optimal place to build in that resiliency.

And yes, I would propose applying this equally across PQ algorithms; just b= ecause we like hash functions doesn=92t mean that SPHINCS+ is immune from i= mplementation error, and strong hybrid modes would also mitigate the conseq= uences of bungling the state-management of your XMSS private key; yes if you produced two signatures with the same= state then you would still need to revoke it for key compromise, but with = a layer of EC, you would have days =96 weeks to safely notice and take acti= on as opposed to hours.

 

I also understand that backwards compatibility, ease-of-migration, ease-of-= adoption, etc are in fact security goals themselves (fewer reasons to stay = on the old broken stuff), so in a conflict between migratibility and crypto= graphic strength, migratibility wins. But I don=92t believe there is a conflict here; I don=92t believe it= =92s Composite VS Multi-Cert; I believe the two play harmoniously together,= which brings me to the next point.

 

 

 

 

Point #2: Are composite and multi-cert competing or complementary in TLS an= d IKE?

 

I would like to clarify what I (speaking for myself, not necessarily my co-= authors) see as the posture for composite public keys, signatures, and cont= ent encryption:

 

The point is well-taken that negotiated protocols want full flexibility to = negotiate and don=92t want to send large PQ keys to legacy clients who won= =92t use them. Really though, nobody is proposing doing that (at least not = since draft-truskovsky-lamps-pq-hybrid-x509, which was abandoned in 2018).

 

I think we=92re all imagining a similar thing where TLS servers are provisi= oned with multiple certs, for example an RSA cert chain + a PQ cert chain; = runtime negotiation gets to choose to use one or the other or both. The que= stion is whether the PQ cert chain should itself be composite, ie PQ :=3D {EC, PQ} to protect against the cry= ptologic and implementation risks that I outline above until we have confid= ence in both the algorithms and their implementations.

 

So in my mind composite and multi-cert are complementary: do multi-cert for= backwards compatibility, and bury an Ed25519 inside your PQ cert for good = measure. Given the size and CPU of most PQ algs, you won=92t even notice it= =92s there.

 

 

 

Point #3: Offline protocols

As mentioned in the LAMPS meeting, I would love to see your analysis extend= ed to cover offline protocols (aka non-negotiated, or what I think Russ cal= led =93Sign-and-store=94 or =93encrypt-and-store=94). I propose that good s= ubjects for this analysis are: the Microsoft X.509-based code-signing infrastructure, document (PDF) signing infrastruc= tures, and S/MIME infrastructures.

 

For this section I=92m going to assume a risk model that a code-signed bina= ry or a signed/encrypted document has a security shelf-life of 30 years, du= ring which time we can expect RSA to fall to quantum computers, or the part= icular PQ alg used to have a bug found in it, or both (though the =93both=94 case is a bit hopeless unless you wa= nt to go to hybrid models with more than 2 algs).

 

 

Research / design questions for offline use-cases:

In the signing case, how does a recipient know that there should be two sig= natures when it only sees one? (aka stripping attacks, assuming one alg is = vulnerable to forgery attacks due to the above risks).

 

 

With PQ hybrid content-encryption (I hate that PQ has overloaded this term.= . maybe =93multi-key encryption=94 would be better?), the big risk I see is= that it is not the key-holder who gets to decide security, but the sender.= Ex.: it is not responsible-disclosu= re@megacorp.com that gets to choose how its encryption public keys are = used, but rather the mail client that whitehat.dude@gmail.com used= to encrypt the super-secret email. In fact, the recipient doesn=92t even k= now that somebody is using their keys until the encrypted content has alrea= dy crossed the internet. If we=92re proposing a multi-cert model here, then how does the sender know that the recipient = actually has two certificates that are expected be used together? You could= imagine cross-linking certs (or CAs) with some kind of extension, but A) n= obody, as of yet, has proposed a spec for that, and B) that would count as new cert verification logic, whi= ch I think goes against your =93Non-Composite PRO: Computational processes = remain unchanged (but perhaps multiple iterations)=94.

 

I would love to see your analysis framework extended to cover these sorts o= f long shelf-life non-negotiated protocols because these are the ones that = I feel benefit the most from composite certs.

 

---
Mike Ounsworth
Software Security Architect, Entrust

 

Any email and files/attachments transmitted with it are confidential and= are intended solely for the use of the individual or entity to whom they a= re addressed. If this message has been sent to you in error, you must not c= opy, distribute or disclose of the information it contains. Please notify Entrust immediately and dele= te the message from your system.
--_000_SA0PR09MB72412AF3E7DDBF2EA66179EBF1939SA0PR09MB7241namp_--