TLS Supported Groups Database: Elliptic Curves and Post-Quantum KEMs
A practical guide to TLS Supported Groups: elliptic curves, standalone ML-KEM, standardized PQ/T hybrids, registry flags, code points, and deployment checks.
TLS Supported Groups is the registry for key-exchange methods negotiated by TLS, not merely a list of elliptic curves. It includes familiar elliptic-curve Diffie–Hellman groups, standalone ML-KEM entries, and hybrid methods that combine ML-KEM with ephemeral elliptic-curve Diffie–Hellman (ECDHE). For TLS 1.3 post-quantum migration, the three standardized hybrids are X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. The IANA snapshot checked on 2026-09-29 marks only X25519MLKEM768 as Recommended=Y among those three. That registry flag does not prove a particular client and server support it.
This guide explains how to read the registry, what the names and code points mean, how the standards fit together, and how to assess implementation support without mistaking an assignment for interoperability.
1. What does “TLS Supported Groups” mean?
In TLS, a supported group is a named key-exchange method that peers can negotiate. “Group” historically evokes the elliptic-curve group used by ECDHE, but the registry’s scope has broadened. TLS 1.3 also uses group names for KEM-based and combined methods. RFC 9954 defines a general framework for hybrid key exchange; RFC 10024 applies it to three ML-KEM/ECDHE combinations. [IANA Supported Groups registry](https://www.iana.org/assignments/tls-parameters) · [RFC 9954](https://www.rfc-editor.org/rfc/rfc9954.html) · [RFC 10024](https://www.rfc-editor.org/rfc/rfc10024.html)
Supported Groups are not cipher suites. A group identifies a key-exchange choice. A cipher suite identifies the symmetric cipher and message authentication combination used by TLS 1.3. Nor is the group an authentication algorithm: a hybrid key exchange does not, by itself, make a certificate signature post-quantum.
Where negotiation happens
In TLS 1.3, a client advertises supported groups and typically sends key shares for one or more groups. The server selects a mutually usable method. If the server selects a group for which the client did not send a key share, TLS can use the HelloRetryRequest mechanism to ask for one. The exact behavior depends on TLS version and implementation; consult the implementation’s documentation when diagnosing negotiation.
2. The registry fields developers need to read
The IANA registry records identifiers and their assigned properties. It is an authoritative source for the assignment, but it is not a compatibility matrix across operating systems, browsers, libraries, or servers.
| Field | What it tells you | What it does not tell you |
|---|---|---|
| Value | The assigned numeric code point, often displayed in decimal and sometimes hex. | Whether your TLS stack implements the group. |
| Description | The registry name, such as X25519MLKEM768. |
That every product uses the same spelling in configuration. |
| DTLS-OK | Whether the registry marks the group as usable with DTLS. | Whether a particular DTLS implementation supports it. |
| Recommended | The registry’s recommendation state, including Y, N, or D for deprecated-style entries. | A universal deployment decision or implementation availability. |
| Reference / Comment | The document governing the assignment and notes such as obsolescence. | A substitute for reading the referenced specification. |
Registry status can evolve. If you are documenting a configuration or audit, record when you checked the registry and cite the relevant specification, rather than treating a live flag as immutable.
3. Elliptic-curve groups and the post-quantum additions
Traditional ECDHE groups include curve-based choices such as X25519 and NIST elliptic curves. They establish a shared secret using ephemeral Diffie–Hellman. The post-quantum additions introduce KEM choices and combinations, so the registry should no longer be read as “the curve list.”
Standalone ML-KEM registry entries
The checked IANA snapshot contains standalone MLKEM512 (512), MLKEM768 (513), and MLKEM1024 (514). Each is marked DTLS-OK=Y and Recommended=N in that snapshot, with a reference to draft-ietf-tls-mlkem-10. These are distinct from the three RFC 10024 hybrid entries below. A draft reference means you should verify the current registry and applicable specification before relying on the assignment for a deployment.
RFC 10024 hybrid groups
| Decimal | Hex | Registry name | Components | Recommended in 2026-09-29 snapshot |
|---|---|---|---|---|
| 4587 | 0x11EB |
SecP256r1MLKEM768 |
NIST P-256 ECDHE + ML-KEM-768 | N |
| 4588 | 0x11EC |
X25519MLKEM768 |
X25519 ECDHE + ML-KEM-768 | Y |
| 4589 | 0x11ED |
SecP384r1MLKEM1024 |
NIST P-384 ECDHE + ML-KEM-1024 | N |
All three were marked DTLS-OK=Y in the checked registry snapshot. Their names and code points are assigned by IANA and specified in [RFC 10024](https://www.rfc-editor.org/rfc/rfc10024.html). The Recommended values above describe that dated registry snapshot; check the live [IANA registry](https://www.iana.org/assignments/tls-parameters) for changes.
How to choose among the three
- X25519MLKEM768: combines widely deployed X25519 with ML-KEM-768. RFC 10024 describes it as often the most practical choice when selecting one PQ/T combiner for TLS 1.3. In the cited registry snapshot it is the only one of the three marked Recommended=Y.
- SecP256r1MLKEM768: pairs P-256 with ML-KEM-768. RFC 10024 describes it for situations requiring both shared secrets to be generated by FIPS-approved mechanisms. This does not mean every implementation or deployment is FIPS-approved.
- SecP384r1MLKEM1024: pairs P-384 with ML-KEM-1024. RFC 10024 describes it for high-security environments seeking an increased security margin. This is a use case in the standard, not a universal ranking.
Use the standard’s rationale as a starting point, then check your actual policy requirements and the TLS products and versions at both ends. Do not infer speed, security certification, or compatibility from the name or Recommended field.
4. How hybrid key exchange works
RFC 9954 defines a framework in which a hybrid combination is negotiated as one TLS 1.3 key-exchange method. The framework combines component key-exchange values and component shared secrets by concatenation; the combined secret then enters the existing TLS 1.3 key schedule. RFC 10024 supplies the concrete ML-KEM/ECDHE groups and their parameters. This construction is intended to combine a traditional component with a post-quantum component during key establishment.
Keep key establishment separate from authentication in your threat model. RFC 9954 addresses ephemeral hybrid key exchange; it does not define post-quantum authentication or certificate signatures. A connection using a hybrid group can still authenticate with the signature algorithms and certificate chain configured by the endpoints.
5. Legacy Kyber draft identifiers
The registry lists X25519Kyber768Draft00 (25497) and SecP256r1Kyber768Draft00 (25498) as obsolete, with Recommended=D and comments identifying RFC 10024 as the obsoleting specification. These are old draft identifiers, not the standardized group names. Do not copy them into a new configuration because a blog post or older deployment guide calls them “Kyber hybrid.” Migrate using the standardized names only when the relevant software supports the RFC 10024 definitions.
The registry also contains draft assignments beyond the three RFC 10024 groups, including names such as SecP256r1MLKEM512, MLKEM512X25519, and a draft SM2/ML-KEM hybrid. Track their references and status independently; do not present them as part of RFC 10024.
6. Check support in a real deployment
An IANA assignment is an identifier allocation, not proof of support. The standards cited here do not provide a current cross-implementation matrix, and no compatibility test is implied by this article. Check both client and server release documentation and test the actual TLS path, including proxies and terminators.
- Inventory the handshake endpoints. Identify the client, origin server, reverse proxy, CDN, service mesh, and any TLS inspection device. The negotiated group is bounded by the capabilities of the endpoints that actually terminate the handshake.
- Record versions and configuration. Capture OS, browser, TLS library, server and proxy versions, enabled TLS versions, and any group allowlists. A support statement without a version number can be misleading.
- Check authoritative references. Confirm the current IANA assignment and read RFC 10024 for hybrid parameters. Use vendor documentation for product-specific support.
- Test negotiation and fallback. Run client-to-server tests in a staging environment, inspect handshake diagnostics, and verify behavior when the hybrid group is absent or rejected. Include older clients if they remain in scope.
- Separate key exchange from authentication. Review certificate signature algorithms and trust configuration separately; enabling a hybrid group does not make those post-quantum.
- Monitor outcomes. Track handshake failures and negotiated parameters using your existing telemetry. Roll out gradually where endpoint diversity or middleboxes could affect success.
7. Common errors and troubleshooting
| Symptom | Likely cause | What to do |
|---|---|---|
| “No shared group” or handshake failure | The peers have no mutually enabled group, the selected TLS version does not permit the expected method, or an intermediary terminates TLS with a different capability set. | Inspect the handshake at the actual terminator; compare enabled groups and protocol versions on both ends. Test a known mutually supported group, then enable the hybrid on both peers where supported. |
| Configuration rejects the RFC group name | The product is older, uses a different configuration syntax, or recognizes only traditional groups. | Check version-specific documentation and accepted identifiers. Do not substitute a similarly named draft Kyber group. |
| Registry says Recommended=Y, but connection does not use it | Recommended is registry metadata, not an instruction to every implementation. The group may not be enabled, supported, or selected by negotiation policy. | Confirm implementation support and configuration, then inspect the negotiated handshake rather than assuming the registry controls it. |
| Works directly but fails through a proxy or CDN | The proxy may terminate and create a separate TLS handshake, or an intermediary may mishandle a handshake it does not support. | Test each leg independently and check the TLS terminator’s version and policy. Coordinate changes across all termination points. |
| Hybrid is enabled but compliance review still flags certificates | Key exchange and authentication are separate. The certificate signature may still use a conventional algorithm. | Document the distinction and assess certificate and signature requirements as a separate migration workstream. |
| Older guide lists code points 25497 or 25498 | The guide refers to obsolete draft identifiers. | Use the live registry and RFC 10024 names for current work; verify that your stack implements the final definitions before changing production. |
8. Performance, reliability, and operational considerations
The cited registry and RFCs establish assignments and protocol behavior; they do not provide a universal latency or throughput benchmark. Hybrid key exchange carries both component exchanges, so message sizes and processing work can differ from a single classical exchange. The actual impact depends on the implementation, network path, hardware, and workload. Measure your own handshake latency, CPU use, and failure rates rather than projecting a result from the group name.
Reliability depends on coordinated support and negotiation policy. A client may offer multiple groups, while a server can select only a supported option. Rollouts should account for clients that lack the new groups, TLS-terminating intermediaries, and configuration drift. Use staged deployment and keep a tested compatibility path consistent with your security policy.
There is no per-group price in the registry. Costs are operational: engineering time to verify versions, rollout and monitoring work, and any infrastructure changes revealed by measurements. The standards do not provide adoption percentages or measured savings; do not derive these from Recommended flags.
9. Reading the registry programmatically
The IANA page is the source of truth for current assignments. For repeatable internal documentation, save the registry snapshot or record the date, then compare the fields relevant to your use case: name, value, DTLS-OK, Recommended, reference, and comment. Preserve the original reference link for each entry. Treat draft references and obsolete comments as meaningful status information, not as incidental notes.
For an inventory report, a useful record might contain the group name, decimal and hex code point, registry snapshot date, reference, and the specific client/server versions you verified. Keep registry facts separate from implementation observations so later readers can tell which claims are assignments and which came from deployment testing.
10. FAQ
Are supported groups just elliptic curves?
No. The registry now includes KEM-based methods and hybrids as well as elliptic-curve groups.
Is MLKEM768 the same registry entry as X25519MLKEM768?
No. MLKEM768 is a standalone entry; X25519MLKEM768 combines ML-KEM-768 with X25519 ECDHE.
Does a hybrid group make my TLS certificate post-quantum?
No. It changes key establishment. Authentication and certificate signatures are separate mechanisms.
Which RFC defines the three standardized hybrids?
RFC 10024 defines the three ML-KEM/ECDHE TLS 1.3 groups. RFC 9954 defines the general hybrid key-exchange framework.
Can I infer browser support from the IANA Recommended flag?
No. Verify the specific browser, operating system, TLS library, server, and versions in your connection path.
11. Capture TLS documentation with ScreenshotNeo
When reviewing protocol changes, developers often need a stable visual record of registry entries, RFC sections, or vendor configuration pages. ScreenshotNeo is a website screenshot API and MCP server from ScreenshotNeo. A GET request can return a PNG, JPEG, WebP, or PDF capture. Its API also supports full-page capture, CSS selector targeting, custom headers, cookies, JavaScript, wait conditions, and bulk capture; see the API documentation for parameter details.
Or skip the browser setup
Use a one-call API request to capture a page such as the IANA registry. Replace the target URL as needed. See the ScreenshotNeo API docs for options and response details.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://www.iana.org/assignments/tls-parameters -o shot.webpScreenshotNeo accepts cookie and consent banners like a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and billing status. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 shots.
Create a free ScreenshotNeo account for 1,000 screenshots a month with no card.
Sources and snapshot note
Registry values and recommendation flags in this article reflect the IANA snapshot checked on 2026-09-29 UTC and can change. The primary sources are the IANA TLS Parameters registry, RFC 10024, and RFC 9954. The registry and RFCs do not establish universal implementation support or provide a cross-vendor compatibility matrix.
