Subject: [T2TRG] [Suit] using/building/standardizing HMS-LMS infrastructure (fwd) Michael Richardson: [Suit] using/building/standardizing HMS-LMS infrastructure

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Nov 2021 10:15:50 -0500

I hate that we can't have aliases.

Subject: [Suit] using/building/standardizing HMS-LMS infrastructure
From: Michael Richardson <[email-masked]>
To: suit <[email-masked]>, LAMPS WG <[email-masked]>, [email-masked]
Date: Thu, 11 Nov 2021 08:19:14 -0500
List-Id: Software Updates for Internet of Things <suit.ietf.org>

It seems that the SUIT WG is becoming quite comfortable with making HSS-LMS
mandatory to implement.   I want to ask some questions about the
infrastructure that will be required to operate things.
This is very much what draft-richardson-t2trg-idevid-considerations deals with.

What I am trying to avoid with this email and maybe subsequent documents is
that we wind up in a situation where HSS-LMS is rejected by industry because
they don't know how to operate it, and our MTI winds up being meaningless.

My understanding is that when creating HSS-LMS signatures that the signer has
to perform a read/modify/write cycle on the private component.

Failure to perform the write operation means that keys will get reused, and
the signatures will not be valid.
I don't think that results in disclosing a private key, as would happen if a
nonce is reused in the GCM/CCM/etc. symmetric cipher use though!
My understanding is that reusing the key would result in a signature that
would be rejected by verifiers as being a duplicated, and thus ignored.

This is constrasted to the Pre-Quantum methods (RSA, DSA, ECDSA, EDDDSA),
where a private key can be loaded from a secure storage, used and then the
in-ram copy destroyed.

There are two risks that I think are important to identify:

1) an HSM that overwrites the new content with the old risks failing halfway
   through, possibly resulting in loss of key.
   Some kind of append-only aka log-based file system would deal with that.

2) off-site/business continuity copies of the key may need much higher
   interactions with the primary/active site in order to remain in sync.
   Existing systems could essentially transfer the secrets once and then be
   done.

When we numbered certificates with sequential serial numbers there was
some need to transfer the counter to the backup system.  But that was
a public piece of information, signed by the CA, so the secondary system
could update it's serial number just by examining a public document.
Now, we generate serial numbers randomly, so we don't need to do that
anymore.

I think that if the secondary site saw all of the signed objects that it
could determine which keys were already used, and could advance itself
without having to interact directly with the HSM at the primary site.

Are there already documents (at NIST?) that explain operation of HSS-LMS signer?
If there aren't, is this something that the IETF should do?

Note that whatever we do, we need to make sure that it scales to the
developer's desktop so that the developer is always exercising the update
mechanism when working. (Otherwise, they put backdoors in due to frustration)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

_______________________________________________
Suit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/suit

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide