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: ``` 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. 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. [1] https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization <https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization> [2] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ <https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/> [3] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 <https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8> [4] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme <https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme> [5] https://docs.openssl.org/3.4/man3/SSL_get0_group_name/ <https://docs.openssl.org/3.4/man3/SSL_get0_group_name/> [6] https://docs.openssl.org/3.4/man3/SSL_get_peer_signature_nid/ <https://docs.openssl.org/3.4/man3/SSL_get_peer_signature_nid/> Thanks, Steven
