crypto/tls: automatic CurvePreferences ordering

[FiloSottile]

CurvePreferences (a legacy misnomer for key exchange mechanisms) are about to become a lot more complex with the post-quantum transition. For example on the client side we will want to send both a MLKEM768X25519 and a X25519 key share, while on the server side we might want to trigger a Hello Retry Request if it allows upgrading to PQ. All this complexity is both difficult to express in the current API, and an excessive burden to delegate to applications.

I propose we do the same thing we did for CipherSuites in #45430 and remove the preference order semantics and the implicit key share selection. The CurvePreferences list, if not nil, will be a list of enabled key exchanges, and the choice of which ones to prioritize and what key shares to send will be left with crypto/tls.

Changing the key share logic is allowed by the current docs. Removing the preference ordering is equivalent to #45430.

// CurvePreferences contains the elliptic curves that will be used in
// an ECDHE handshake, in preference order. If empty, the default will
// be used. The client will use the first preference as the type for
// its key share in TLS 1.3. This may change in the future.
CurvePreferences []CurveID

One day we might need a way for the application to pass on draft-ietf-tls-key-share-prediction hints from DNS, like ECH parameters, but the current CurvePreferences was anyway poorly suited for the nuanced semantics required to avoid downgrade attacks. (If an application simply passed the draft-ietf-tls-key-share-prediction hints as CurvePreferences, a DNS attacker could downgrade key exchanges from PQ to non-PQ. They would have to sort the list based on the hints, but also applying logic to allow key share reuse. That's unrealistic and I'd rather have the application pass on the raw DNS payload like with ECH.)

/cc @golang/security @golang/proposal-review

[gabyhelp]

Related Issues and Documentation

• crypto/tls: implement and enable X25519Kyber768Draft00 #67061 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[mateusz834]

@FiloSottile Do you see a need for a new GODEBUG for this change? #45430 did not introduce one.

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

Am I understanding correctly that the proposal is to switch tls.Config.CurvePreferences from an ordered preference list to, effectively, a set, where std always provides the preference order?

Given that we haven't had any complaints about the equivalent change to cipher suites, I'm leaning toward not providing a GODEBUG. If we do end up adding a GODEBUG, it would have to either do nothing in FIPS mode or panic.

[FiloSottile]

Am I understanding correctly that the proposal is to switch tls.Config.CurvePreferences from an ordered preference list to, effectively, a set, where std always provides the preference order?

Yep!

Given that we haven't had any complaints about the equivalent change to cipher suites, I'm leaning toward not providing a GODEBUG. If we do end up adding a GODEBUG, it would have to either do nothing in FIPS mode or panic.

I'm not sure this interacts that much with FIPS mode. In FIPS mode the set of supported CurvePreferences is thinned to only the NIST-approved ones, but ordering is mostly unaffected.

I'm ok with not adding a GODEBUG.

[aclements]

Based on the discussion above, this proposal seems like a likely accept.

The proposal is to change tls.Config.CurvePreferences from a preference-ordered list to a set of acceptable curves.

        // CurvePreferences contains the elliptic curves that will be used in
        // an ECDHE handshake. The order of the list is ignored, and a curve
        // is chosen from this list using an internal preference order.
	// If empty, the default will be used.
        CurvePreferences []CurveID