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.
If it's required to transport such information and there's no other way, then I'd say yes, it would make sense. > Here is a first idea on how to define > the TLVs: > > ``` > PP2_SUBTYPE_SSL_KX_ALG: US-ASCII name of the key exchange group negotiated. > 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. > > 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 these I can't judge, I'd let William have a look (in case he sees other use cases that we might want to also factor in). > 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. Indeed, let's not over-engineer at this point. Thanks, Willy
