What happens to Go's post-quantum TLS default when a service sets tls.Config.CurvePreferences explicitly?

## The field ```go type Config struct { // CurvePreferences contains the elliptic curves and key exchange // mechanisms that will be used in an ECDHE handshake, in preference order. CurvePreferences []CurveID // ... } ``` Two properties of this field decide the whole answer, and both surprise people. **It is an allow-list, not an addition.** Whatever you put in the slice is the complete set of groups the handshake may use. Nothing outside the slice is negotiable. There is no "defaults plus mine" mode. **`nil` is not "none", it is "Go decides".** An unset `CurvePreferences` hands the choice to the standard library's own preference list, and that list is what Go 1.24 changed by putting `X25519MLKEM768` at the front. This is the ordinary Go convention of a zero value meaning a sensible default, and here it means the security-relevant default tracks your toolchain automatically. ## The trap Put those two together and you get the failure this leaf exists for: ```go cfg := &tls.Config{ CurvePreferences: []tls.CurveID{tls.X25519, tls.CurveP256}, } ``` That line was good advice for years — pin the curves, drop the weak ones, be explicit. On Go 1.24 and later it is a downgrade. It compiles, it passes review, it looks *more* hardened than the config next to it, and it removes post-quantum key exchange from every connection the service makes. Nothing warns you. The handshake succeeds; it just negotiates a classical curve. This is the reason a Go upgrade alone does not tell you your fleet got post-quantum protection. The only way to know is to look: audit every `tls.Config` literal for a non-nil `CurvePreferences`, and count real handshakes by negotiated group (recent Go exposes it as `ConnectionState.CurveID`) rather than trusting the release notes. ## The three postures Once you understand the field as an ordered allow-list, all three deliberate configurations fall out of it. **Track the defaults — leave it nil.** The best choice for almost every service. You inherit whatever the toolchain considers current, which means the next protocol default arrives with your next Go upgrade instead of requiring a code change in every repository. **Keep an explicit list but lead with the hybrid group.** ```go cfg := &tls.Config{ CurvePreferences: []tls.CurveID{tls.X25519MLKEM768, tls.X25519, tls.CurveP256}, } ``` Use this when a policy genuinely requires a written-down list. Understand that you have now taken ownership of keeping it current: the next hybrid group Go adds will not appear in your handshakes until someone edits this slice. **Force the hybrid group — list only it.** ```go cfg := &tls.Config{ CurvePreferences: []tls.CurveID{tls.X25519MLKEM768}, } ``` This converts a silent downgrade into a loud failure: a peer that does not support the group cannot complete the handshake. That is exactly what you want between two endpoints you control, and exactly what you do not want facing partners whose stacks you cannot upgrade. ## Ordering matters, not just membership The slice is a *preference order*. In TLS 1.3 the client sends key shares for its top preferences and the server picks; if the server prefers a group for which the client sent no share, the protocol recovers with a HelloRetryRequest — correct, but it costs an extra round trip. Putting a group in the list that the other side is unlikely to want first is therefore a latency decision as well as a security one. ## The run-time lever `GODEBUG=tlsmlkem=0` disables the hybrid group without any code change, in a single process or across a fleet through the environment. It exists precisely so an operator can back out of a new protocol default at 3am without a rebuild. Treat it as an incident tool with an expiry date, not as configuration: it is fleet-wide and blunt, whereas a `CurvePreferences` list on one client config is surgical. If exactly one partner endpoint is broken, the code-level fix scoped to that destination is the better answer, because it leaves every other connection protected. ## The review habit When you see a `CurvePreferences` in a diff, ask one question: what does this *remove*? The field never adds anything. Every entry not in the slice is off, including entries that did not exist when the slice was written.