crypto/tls: expose `testingOnlyDidHRR` from ConnectionState

[jschauma]

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 #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.

[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

[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?

[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

[aclements]

@FiloSottile or @rolandshoemaker (or anyone else), could you write up the concrete proposal based on #74425 (comment)? I think it's just to add a HelloRetryRequest bool field to ConnectionState, though I'd like to see a doc comment, too. Thanks!

@wwqgtxx , that sounds like a separate proposal to me.

[rolandshoemaker]

The concrete proposal here is:

type ConnectionState struct {
    ...

    // HelloRetryRequest is true if we sent a Hello Retry Request if we are a
    // server, or if we recieved a Hello Retry Request if we are a client.
    HelloRetryRequest bool
}

type ClientHelloInfo struct {
    ...

    // HelloRetryRequest is true if the Client Hello was sent in response to a
    // Hello Retry Request message.
    HelloRetryRequest bool
}