Draft: draft-ietf-tls-tls13

Commentary: Remove point format negotiation . 
 Per WG discussion .
Paragraph (version A):
ECDHE parameters for both clients and servers are encoded in the
opaque key_exchange field of the ClientKeyShareOffer or
ServerKeyShare structures.  The opaque value conveys the Elliptic
Curve Diffie-Hellman public value (ecdh_Y) represented as a byte
string ECPoint.point, which can represent an elliptic curve point in
uncompressed or compressed format.
Paragraph (version B):
ECDHE parameters for both clients and servers are encoded in the
opaque key_exchange field of the ClientKeyShareOffer or
ServerKeyShare structures.  The opaque value conveys the Elliptic
Curve Diffie-Hellman public value (ecdh_Y) represented as a byte
string ECPoint.point.
Paragraph (version B):
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.
Paragraph (version B):
Note: Versions of TLS prior to 1.3 permitted point negotiation; TLS
curve.
Paragraph (version A):
A client that proposes ECC cipher suites in its ClientHello message
SHOULD send the Supported Point Formats Extension to indicate the
elliptic curve point formats it supports.  If the Supported Point
Formats Extension is indeed sent, it MUST contain the value 0
(uncompressed) as one of the items in the list of point formats.
Paragraph (version A):
Three point formats are included in the definition of ECPointFormat
above.  The uncompressed point format is the default format in that
implementations of this document MUST support it for all of their
supported curves.  Compressed point formats reduce bandwidth by
including only the x-coordinate and a single bit of the y-coordinate
of the point.  Implementations of this document MAY support the
ansiX962_compressed_prime and ansiX962_compressed_char2 formats,
where the former applies only to prime curves and the latter applies
only to characteristic-2 curves.  (These formats are specified in
X962.)  Values 248 through 255 are reserved for private use.
Paragraph (version A):
The ECPointFormat name space is maintained by IANA.  See iana-
considerations for information on how new value assignments are
added.
Paragraph (version A):
Items in ec_point_format_list are ordered according to the sender's
preferences (favorite choice first).
Paragraph (version A):
If the client supplies a Supported Points Formats Extension in the
ClientHello, the server may send its own Supported Points Format
extension in the ServerHello.  This extension allows a server to
enumerate the point formats it can parse (for the curve that will
appear in its ServerKeyExchange message when using the ECDHE_ECDSA or
ECDHE_RSA key exchange algorithm, or for the curve that is used in
the server's public key that will appear in its Certificate message
when using the ECDH_ECDSA or ECDH_RSA key exchange algorithm).
Paragraph (version A):
The server's Supported Point Formats Extension has the same structure
and semantics as the client's Supported Point Formats Extension.
Note that the server may include items that were not found in the
client's list (e.g., the server may prefer to receive points in
compressed format even when a client cannot parse this format: the
same client may nevertheless be capable of outputting points in
compressed format).
Paragraph (version A):
An endpoint that receives a hello message containing a Supported
Point Formats Extension MUST respect the sender's choice of point
formats during the handshake.  If no Supported Point Formats
Extension is received this is equivalent to an extension allowing
only the uncompressed point format.