Hello,
I am experimenting with the entire QUIC stack on linux for a server framework built on top, I noticed some issue whilst connecting with other library that don't offer the same key exchange (or offer a limited variety)
I tested a patch locally and I was wondering if it was useful to push the idea here
Important note : this patch was made with the help of GPT 5.5 (finding the missing part) and Claude (applying the fix to the main code), I did manual verification and ran the test, tho I cannot say if this add anything to the limited scope of SwiftTLS.
The branch is here https://github.com/hironichu/swift-tls/tree/feature/secp256r1-key-exchange
NamedGroup.secp256 (0x0017) was declared but had no ephemeral key implementation, so configuring keyExchangeGroup = .secp256 failed on both sides: the client's startHandshake threw handshakeError and the server hardcoded its supported groups to
[.x25519MLKEM768, .secp384, .x25519].
- Add
P256EphemeralKey and the corresponding .p256 cases / a .secp256 case to generateEphemeralKeyForNamedGroup, mirroring the existing P-384 implementation.
- Route the client
startHandshake through the shared generateEphemeralKeyForNamedGroup helper instead of a duplicated inline switch, so client and server derive key shares from one path.
- Let the server honor the configured group via a new
fixedKeyExchangeGroup on its configuration; default offered groups are unchanged, so secp256 is opt-in and the change is backward compatible.
- Add a client-to-server P-256 handshake test.
Motivation: interop with P-256-only TLS 1.3 / QUIC peers.
Hello,
I am experimenting with the entire QUIC stack on linux for a server framework built on top, I noticed some issue whilst connecting with other library that don't offer the same key exchange (or offer a limited variety)
I tested a patch locally and I was wondering if it was useful to push the idea here
Important note : this patch was made with the help of GPT 5.5 (finding the missing part) and Claude (applying the fix to the main code), I did manual verification and ran the test, tho I cannot say if this add anything to the limited scope of SwiftTLS.
The branch is here https://github.com/hironichu/swift-tls/tree/feature/secp256r1-key-exchange
NamedGroup.secp256(0x0017) was declared but had no ephemeral key implementation, so configuringkeyExchangeGroup = .secp256failed on both sides: the client'sstartHandshakethrewhandshakeErrorand the server hardcoded its supported groups to[.x25519MLKEM768, .secp384, .x25519].P256EphemeralKeyand the corresponding.p256cases / a.secp256case togenerateEphemeralKeyForNamedGroup, mirroring the existing P-384 implementation.startHandshakethrough the sharedgenerateEphemeralKeyForNamedGrouphelper instead of a duplicated inline switch, so client and server derive key shares from one path.fixedKeyExchangeGroupon its configuration; default offered groups are unchanged, so secp256 is opt-in and the change is backward compatible.Motivation: interop with P-256-only TLS 1.3 / QUIC peers.