Skip to content

Add TLS 1.3 group information to various SSL/TLS methods and classes #132239

Description

@x509cert

As we move toward post quantum crypto, selecting and/or detecting hybrid TLS 1.3 groups (ie; Eliptic Curve Crypto [ECC] + MLKEM) is paramount.

Today, this data is not exposed through various .NET methods, such as the ASP.NET code below.

app.MapGet("/", (HttpContext ctx) =>
{
    var tls = ctx.Features.Get<ITlsHandshakeFeature>();
    return Results.Json(new
    {
        Protocol = tls?.Protocol.ToString() ?? "Unknown",
        CipherSuite = tls?.NegotiatedCipherSuite?.ToString() ?? "Unknown"
    });
});

An update would include some like this:

        CipherGroup = tls?.NegotiatedGroup?.ToString() ?? "Unknown"

This would require additional pub enums that include the group value:

    public enum TlsSupportedGroup : ushort
    {
        // Classical ECDHE (RFC 8446 §4.2.7, RFC 8422).
        secp256r1 = 0x0017,   // NIST P-256
        secp384r1 = 0x0018,   // NIST P-384
        x25519    = 0x001D,   // RFC 7748
 
        // Hybrid ECDHE + ML-KEM (draft-kwiatkowski-tls-ecdhe-mlkem).
        SecP256r1MLKEM768  = 0x11EB,
        X25519MLKEM768     = 0x11EC,
        SecP384r1MLKEM1024 = 0x11ED,
    }

This list is not complete, but I doubt you want the entire list; it runs to about 100-ish values.

For bonus points; the following would be useful:

IsHybrid() - classic AND MLKEM
IsPostQuantum() - MLKEM OR IsHybrid()
IsPurePostQuantum() - MLKEM
IsClassic()  - classic

Note: the group is negotiated separately from the ciphersuite in TLS 1.3.

If you want more info - just ask.

Activity

  1. dotnet-policy-service commented on Aug 12, 2026

    @dotnet-policy-service
    Contributor

    Tagging subscribers to this area: @dotnet/area-system-runtime
    See info in area-owners.md if you want to be subscribed.

  2. dotnet-policy-service commented on Aug 12, 2026

    @dotnet-policy-service
    Contributor

    Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
    See info in area-owners.md if you want to be subscribed.

  3. bartonjs commented on Aug 12, 2026

    @bartonjs
    Member

    Personally, I think exposing the negotiated value for the TLS Supported Group is goodness (ideally using the wire value, a la ciphersuites). But I'd leave out the policy/judgment/classification "IsHybrid", etc. Names like "IsClassic" or "IsTraditional" don't age well.

    Also, looks like the hybrid PQC exchanges are no longer draft, they're now IETF RFC 10024 (as of two days ago)

  4. added this to the 12.0.0 milestone on Aug 13, 2026
  5. removed
    untriagedNew issue has not been triaged by the area owner
    on Aug 13, 2026
  6. rzikm commented on Aug 13, 2026

    @rzikm
    Member

    Triage: too late for 11.0, but given how the space evolves, we should look at it for 12.0

  7. added theissue type on Aug 13, 2026
  8. self-assigned this
    on Aug 26, 2026
  9. rzikm commented on Aug 26, 2026

    @rzikm
    Member

    It seems that the only platform that surfaces the algorithm is currently OpenSSL, I don't see a way to access it on the other platforms. Shipping a new property that gives useful information only on a single platform is difficult, so we hold off until there is support at least for Schannel.

  10. rzikm commented on Aug 27, 2026

    @rzikm
    Member

    Pushed a feasibility prototype branch exploring exposing the negotiated TLS 1.3 supported group (named/key-exchange group, including hybrid PQC groups such as X25519MLKEM768):

    Branch: https://github.com/rzikm/dotnet-runtime/tree/rzikm/tls-negotiated-group

    Highlights:

    • New [CLSCompliant(false)] public enum TlsSupportedGroup : ushort using IANA wire code points, generated from the IANA registry via a T4 template (same technique as TlsCipherSuite).
    • New SslStream.NegotiatedGroup property plumbed through per-platform SslConnectionInfo.
    • OpenSSL implementation via SSL_get_negotiated_group (3.0+), mapping NID -> IANA value (provider/unknown groups carry the IANA id in the low bits).

    Platform feasibility (verified against primary sources): only OpenSSL exposes the negotiated group.

    • Windows/Schannel - no QueryContextAttributes attribute returns it (szExchange/aiExch give only the key-exchange algorithm), still true on 24H2/Server 2025.
    • macOS/Network.framework - sec_protocol_metadata exposes ciphersuite + protocol only.
    • Android/JSSE+Conscrypt - no public accessor.

    On these platforms the property reports 0 (unavailable), mirroring how NegotiatedCipherSuite is platform-gated. This is unapproved public API - the branch is prototype/evidence for API review, not a PR.

    Note

    This comment was generated with the assistance of GitHub Copilot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions