From nobody Tue Jan 31 12:13:51 2023 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 B9B14C151707; Tue, 31 Jan 2023 12:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.897 X-Spam-Level: X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sp5TdGSGq65f; Tue, 31 Jan 2023 12:13:46 -0800 (PST) Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A30C151551; Tue, 31 Jan 2023 12:13:46 -0800 (PST) Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 29A45F6033; Tue, 31 Jan 2023 15:13:45 -0500 (EST) Received: from [10.0.1.2] (pfs.iad.rg.net [198.180.150.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id E37B2F6031; Tue, 31 Jan 2023 15:13:44 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: Date: Tue, 31 Jan 2023 15:13:44 -0500 Cc: "Vaira, Antonio" , LAMPS , "draft-gazdag-x509-hash-sigs.authors@ietf.org" , "pqc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8E299570-E1F6-44AC-9C36-9F078B478C12@vigilsec.com> References: <08C331ED-453C-4812-955A-F2161B960329@vigilsec.com> <3439f87bb3bb4a199f706b791cba6b6a@bsi.bund.de> <6828097d5b5b4beabb0c4243b150077f@amazon.com> <99a43b5f4620438a9cb7ca539f70dbcb@bsi.bund.de> To: Scott Fluhrer X-Mailer: Apple Mail (2.3445.104.21) X-Scanned-By: mailmunge 3.10 on 66.39.134.11 Archived-At: Subject: Re: [lamps] Auditing HBS state usage X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.39 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: Tue, 31 Jan 2023 20:13:50 -0000 Scott: This tell which position was used for a particular signature. I am = aware of schemes where the tree is divided among signers. This is done = so that each signer operated in a separate sub-tree to ensure that the = same node is never used twice. This means that the auditor would need = additional knowledge regarding the sub-tree assignments to know the what = is gong on. Russ > On Jan 31, 2023, at 1:10 PM, Scott Fluhrer (sfluhrer) = wrote: >=20 > Actually, it's not that hard to extract the current state from either = an XMSS(^MT) or LMS/HSS signature. >=20 > For XMSS and XMSS^MT, the current state is at a fixed place in the = signature. >=20 > For HSS, the state is scattered in the signature; however it's not = *that* hard to retrieve... >=20 > So, expressing the current state explicitly in the certificate might = make things a bit easier; however it doesn't fundamentally change = anything >=20 >> -----Original Message----- >> From: Spasm On Behalf Of Mike Ounsworth >> Sent: Tuesday, January 31, 2023 10:51 AM >> To: Kampanakis, Panos ; Vaira, >> Antonio >> Cc: LAMPS ; = draft-gazdag-x509-hash-sigs.authors@ietf.org; >> pqc@ietf.org >> Subject: Re: [lamps] Auditing HBS state usage >>=20 >> [changing title, and adding PQUIP list] >>=20 >>> - my understanding of stateful HBS schemes is that the state of the = private >> key can be uniquely identified by the authentication path that is = part of the >> signature. Could we think to derive a unique value, out of this = authentication >> path and embed it into a certificate field? Maybe such certificate = can be >> further published, for example on CT, to allow public scrutiny of the = CA >> operations? >>=20 >> Interesting idea! >> Basically, explicitly put the private key state in the signature for = easy auditing. >>=20 >>=20 >> IMO the list of certificates issued by a CA is already well tracked = and audited. >> IMO if we're gonna get ourselves into trouble with over-using a HBS = key, it's >> gonna be uses of the CA key for things other than certificate = signing; like a >> stuck process that re-issues the same CRL 500 times, or a CA set up = for direct >> OCSP or CMP signing with the CA key, or .. who knows .. some CA = software >> that uses the CA key for backend TLS connections, or that uses the CA = key to >> sign audit records. All things that are completely not a problem = today, so >> developers and ops personnel might not even think about them when >> moving to a HBS CA key. >>=20 >> I like the idea of auditing signatures and private key states, but I = think for it to >> be effective you have to audit every signature performed by the HSM = to >> make sure you're catching "the weird stuff" that might not otherwise = get >> audited. In my mind, this is in the bucket of "quality of life = features" that >> HSM vendors will need to build in to their products that support HBS. >>=20 >> --- >> Mike Ounsworth >>=20 >> -----Original Message----- >> From: Spasm On Behalf Of Kampanakis, Panos >> Sent: Tuesday, January 31, 2023 9:28 AM >> To: Vaira, Antonio >> Cc: LAMPS ; = draft-gazdag-x509-hash-sigs.authors@ietf.org >> Subject: [EXTERNAL] Re: [lamps] draft-gazdag-x509-hash-sigs-00 >>=20 >> WARNING: This email originated outside of Entrust. >> DO NOT CLICK links or attachments unless you trust the sender and = know the >> content is safe. >>=20 >> ________________________________________________________________ >> ______ >> Hi Antonio, >>=20 >>> - my understanding of stateful HBS schemes is that the state of the = private >> key can be uniquely identified by the authentication path that is = part of the >> signature. Could we think to derive a unique value, out of this = authentication >> path and embed it into a certificate field? Maybe such certificate = can be >> further published, for example on CT, to allow public scrutiny of the = CA >> operations? >>=20 >> Interesting. Indeed, Stateful leaf HBS certs (which will include the = tree >> verification path) could be published so auditors or verifiers could = attest that >> state was not reused. For the Web there is CT so that would be = relatively >> straightforward. But given these certs will not be used for the Web, = it >> probably does not help much. In a code signing case, a signer vendor = that >> signs its software would need to publish all HBS signatures basically = for them >> to be auditable to confirm state/OTS public key was not reused. It = would be >> operational overhead for vendors though to make all their signatures >> available. >>=20 >> There is the threat model that is important here as well. If I am the = verifier of >> company X created by company X to verify company X's software = signatures, >> do I need to audit company X's signing did not reuse SHBS state? = Probably >> not because I trust the signer who is probably auditing internally. = But still, a >> published code signing repo of all (Root signatures and ICA issued = signatures >> and software signatures) could provide assurance to 3rd parties that = want to >> be sure. It still is not perfect because someone could argue that = some failure >> scenario while signing may have reused state but the signature did = not show >> up in the published signatures, but it certainly raises trust. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Spasm On Behalf Of Vaira, Antonio >> Sent: Tuesday, January 31, 2023 7:33 AM >> To: Kousidis, Stavros = ; >> Kampanakis, Panos >> Cc: LAMPS ; = draft-gazdag-x509-hash-sigs.authors@ietf.org >> Subject: RE: [EXTERNAL][lamps] draft-gazdag-x509-hash-sigs-00 >>=20 >> CAUTION: This email originated from outside of the organization. Do = not click >> links or open attachments unless you can confirm the sender and know = the >> content is safe. >>=20 >>=20 >>=20 >> Dear Stavros, Dear Panos, >>=20 >> I hope I am not intruding this conversation, I would like to add a = couple of >> personal considerations: >>=20 >> - I believe that we will also need to have "stateful HBS ICAs", to at = least sign >> "stateful HBS code-signing certificates". This would allow a relying = party to >> validate the code-signing certificates, and its associated = certificate chain, by >> verifying only one type of digital signatures, which in this case = would be a >> stateful HBS scheme. This type of ICAs may be handled as RootCA, so >> probably there is not much to add to the security considerations. >> - my understanding of stateful HBS schemes is that the state of the = private >> key can be uniquely identified by the authentication path that is = part of the >> signature. Could we think to derive a unique value, out of this = authentication >> path and embed it into a certificate field? Maybe such certificate = can be >> further published, for example on CT, to allow public scrutiny of the = CA >> operations? >> - on a more generic note, the recent publication of CNSA 2.0, despite >> applying only to NSS, may trigger other regulatory bodies, which may = be >> transversal to the scope of NSS, to adopt similar guidelines. = Therefore I think >> we might have to deal with stateful HBS sooner than later. >>=20 >> - @Stavros: it would be very interesting to know more about how you = plan to >> handle the requirements from =C2=A77 of NIST SP 800-208. >>> in my understanding, to fulfil the requirements set forth in this = section >> one would that initializing several hypertrees on different HSMs. One = or >> more HSMs may be used immediately and the remaining should be = securely >> stored for later use (as disaster recovery mechanism for example). I = think >> this approach might prove to be quite cumbersome, at least over a = long >> period of time (which is intended use of stateful HBS). >>> do you see additional approaches that would allow to comply with the >> requirements from =C2=A77 of NIST SP 800-208? >>=20 >>=20 >> Many thanks >> Antonio Vaira >>=20 >> -----Original Message----- >> From: Spasm On Behalf Of Kousidis, Stavros >> Sent: Monday, 23 January 2023 09:33 >> To: Kampanakis, Panos >> Cc: LAMPS ; = draft-gazdag-x509-hash-sigs.authors@ietf.org >> Subject: Re: [lamps] draft-gazdag-x509-hash-sigs-00 >>=20 >> Dear Pano, >>=20 >> thank you for your comments and suggestions, and sorry for the late = reply. >>=20 >> The typical use case we have in mind are root and (potentially also >> subordinate) CAs which are using an HSM for cert signing that ensures = the >> secure handling of the state. When discussing this in the security >> considerations we would also stress on NISTs proposal to use = "Distributed >> Multi-Tree Hash-Based Signatures" (see NIST SP 800-208 =C2=A77) as a = design to >> further ensure that states are handled appropriately. >>=20 >> We have tracked the other use cases you mentioned as an issue in in = our >> repository. I think Stefan Gazdag has some experience here and we = will >> discuss how to incorporate your suggestions in the security = considerations. >>=20 >> Best >> Stavros >>=20 >> -----Urspr=C3=BCngliche Nachricht----- >> Von: Kampanakis, Panos >> Gesendet: Donnerstag, 29. Dezember 2022 18:23 >> An: Kousidis, Stavros >> Cc: LAMPS ; = draft-gazdag-x509-hash-sigs.authors@ietf.org >> Betreff: RE: [lamps] draft-gazdag-x509-hash-sigs-00 >>=20 >> One more comment regarding draft-gazdag-x509-hash-sigs. >>=20 >> Stateful HBS had come up previously for X.509 and some participants = voiced >> serious concerns >> = https://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.co >> m/?url=3Dhttps*3A*2F*2Fmailarchive.ietf.org*2Farch*2Fmsg*2Fspasm*2FDKP >> DfaQZxF5_De9BYuoWsRKp4gM*2F&data=3D05*7C01*7Cantonio.vaira*40siem >> ens.com*7C42f367be82dd413a64ae08dafd1c9a04*7C38ae3bcd95794fd4add >> ab42e1495d55a*7C1*7C0*7C638100596561496300*7CUnknown*7CTWFpbG >> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6 >> Mn0*3D*7C3000*7C*7C*7C&sdata=3Dh25km8rodm9XTku1Chgjffe*2BEm9dOR >> sXhMwrrDhcVzQ*3D&reserved=3D0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!FJ-= >> Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7We >> Ocu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OhAlgSN8g$ A >> summary of the counter-arguments could be that CAs have messed up >> before, how can we rest assured they will not reuse state. >>=20 >> I think your argument for Stateful HBS in this draft is only for root = CAs which >> sign a few ICAs and then go to sleep and rarely wake up. Maybe = another use >> is for code-signing EKU certs where the signer controls its signing = process and >> the verifiers trust it. The draft also mentions subordinate CA = certificates. I >> don't think these are good use-cases for stateful HBS. I would = suggest for the >> draft to clearly stress the potentially use-cases for Stateful HBS. = Also I suggest >> for the security considerations section to stress the importance and = how you >> envision these use-cases will be able to address the state concern. = For >> example a Root CA uses an HSM and signs very few ICA certs and then = goes >> offline. Another example is a code-signer keeps track of all its = signatures and >> can go back and attest the state was not reused periodically and its = verifiers >> usually trust the signer. Another one could be the state look ahead = where >> you retrieve x states and change your pointer before you even start = signing >> anything. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Spasm On Behalf Of Kousidis, Stavros >> Sent: Saturday, December 24, 2022 12:11 AM >> To: Russ Housley >> Cc: LAMPS ; = draft-gazdag-x509-hash-sigs.authors@ietf.org >> Subject: RE: [EXTERNAL][lamps] draft-gazdag-x509-hash-sigs-00 >>=20 >> CAUTION: This email originated from outside of the organization. Do = not click >> links or open attachments unless you can confirm the sender and know = the >> content is safe. >>=20 >>=20 >>=20 >> Dear Russ, >>=20 >> thank you for the information. >>=20 >> In the next version we will adopt the "OCTET STRING" definition of = RFC 8708 >> for HSS and apply this also to XMSS/XMSS^MT. The same applies to >> SPHINCS+ where we will adopt the definition of "draft-ietf-lamps-cms- >> sphincs-plus-01". >>=20 >> Best >> Stavros >>=20 >> -----Urspr=C3=BCngliche Nachricht----- >> Von: Russ Housley >> Gesendet: Freitag, 23. Dezember 2022 18:12 >> An: draft-gazdag-x509-hash-sigs.authors@ietf.org >> Cc: LAMPS >> Betreff: [lamps] draft-gazdag-x509-hash-sigs-00 >>=20 >> Dear I-D Authors: >>=20 >> RFC 8708 has this definition: >>=20 >> HSS-LMS-HashSig-PublicKey ::=3D OCTET STRING >>=20 >> This will carry the bytes as defined in RFC 8554. >>=20 >> draft-gazdag-x509-hash-sigs-00 says: >>=20 >> HSS-HashSig-PublicKey ::=3D SEQUENCE { >> levels OCTET STRING, -- number of levels L >> tree OCTET STRING, -- typecode of top-level LMS tree >> ots OCTET STRING, -- typecode of top-level LM-OTS >> identifier OCTET STRING, -- identifier I of top-level LMS key = pair >> root OCTET STRING -- root T[1] of top-level tree >> } >>=20 >> This will produce a different byte string than RFC 8554. I think = this is a >> problem. There should only be one way to encode the HSS/LMS public = key. >>=20 >> Russ >>=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> = https://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.co >> m/?url=3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm&data=3D= >> 05*7C01*7Cantonio.vaira*40siemens.com*7C42f367be82dd413a64ae08dafd >> 1c9a04*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C63810059656 >> 1496300*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l >> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=3DBzfXk7I >> kssXiXjWumPeivk5qXUsPP2tXjqRJZXx3QB8*3D&reserved=3D0__;JSUlJSUlJSUlJSU >> lJSUlJSUlJSUlJQ!!FJ- >> Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7We >> Ocu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OirgtotNA$ >>=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> = https://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.co >> m/?url=3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm&data=3D= >> 05*7C01*7Cantonio.vaira*40siemens.com*7C42f367be82dd413a64ae08dafd >> 1c9a04*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C63810059656 >> 1496300*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l >> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=3DBzfXk7I >> kssXiXjWumPeivk5qXUsPP2tXjqRJZXx3QB8*3D&reserved=3D0__;JSUlJSUlJSUlJSU >> lJSUlJSUlJSUlJQ!!FJ- >> Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7We >> Ocu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OirgtotNA$ >>=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> = https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm_ >> _;!!FJ- >> Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7We >> Ocu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OgQtC7kZg$ >>=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> = https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm_ >> _;!!FJ- >> Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7We >> Ocu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OgQtC7kZg$ >> 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 = 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 = Entrust >> immediately and delete the message from your system. >>=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm