OpenSSL Communities

Summary of LBC Requests for OpenSSL Board

JJ Jeff Johnson Thu 22 Jan 2026 2:27PM Public Seen by 67

In preparation for the next BAC Meeting and the next LBC meeting .....

-jj

Core Objectives

  • Call for Input: Jeff Johnson (Cisco/BAC) initiated a request for large businesses to provide a prioritized list of features and capabilities they want OpenSSL to focus on to influence the project's roadmap.

Key Feature Requests by Organization

  • Cisco & Comcast:

    • DTLS 1.3: Prioritized for VPN and streaming platforms that cannot easily migrate to QUIC.

    • Post-Quantum (PQ) Support: Noted that PQ cannot be fully supported on DTLS 1.2, making DTLS 1.3 critical for future security.

  • Akamai (Watson Ladd):

    • QUIC API: Requested support for the BoringSSL QUIC API to maintain compatibility with Google Quiche and reduce the burden of custom patches.

    • Build System: Suggested migrating the build system to CMake for better integration with internal packaging.

    • Performance: Emphasized the need for performance at scale (hundreds of thousands of connections/sec).

    • FIPS Policy: Expressed concerns over AES-GCM restrictions and the need for better tracking of backwards compatibility issues.

  • Chainguard (Dimitri John Ledkov):

    • KDF Implementations: Requested KDF SNMP, KDF IKEv2, and PQC SSH KDFs in Default and FIPS providers.

    • Compatibility: Suggested source code compatibility with OpenSSL forks (like BoringSSL/AWS-LC) through macros or compat headers.

    • SHA-256: Requested support for SHA-256 in OCSP and for subjectKeyIdentifier.

    • FIPS-Unapproved Provider: Proposed a provider for non-security digests (like SHA-1/MD5) to support legacy "CRC-like" functionality.

  • Versa Networks (Suresh Keisam):

    • PQC Backporting: Requested backporting ML-DSA and LMS-verification to LTS OpenSSL 3.5 to meet DoD/CNSA 2.0 requirements.

    • QKD Provider: Requested a Quantum Key Distribution provider compliant with ETSI-014.

    • Runtime Control: Requested an equivalent to deprecated Engine APIs (ENG_CTRL) for finer runtime control.

Major Discussion Points & Debates

  • The QUIC API Conflict: Tim Hudson (OpenSSL President) rejected the request to adopt BoringSSL QUIC APIs, stating that the "ship has long since sailed" and that QUIC stack maintainers (like those of Google Quiche) should instead adopt the officially documented OpenSSL interface.

  • FIPS and AES-GCM: There was a technical debate regarding AES-GCM IV generation. Oracle and Chainguard representatives clarified that AES-GCM is approved in FIPS mode, provided IVs are generated internally (with specific exceptions for protocols like TLS and IPsec).

  • OpenSSH and PQC: Participants discussed the difficulty of getting the OpenSSH-portable project to accept patches for PQC. There was a suggestion to potentially collaborate on a "united front" or a separate project to ensure OpenSSH can use OpenSSL’s FIPS-validated PQC primitives.

  • LTS Backporting Policy: Red Hat and Oracle representatives expressed strong resistance to backporting major features (like LMS) into LTS releases, arguing that it deviates from established OpenSSL practices, despite the "once-in-a-lifetime" nature of the PQC transition.

PD

Paul Dale Thu 22 Jan 2026 10:01PM

Backporting LMS verify to 3.5 is not invasive but it is against policy and would require an exception. Given the resistance to it's inclusion in 3.5, I'm not hopeful.

Backporting the ML-DSA additions is more risky and I'd not recommend it.

MC

Matt Caswell Fri 23 Jan 2026 10:19AM

On the QUIC API we do already have a suitable third party API. It doesn't make any sense to add another one. I see no reason and have no plans to revisit that again.

BF

Barry Fussell Sun 8 Feb 2026 3:58PM

KDF SNMP and KDF SRTP have been committed to master. KDF IKEv2 is being worked on now. I could be wrong, but I don't think PQC SSH KDF is FIPS compliant or has ACVP testing available yet.

DB

Dmitry Belyavsky Sun 8 Feb 2026 5:01PM

We in Red Hat have implemented hybrid NIST PQ for OpenSSH and ready for sharing patches. If the "united front" or separate project happens, we would consider it.