Re: [lamps] draft-gazdag-x509-hash-sigs-00

[Tim Hollebeek <[e-mail]>]

This won't work because the auditors or verifiers can only use CT to verify the 
state has not been reused for public issuance, but the required security property 
is that the state was never reused, ever.  If someone signs a test certificate and
something goes wrong and the system is rolled back or restored from backup,
and that test certificate gets out, you lose everything.  Secure state-based
hash implementations take some care ... but CT itself has similar problems,
so the problems are solvable.  But you need more invasive audit and validation
of implementations than just CT monitoring.

There was a lot of private discussion of all of this about five years ago when
hash-based public roots were last seriously considered, but those discussions
never went anywhere, in part because it was too early, and in part because it
became obvious that state management for hash-based certificates is tricky.

Revocation is another really fun problem, because it can really start eating up
your signature budget in some architectures and deployment models.

-Tim

> -----Original Message-----
> From: Spasm <[e-mail]> On Behalf Of Kampanakis, Panos
> Sent: Tuesday, January 31, 2023 10:28 AM
> To: Vaira, Antonio <[e-mail]>
> Cc: LAMPS <[e-mail]>; [e-mail]
> Subject: Re: [lamps] draft-gazdag-x509-hash-sigs-00
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaila
> rchive.ietf.org%2Farch%2Fmsg%2Fspasm%2FDKPDfaQZxF5_De9BYuoWsRKp
> 4gM%2F&data=05%7C01%7Cantonio.vaira%40siemens.com%7C42f367be82d
> d413a64ae08dafd1c9a04%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0
> %7C638100596561496300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&sdata=h25km8rodm9XTku1Chgjffe%2BEm9dORsXhMwrrDhcVzQ%3D&
> reserved=0 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=05%7C01%7Cantonio.vaira
> %40siemens.com%7C42f367be82dd413a64ae08dafd1c9a04%7C38ae3bcd9579
> 4fd4addab42e1495d55a%7C1%7C0%7C638100596561496300%7CUnknown%7
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BzfXk7IkssXiXjWumPeivk5qX
> UsPP2tXjqRJZXx3QB8%3D&reserved=0
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=05%7C01%7Cantonio.vaira
> %40siemens.com%7C42f367be82dd413a64ae08dafd1c9a04%7C38ae3bcd9579
> 4fd4addab42e1495d55a%7C1%7C0%7C638100596561496300%7CUnknown%7
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BzfXk7IkssXiXjWumPeivk5qX
> UsPP2tXjqRJZXx3QB8%3D&reserved=0
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm