Draft: draft-ietf-tls-tls13

Commentary: ( 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  . ( Those seem to be remnants of TLS 1.2 . )
Paragraph (version A):
Indicates support of the corresponding named curve.  Note that
some curves are also recommended in ANSI X9.62 X962 and FIPS 186-4
DSS.  Others are recommended in I-D.irtf-cfrg-curves.  Values
0xFE00 through 0xFEFF are reserved for private use.
Paragraph (version B):
Indicates support of the corresponding named curve.  Note that
some curves are also recommended in ANSI X9.62 X962 and FIPS 186-4
DSS.  Others are recommended in RFC7748.  Values 0xFE00 through
0xFEFF are reserved for private use.
Paragraph (version A):
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
(dh_Y = g^X mod p), encoded as a big-endian integer, padded with
zeros to the size of p.
Paragraph (version A):
ECDHE parameters for both clients and servers are encoded in the the
opaque key_exchange field of a KeyShareEntry in a KeyShare structure.
The opaque value conveys the Elliptic Curve Diffie-Hellman public
value (ecdh_Y) represented as a byte string ECPoint.point.
Paragraph (version A):
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.
Paragraph (version B):
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
(Y = g^X mod p), encoded as a big-endian integer, padded with zeros
to the size of p.
Paragraph (version B):
ECDHE parameters for both clients and servers are encoded in the the
opaque key_exchange field of a KeyShareEntry in a KeyShare structure.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
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).
Paragraph (version B):
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).