crypto/tls: allow early_data without pre_shared_key in ECH reject

[rbqvq]

As a part of origin report #79282 at BugHunter March 4.

---

Additionally, there's a Chrome/Edge/BoringSSL interoperability issue with ECH Reject + Early Data:

According to RFC 9849, Section 6.1: Offer ECH

7. When the client offers the "early_data" extension in ClientHelloInner, it MUST also include the "early_data" extension in ClientHelloOuter. This allows servers that reject ECH and use ClientHelloOuter to safely ignore any early data sent by the client per [RFC8446], Section 4.2.10.

Chrome/Edge/BoringSSL offers early_data in ClientHelloOuter but not PSKs.

Golang will throw a fatal alert if early_data offered but PSKs not offered.

This can cause Chrome/Edge/BoringSSL compatibility issues with ECH Reject + Early Data in QUIC scenarios.

[gabyhelp]

Related Issues

• crypto/tls: ECH decodeInnerClientHello incorrectly rejects ClientHello with GREASE values in supportedVersions #71642 (closed)
• crypto/tls: client should not fail if it sets an ECH config and the server rejects it #75240 (closed)
• crypto/tls: earlyTrafficSecret should use ClientHelloInner if ECH enabled #76283 (closed)
• crypto/tls: disable earlyData extension in SessionTicket if didHRR #76462
• crypto/tls: omit PSK in ECH outer client hello #79282
• crypto/tls: ClientHelloOuter should hide the actual ALPN list #71220

Related Code Changes

• [release-branch.go1.24] crypto/tls: use inner hello for earlyData when using QUIC and ECH
• crypto/tls: use inner hello for earlyData when using QUIC and ECH
• [release-branch.go1.25] crypto/tls: use inner hello for earlyData when using QUIC and ECH
• crypto/tls: skip unsupported ECH config versions

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

[dr2chase]

@rolandshoemaker

[dr2chase]

@neild