Hi William, > I find it confusing in the TLS context where everything is named either an > algorithm or a signature. group seems to be a common name for that, wouldn't > it > be better to use it? Maybe something like PP2_SUBTYPE_SSL_GROUP ?
I am aligned with that as "group" is used in TLS library APIs for accessing key exchange and is also used in the TLS IANA registry. > What's the difference between PP2_SUBTYPE_SSL_SIG_SCHEME and > PP2_SUBTYPE_SSL_SIG_SCHEME_ALG ? Ah, this was a mistype. They are meant to be the same. Per your previous suggestion, I think PP2_SUBTYPE_SSL_SIG_SCHEME makes sense. I can go ahead and start on a patch for PP2_SUBTYPE_SSL_GROUP and PP2_SUBTYPE_SSL_SIG_SCHEME unless you see any other blockers to discuss. Thanks, Steven On 9/8/25, 9:26 AM, "William Lallemand" <[email protected] <mailto:[email protected]>> wrote: Hello Steven, On Fri, Aug 29, 2025 at 10:34:01PM +0000, Collison, Steven wrote: > Hello, > > NIST, the IETF, and other groups are standardizing new cryptographic > algorithms[1][2] that are resistant to attacks by a quantum computer. > Backends behind HAProxy or behind other products that produce Proxy Protocol > version 2 would like to determine if the “frontend” TLS connection used Post > Quantum TLS(PQTLS) algorithms for their own auditing purposes and business > logic. Proxy Protocol currently has two TLVs that help with this use case: > ``` PP2_SUBTYPE_SSL_KEY_ALG: The server certificate public key type > PP2_SUBTYPE_SSL_SIG_ALG: The signature algorithm used to sign the end > entity(leaf) server certificate. ``` > > However there are not yet TLVs defined to communicate the key exchange > algorithm[3](ex: secp256r1 and X25519MLKEM768 for a post quantum example) and > the signature scheme[4] used during the TLS handshake to sign the > ServerKeyExchange/CertificateVerify message. My question to the group is if > it makes sense to add missing TLVs to cover key exchange algorithm and > handshake signature algorithm. If so, I can create a patch to register TLV > code points in proxy_protocol.txt. These TLVs will also be useful outside of > the PQTLS context for backends that want to audit existing key exchange and > handshake signature algorithm usage. Here is a first idea on how to define > the TLVs: I agree, we clearly need to define these TLV. > PP2_SUBTYPE_SSL_KX_ALG: US-ASCII name of the key exchange group > negotiated. I find it confusing in the TLS context where everything is named either an algorithm or a signature. group seems to be a common name for that, wouldn't it be better to use it? Maybe something like PP2_SUBTYPE_SSL_GROUP ? > PP2_SUBTYPE_SSL_SIG_SCHEME: US-ASCII name of the SignatureScheme > negotiated. > I chose `PP2_SUBTYPE_SSL_SIG_SCHEME_ALG` to differentiate between the > existing `PP2_SUBTYPE_SSL_SIG_ALG` which is related to a signature on an X509 > certificate. What's the difference between PP2_SUBTYPE_SSL_SIG_SCHEME and PP2_SUBTYPE_SSL_SIG_SCHEME_ALG ? I feel like these are the same things. > For implementation of these TLVs within HAProxy, later versions of Openssl > support the SSL_get_negotiated_group/SSL_get0_group_name[5] and > SSL_get_signature_nid[6] functions to retrieve this information from the > session. For this we already have the ssl_fc_curve sample fetch which can be used, maybe we should rename it into ssl_fc_group at some point. > I can imagine a future use case where backends will be interested in the > signature algorithms used on each X509 certificate in the chain(beyond what > PP2_SUBTYPE_SSL_SIG_ALG provides), but due to the complexity of how to > propagate this info, I think it can be considered out of scope of this > discussion. We would probably need to store a list of sigalgs as bytes, like it's done in the clienthello for example. > Thanks, > Steven Regards, -- William Lallemand
