It can be useful for a TLS server to know (e.g., to log) whether or not a HelloRetryRequest was performed. An example use case is with the increased adoption of PQC and servers doing HRRs depending on whether the client included the X25519MLKEM768 keyshare or not in the ClientHello. With https://github.com/golang/go/issues/67516, we now get the CurveID exposed (yay), but that only provides the final negotiated keygroup, which could be arrived at with or without an HRR; to debug and troubleshoot connections, being able to e.g., log whether an HRR took place would be useful.
To this end, I'd like to propose to expose testingOnlyDidHRR from the ConnectionState in a similar manner as the CurveID; perhaps simply named as DidHRR bool.
Comment From: FiloSottile
A ConnectionState.HelloRetryRequest bool sounds good to me.
I wonder if we should also expose in ClientHelloInfo whether it's a HRR.
/cc @golang/security
Comment From: wwqgtxx
There's a similar issue regarding unexported fields in ConnectionState.
Following #27125, ExportKeyingMaterial is implemented through a private ekm field.
This is fine for most users, but third-party TLS libraries cannot construct a fully functional tls.ConnectionState object on their own.
Current http/net libraries use the connectionStater interface to assign internal state values, which only accepts tls.ConnectionState objects returned by the implementor. TLSHandshakeDone in net/http/httptrace also has the same limitation.
So, should we allow legal ways to set the ekm field of ConnectionState, such as by adding a public setter function?
Comment From: aclements
This proposal has been added to the active column of the proposals project and will now be reviewed at the weekly proposal review meetings. — aclements for the proposal review group