Re: [lamps] Auditing HBS state usage

[Russ Housley <[e-mail]>]

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) <sfluhrer=[e-mail]> wrote:
> 
> Actually, it's not that hard to extract the current state from either an XMSS(^MT) or LMS/HSS signature.
> 
> For XMSS and XMSS^MT, the current state is at a fixed place in the signature.
> 
> For HSS, the state is scattered in the signature; however it's not *that* hard to retrieve...
> 
> So, expressing the current state explicitly in the certificate might make things a bit easier; however it doesn't fundamentally change anything
> 
>> -----Original Message-----
>> From: Spasm <[e-mail]> On Behalf Of Mike Ounsworth
>> Sent: Tuesday, January 31, 2023 10:51 AM
>> To: Kampanakis, Panos <kpanos=[e-mail]>; Vaira,
>> Antonio <[e-mail]>
>> Cc: LAMPS <[e-mail]>; [e-mail];
>> [e-mail]
>> Subject: Re: [lamps] Auditing HBS state usage
>> 
>> [changing title, and adding PQUIP list]
>> 
>>> - 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?
>> 
>> Interesting idea!
>> Basically, explicitly put the private key state in the signature for easy auditing.
>> 
>> 
>> 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.
>> 
>> 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.
>> 
>> ---
>> Mike Ounsworth
>> 
>> -----Original Message-----
>> From: Spasm <[e-mail]> On Behalf Of Kampanakis, Panos
>> Sent: Tuesday, January 31, 2023 9:28 AM
>> To: Vaira, Antonio <[e-mail]>
>> Cc: LAMPS <[e-mail]>; [e-mail]
>> Subject: [EXTERNAL] Re: [lamps] draft-gazdag-x509-hash-sigs-00
>> 
>> WARNING: This email originated outside of Entrust.
>> DO NOT CLICK links or attachments unless you trust the sender and know the
>> content is safe.
>> 
>> ________________________________________________________________
>> ______
>> Hi Antonio,
>> 
>>> - 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?
>> 
>> 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.
>> 
>> 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.
>> 
>> 
>> 
>> -----Original Message-----
>> From: Spasm <[e-mail]> On Behalf Of Vaira, Antonio
>> Sent: Tuesday, January 31, 2023 7:33 AM
>> To: Kousidis, Stavros <stavros.kousidis=[e-mail]>;
>> Kampanakis, Panos <kpanos=[e-mail]>
>> Cc: LAMPS <[e-mail]>; [e-mail]
>> Subject: RE: [EXTERNAL][lamps] draft-gazdag-x509-hash-sigs-00
>> 
>> 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.
>> 
>> 
>> 
>> Dear Stavros, Dear Panos,
>> 
>> I hope I am not intruding this conversation, I would like to add a couple of
>> personal considerations:
>> 
>> - 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.
>> 
>> - @Stavros: it would be very interesting to know more about how you plan to
>> handle the requirements from §7 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 §7 of NIST SP 800-208?
>> 
>> 
>> Many thanks
>> Antonio Vaira
>> 
>> -----Original Message-----
>> From: Spasm <[e-mail]> On Behalf Of Kousidis, Stavros
>> Sent: Monday, 23 January 2023 09:33
>> To: Kampanakis, Panos <kpanos=[e-mail]>
>> Cc: LAMPS <[e-mail]>; [e-mail]
>> Subject: Re: [lamps] draft-gazdag-x509-hash-sigs-00
>> 
>> Dear Pano,
>> 
>> thank you for your comments and suggestions, and sorry for the late reply.
>> 
>> 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 §7) as a design to
>> further ensure that states are handled appropriately.
>> 
>> 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.
>> 
>> Best
>> Stavros
>> 
>> -----Ursprüngliche Nachricht-----
>> Von: Kampanakis, Panos <kpanos=[e-mail]>
>> Gesendet: Donnerstag, 29. Dezember 2022 18:23
>> An: Kousidis, Stavros <[e-mail]>
>> Cc: LAMPS <[e-mail]>; [e-mail]
>> Betreff: RE: [lamps] draft-gazdag-x509-hash-sigs-00
>> 
>> One more comment regarding draft-gazdag-x509-hash-sigs.
>> 
>> 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=https*3A*2F*2Fmailarchive.ietf.org*2Farch*2Fmsg*2Fspasm*2FDKP
>> DfaQZxF5_De9BYuoWsRKp4gM*2F&data=05*7C01*7Cantonio.vaira*40siem
>> ens.com*7C42f367be82dd413a64ae08dafd1c9a04*7C38ae3bcd95794fd4add
>> ab42e1495d55a*7C1*7C0*7C638100596561496300*7CUnknown*7CTWFpbG
>> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
>> Mn0*3D*7C3000*7C*7C*7C&sdata=h25km8rodm9XTku1Chgjffe*2BEm9dOR
>> sXhMwrrDhcVzQ*3D&reserved=0__;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.
>> 
>> 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.
>> 
>> 
>> 
>> -----Original Message-----
>> From: Spasm <[e-mail]> On Behalf Of Kousidis, Stavros
>> Sent: Saturday, December 24, 2022 12:11 AM
>> To: Russ Housley <[e-mail]>
>> Cc: LAMPS <[e-mail]>; [e-mail]
>> Subject: RE: [EXTERNAL][lamps] draft-gazdag-x509-hash-sigs-00
>> 
>> 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.
>> 
>> 
>> 
>> Dear Russ,
>> 
>> thank you for the information.
>> 
>> 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".
>> 
>> Best
>> Stavros
>> 
>> -----Ursprüngliche Nachricht-----
>> Von: Russ Housley <[e-mail]>
>> Gesendet: Freitag, 23. Dezember 2022 18:12
>> An: [e-mail]
>> Cc: LAMPS <[e-mail]>
>> Betreff: [lamps] draft-gazdag-x509-hash-sigs-00
>> 
>> Dear I-D Authors:
>> 
>> RFC 8708 has this definition:
>> 
>>     HSS-LMS-HashSig-PublicKey ::= OCTET STRING
>> 
>> This will carry the bytes as defined in RFC 8554.
>> 
>> draft-gazdag-x509-hash-sigs-00 says:
>> 
>>    HSS-HashSig-PublicKey ::= 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
>>    }
>> 
>> 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.
>> 
>> Russ
>> 
>> _______________________________________________
>> Spasm mailing list
>> [e-mail]
>> https://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.co
>> m/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm&data=
>> 05*7C01*7Cantonio.vaira*40siemens.com*7C42f367be82dd413a64ae08dafd
>> 1c9a04*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C63810059656
>> 1496300*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
>> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=BzfXk7I
>> kssXiXjWumPeivk5qXUsPP2tXjqRJZXx3QB8*3D&reserved=0__;JSUlJSUlJSUlJSU
>> lJSUlJSUlJSUlJQ!!FJ-
>> Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7We
>> Ocu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OirgtotNA$
>> 
>> _______________________________________________
>> Spasm mailing list
>> [e-mail]
>> https://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.co
>> m/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm&data=
>> 05*7C01*7Cantonio.vaira*40siemens.com*7C42f367be82dd413a64ae08dafd
>> 1c9a04*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C63810059656
>> 1496300*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
>> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=BzfXk7I
>> kssXiXjWumPeivk5qXUsPP2tXjqRJZXx3QB8*3D&reserved=0__;JSUlJSUlJSUlJSU
>> lJSUlJSUlJSUlJQ!!FJ-
>> Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7We
>> Ocu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OirgtotNA$
>> 
>> _______________________________________________
>> Spasm mailing list
>> [e-mail]
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm_
>> _;!!FJ-
>> Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7We
>> Ocu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OgQtC7kZg$
>> 
>> _______________________________________________
>> Spasm mailing list
>> [e-mail]
>> 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.
>> 
>> _______________________________________________
>> Spasm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spasm
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm