Change:
(Let me know if you think this is sufficiently non-trivial that it deserves a mailing list posting. It is a wire format change, but I think a fairly boring one.) Only the outer length prefix is necessary, not the inner one. Named groups can just as easily take a byte string with known length rather than need to parse fields out. This is consistent with the definition of DigitallySigned.signature; the signature is an opaque field which is passed as a byte string into the corresponding signature algorithm. The definition of rsapsssha256 does not define an inner u16 length prefix. It simply takes the opaque byte string and passes it into the rsapsssha256 function. (In fact, this change means KeyShareEntry and DigitallySigned structures exactly parallel.) This also fixes some references to non-existent structures like ECPoint and dh_Yc. (Those seem to be remnants of TLS 1.2.)

Discussion:
Indicates support of the corresponding named curve.  Note that some curves are also recommended in ANSI X9.62 X962 and FIPS 186-4 <del> DSS.  Others are recommended in I-D.irtf-cfrg-curves.  Values 0xFE00 through 0xFEFF are reserved for private use. </del> <ins> DSS.  Others are recommended in RFC7748.  Values 0xFE00 through 0xFEFF are reserved for private use. </ins> Indicates support of the corresponding finite field group, defined

Diffie-Hellman DH parameters for both clients and servers are encoded in the opaque key_exchange field of a KeyShareEntry in a KeyShare structure.  The opaque value contains the Diffie-Hellman public value <del> (dh_Y = g^X mod p), encoded as a big-endian integer, padded with zeros to the size of p. </del> <ins> (Y = g^X mod p), encoded as a big-endian integer, padded with zeros to the size of p. </ins> Note: For a given Diffie-Hellman group, the padding results in all public keys having the same length. <del> %%% Key Exchange Messages opaque dh_Y<1..2^16-1>; </del> 6.3.2.3.2. ECDHE parameters for both clients and servers are encoded in the the opaque key_exchange field of a KeyShareEntry in a KeyShare structure. <del> The opaque value conveys the Elliptic Curve Diffie-Hellman public value (ecdh_Y) represented as a byte string ECPoint.point. %%% Key Exchange Messages opaque point <1..2^8-1>; For secp256r1, secp384r1 and secp521r1, this is the byte string representation of an elliptic curve point following the conversion routine in Section 4.3.6 of ANSI X9.62 X962.  For x25519 and x448, this is raw opaque octet-string representation of point (in the format those functions use), 32 octets for x25519 and 56 octets for x448. </del> <ins> For secp256r1, secp384r1 and secp521r1, the contents are the byte string representation of an elliptic curve public value following the conversion routine in Section 4.3.6 of ANSI X9.62 X962. </ins> Although X9.62 supports multiple point formats, any given curve MUST specify only a single point format.  All curves currently specified in this document MUST only be used with the uncompressed point format (the format for all ECDH functions is considered uncompressed). <ins> For x25519 and x448, the contents are the byte string inputs and outputs of the corresponding functions defined in RFC7748, 32 bytes for x25519 and 56 bytes for x448. </ins> Note: Versions of TLS prior to 1.3 permitted point negotiation; TLS 1.3 removes this feature in favor of a single point format for each curve.

ECDH functions are used as follows: <del> The public key to put into ECPoint.point structure is the result of applying the ECDH function to the secret key of appropriate length (into scalar input) and the standard public basepoint (into u-coordinate point input). </del> <ins> The public key to put into the KeyShareEntry.key_exchange structure is the result of applying the ECDH function to the secret key of appropriate length (into scalar input) and the standard public basepoint (into u-coordinate point input). </ins> The ECDH shared secret is the result of applying ECDH function to the secret key (into scalar input) and the peer's public key (into