Server Hello should not contain supported_groups extension (extension.SupportedEllipticCurves)

[uumaro]

Your environment.

• Version: v2.0.9
• Browser: N/A

Pion includes both the supported_groups (also called elliptic_curves) and ec_point_formats extensions, whether sending a Client Hello or a Server Hello. (Refs: flight 1, flight 3 for Client Hello, flight 4 for Server Hello). ec_point_formats is fine in a Server Hello, but supported_groups is only defined for Client Hello.

The presence of supported_groups in Server Hello has emerged as a concrete distinguisher used to block Snowflake WebRTC connections in Russia:

Russian DPI check supported_groups extension in ServerHello payload (byte 0x5a in udp packet). It looks for DTLS packet header "magic" "16 FE FD" and then looks for "1D 00 17 00 18" at 0x5a offset.

I think that supported_groups does not belong in Server Hello. These are my reasons for thinking so:

1. Comparison with browser DTLS.

2. Go crypto/tls: clientHelloMsg contains supportedCurves and supportedPoints fields which may be marshaled, but serverHelloMsg only contains and may marshal supportedPoints.

3. RFC 8422 specifies both extensions for Client Hello, but only ec_point_formats for Server Hello.

   5.1. Client Hello Extensions

   This section specifies two TLS extensions that can be included with the ClientHello message as described in [RFC4366]: the Supported Elliptic Curves Extension and the Supported Point Formats Extension.

   5.2. Server Hello Extension

   This section specifies a TLS extension that can be included with the ServerHello message as described in [RFC4366], the Supported Point Formats Extension.

(Note, though, that in TLS 1.3, Server Hello may contain supported_groups—though TLS 1.3 also removes ec_point_formats. I don't think it's relevant for DTLS 1.2.)

[daenney]

This sounds very reasonable to me. If you're able and willing, feel free to submit a PR (with a test please) that fixes this inconsistency.