Should we prioritise LMS for the 3.5 release?

The concept is that the BAC representatives should reach out to the communities that they represent to get a sense of what the community expectations and priorities are - and then attempt to form a consistent cross-community view (where that is possible).

There were substantial discussions in this weeks OTC meeting about what is missing from the LMS PR and what would need to be sorted out prior to it being in a position to be ready to go into an OpenSSL release. We need to wait to have both verify and signing for LMS for it to make it into OpenSSL-3.5 and there are outstanding issues on the signing side of things to work through.

The draft minutes didn't quite capture that (they capture the topic being raised but do not note the conclusion to defer until we sort out the technical issues on the signing side of things) and will be updated. I'll drop a note when the update goes in.

The early adopters of LMS that I'm aware of have all rolled their own and implemented in software and none of their hardware vendors can provide what they need so they are operating in pure software with separate controls around the systems performing the signing and are for now ignoring the FIPS140-3 requirements. It would be useful to get references to any HSM vendors that are actually shipping solutions - and shipping them with a standard PKCS#11 interface so they can be used - and providing guarantees that it is impossible for any signature key to get reused even with backup and restore of HSMs and that the distributed storage management for the HSM also precludes signature key reuse.

There is a lot of creative marketing in the HSM space that the moment with PQC where vendors claim to have things but they are only in prototypes and not exposed in standard APIs and not actually able to be shipped.

Nothing comes at zero cost and our target list for OpenSSL-3.5 is rather ambitious (and the team and contributors are working through things as fast as they reasonably can).

At this stage we aren't yet confident we will get SLH-DSA into OpenSSL-3.5. So the question really is would half-of-LMS be a higher priority to all of SLH-DSA for OpenSSL-3.5.

Thanks Tim. You are right those additional details were not discussed (no mention of delaying SLH-DSA). The general thought was that LMS verify was done and wouldn't delay any other priorities. Your comments change that picture some. I haven't had a chance to reach out to those in the community as I am in the PQ PKI conference (Austin). I will ask around if I can, but it was interesting to see a couple talks on secure boot and another on HSM performance numbers with various alg's. This is fun stuff!

The decision was requested by the end of this week, there simply wasn't time to gather community input as you suggest. With a less stringent time frame, things would be done differently.

It isn't currently possible to FIPS validate LMS signing for a software library. LMS verify can, however, be validated now and I think it deserves inclusion for that reason. As noted: FIPS is important for the project. The LMS code is currently at a state where this is possible -- it is code complete and only requires some eyes for review. The effort required for this is low.

I don't agree with the notion that LMS is increasing the risk for SLH-DSA being absent in 3.5. Shane Lontis and I are doing the bulk of the work on all of the PQC algorithms and all of the work on LMS and SLH-DSA. SLH-DSA is close to code complete now. The only outstanding item I'm aware of is compliance with the FIPS self test requirements. We are fairly confident we can meet the required time frame.

In the Corporation BAC meeting discussion the context was that the target list for OpenSSL-3.5 of ML-KEM, Hybrid-ML-KEM-in-TLS, ML-DSA, SLH-DSA was already at risk of not being able to get all of those in. LMS was not on the list and did we have the SLH-DSA ahead of LMS in the right priority order. We did not anticipate that the BAC would have meaningful impacts on OpenSSL-3.5 but on things like the priority ordering of SLH-DSA compared to LMS getting confirmation that our currently planned priority order did match the community sense was the request - in that we have more work to do to SLH-DSA which could be redirected to LMS if we have the priorities not aligned with community views. We are confident at this stage on ML-KEM, Hybrid-ML-KEM-in-TLS and expect ML-DSA to follow, but beyond that we are in the territory of may not be ready in time for this release.

We also do not want to deliver half-algorithm solutions (i.e. just verification) and we want to ensure we have encoder and decoder support in place (i.e. not just the algorithm but things to a workable form for actual use). The prior feedback we have indicates our communities want completed features added in, not partial solutions. One of the reasons for the feature branches is to be able to develop and test features incrementally until they get to the level of making sense to drop into an OpenSSL release. It is a different way of working to what we have done in the past.

Note that doesn't mean external contributors shouldn't keep pushing things forward and getting things ready - once a feature branch is to the level of "nothing-more-planned-for-a-release" and reviewed and tested and the community has had an opportunity to look at and explore (and hopefully take for a test drive) a feature branch it can land early in a development cycle. The current set of feature branches are in various states of readiness and the Foundation and Corporation resources are focused on the feature set in the noted priority order.

Note so far the feedback in the Large Business Community Thread aligns with our sense of the appropriate priority order which is not at all surprising as that community is the one that tends to be closest to what the ultimate end users want available. It is early days in getting more explicit and public community feedback.

It is also expected that the feedback from different communities on priorities will vary and working through a collective viewpoint as the BAC for a recommendation to the Corporation is part of the "fun" of the BAC member roles.

Note none of this is a reflection on whether or not LMS is useful - we are basically talking about whether or not SLH-DSA is more important to land sooner than half-of-LMS - and the timeframes for all-of-LMS I expect will be for the October 2025 release (the one after OpenSSL-3.5 releasing in April). Again that is subject to community feature priority feedback which is one of the primary purposes of the BAC.

@Paul Dale It is my understanding as well the LMS signing in s/w is not highly desirable. However, LMS verification in s/w is. Norm Ashley from my team implemented both LMS sign and verify as part of his work in OQS. There was much controversy in that community on the LMS sign part and although the code is in there still, it is not built by default. I believe LMS verification is built by default. Anyway, just thought I would pass that along.

Anton, has the decision been deferred or the feature been deferred? We're a week from feature branch decisions, so I think you are saying LMS verification won't be included - correct?

The security concerns are only about signing, and there's a debate to be had about whether it should ever be included.

This conversation is about verification. Where do you see security concerns about verification? The verification code is merged, it goes cleanly to master and tests pass - it's ready to go now. It doesn't affect SLH-DSA, which has it's required approvals and is waiting to merge. I don't see any good reason to defer it. What is the justification?

@Paul Dale Feature-branch-based development is about completing all parts of a feature that are sufficient to justify its inclusion from a business perspective. We fully expect varying views within our communities, and we recognize that some of these views are passionately held. The primary purpose of this platform is to ensure these discussions and disagreements are clearly visible.

For this particular feature, there is not yet a clear community consensus in our view. That’s why we have deferred making a decision to allow time for that consensus to be established. We hope this process can happen early in the next release cycle, and there is nothing preventing this consensus-building from happening in parallel with the 3.5 release.