Re: [lamps] Proposed addition of hash-based signature algorithms for certificates to the LAMPS charter

[Daniel Van Geest <[e-mail]>]

Hi Adam,

You’re right that handling state needs to be done carefully and use of these signature schemes would not be appropriate in many contexts.  My presentation of this draft to LAMPS and SECDISPATCH pointed this out and gave some examples where they would and would not be appropriate.  If the WG chooses to proceed with this draft we can add more prominent/thorough text covering risks and mitigations.  Some solutions for managing state have been investigated, for example in https://eprint.iacr.org/2016/357.pdf, and should be used by signing implementations.

There are multi-lateral use cases for these signatures, a notable one being offline root CA signing.  Since these signature schemes are already well trusted, migration can begin prior to the completion of the NIST PQ Cryptography standardization, but will probably continue to be used well beyond that since they have decades of study behind them.

If we add stronger text warning of state reuse or mismanagement, the same should probably be done in draft-ietf-lamps-cms-hash-sig.  That draft is targeting code signing in CMS, but CMS also has other use cases where stateful signatures could be dangerous.

Daniel


On 2018-11-08, 3:42 PM, "Spasm on behalf of Adam Langley" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

On Tue, Nov 6, 2018 at 7:51 PM Russ Housley <[e-mail]<mailto:[e-mail]>> wrote:
The SECDISPATCH WG met on Tuesday afternoon, and they made this recommendation:

>  draft-vangeest-x509-hash-sigs-01 -- re-charter LAMPS WG to accept this draft

Three questions:

1) Do you support the addition of this work to the LAMPS charter?

No:

The signature schemes in the draft are stateful and sudden-death: the penalty for mishandling the state is huge. This contrasts with every signature scheme ever (I believe) deployed and thus with every current process. For example, reconstituting an HSM from smartcards would be a fatal error with such a scheme.

These schemes hedge against a valid risk, but at the cost of introducing a much larger one.

The contexts in which stateful & sudden-death signatures are plausible are so specific and controlled that standisation in X.509 would be immaterial to them—they are not multi-lateral enough that whether something has an RFC or not matters. On the other hand, standisation implicitly hints that the thing being standardised is somewhat reasonable. So, on balance, I don't think the integration of stateful schemes into formats and protocols is a suitable subject for the IETF.


AGL
--
Adam Langley [e-mail]<mailto:[e-mail]> https://www.imperialviolet.org