Draft: draft-ietf-tls-tls13

Commentary: MUST include all the original shares , plus the one the server selected . Otherwise we create a downgrade opportunity . 
 By using the same numbering space for ecdhe and dhe groups . Probably a comment for draft - dkg 
 Currently the way you detect that ServerHello is a " try - again " is to check the DL / ECC extensions and see if it matches the CKE . This seems inelegant . Options include : Leave as - is Have some explicit rejection indicator Add a new message type , though it is pretty much going to have the same contents .
Paragraph (version B):
Merge in support for ECC from RFC 4492 but without explicit
curves.
Paragraph (version B):
Remove the unnecessary length field from the AD input to AEAD
ciphers.
Paragraph (version A):
These goals are achieved by the handshake protocol, which can be
summarized as follows: The client sends a ClientHello message which
contains a random nonce (ClientHello.random), its preferences for
Protocol Version, Cipher Suite, and a variety of extensions.  In the
same flight, it sends a ClientKeyExchange message which contains its
share of the parameters for key agreement for some set of expected
server parameters (DHE/ECDHE groups, etc.).
Paragraph (version A):
The server responds to the ClientHello with a ServerHello message, or
else a fatal error will occur and the connection will fail.  The
ServerHello contains the server's nonce (ServerHello.random), the
server's choice of the Protocol Version, Session ID and Cipher Suite,
and the server's response to the extensions the client offered.
Paragraph (version A):
If the client has provided a ClientKeyExchange with an appropriate
set of keying material, the server can then generate its own keying
material share and send a ServerKeyExchange message which contains
its share of the parameters for the key agreement.  The server can
now compute the shared secret.  At this point, a ChangeCipherSpec
message is sent by the server, and the server copies the pending
Cipher Spec into the current Cipher Spec.  The remainder of the
server's handshake messages will be encrypted under that Cipher Spec.
Paragraph (version B):
These goals are achieved by the handshake protocol, which can be
summarized as follows: The client sends a ClientHello message which
contains a random nonce (ClientHello.random), its preferences for
Protocol Version, Cipher Suite, and a variety of extensions.  In the
same flight, it sends a ClientKeyShare message which contains its
share of the parameters for key agreement for some set of expected
server parameters (DHE/ECDHE groups, etc.).
Paragraph (version B):
If the client has provided a ClientKeyShare with an appropriate set
of keying material, the server responds to the ClientHello with a
ServerHello message.  The ServerHello contains the server's nonce
(ServerHello.random), the server's choice of the Protocol Version,
Session ID and Cipher Suite, and the server's response to the
extensions the client offered.
Paragraph (version B):
The server can then generate its own keying material share and send a
ServerKeyShare message which contains its share of the parameters for
the key agreement.  The server can now compute the shared secret.  At
this point, a ChangeCipherSpec message is sent by the server, and the
server copies the pending Cipher Spec into the current Cipher Spec.
The remainder of the server's handshake messages will be encrypted
under that Cipher Spec.
Paragraph (version B):
If no common cryptographic parameters can be negotiated, the server
will send a fatal alert.
Paragraph (version A):
When a client first connects to a server, it is required to send
the ClientHello as its first message.  The client can also send a
ClientHello in response to a HelloRequest or on its own initiative
in order to renegotiate the security parameters in an existing
connection.  Finally, the client will send a ClientHello when the
server has responded to its ClientHello with a ServerHello that
selects cryptographic parameters that don't match the client's
ClientKeyExchange.  In that case, the client MUST send the same
ClientHello (without modification) along with the new
ClientKeyExchange.
Paragraph (version B):
When a client first connects to a server, it is required to send
the ClientHello as its first message.  The client can also send a
ClientHello in response to a HelloRequest or on its own initiative
in order to renegotiate the security parameters in an existing
connection.  Finally, the client will send a ClientHello when the
server has responded to its ClientHello with a ServerHello that
selects cryptographic parameters that don't match the client's
ClientKeyShare.  In that case, the client MUST send the same
ClientHello (without modification) along with the new
ClientKeyShare.
Paragraph (version A):
A list of ClientKeyExchangeOffer values.
Paragraph (version A):
When one of the ClientKeyExchangeOffers is a Diffie-Hellman key, the
client SHALL encode it using ClientDiffieHellmanParams.  This
structure conveys the client's Diffie-Hellman public value (dh_Yc)
and the group which it is being provided for.
Paragraph (version A):
The server will send this message in response to a ClientHello
message when it was able to find an acceptable set of algorithms.
If it cannot find such a match, it will respond with a handshake
failure alert.
Paragraph (version B):
The named group for the key share offer.  This identifies the
specific key exchange method that the ClientKeyShareOffer
describes.  Finite Field Diffie-Hellman parameters are described
in ffdhe-param; Elliptic Curve Diffie-Hellman parameters are
described in ecdhe-param.
Paragraph (version B):
A list of ClientKeyShareOffer values.
Paragraph (version B):
Diffie-Hellman parameters for both clients and servers are encoded in
the opaque key_exchange field of the ClientKeyShareOffer or
ServerKeyShare structures.  The opaque value contains the Diffie-
Hellman public value (dh_Y = g^X mod p), encoded as a big-endian
integer.
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, which can represent an elliptic curve point in
uncompressed or compressed format.
Paragraph (version B):
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.
Paragraph (version B):
The server will send this message in response to a ClientHello
message when it was able to find an acceptable set of algorithms
and the client's ClientKeyShare message was acceptable.  If the
client proposed groups are not acceptable by the server, it will
respond with an insufficient_security fatal alert.
Paragraph (version B):
The server will send this message in response to a ClientHello
message when it was able to find an acceptable set of algorithms
but the client's ClientKeyShare message did not contain an
acceptable offer.  If it cannot find such a match, it will respond
with a handshake failure alert.
Paragraph (version B):
The group which the client MUST use for its new ClientHello.
Paragraph (version B):
The "server_version", "cipher_suite" and "extensions" fields have the
same meanings as their corresponding values in the ServerHello.  The
server SHOULD send only the extensions necessary for the client to
generate a correct ClientHello/ClientKeyShare pair.
Paragraph (version B):
Upon receipt of a HelloRetryRequest, the client MUST send a new
ClientHello/ClientKeyShare pair to the server.  The ClientKeyShare
MUST contain both the groups in the original ClientKeyShare as well
as a ClientKeyShareOffer consistent with the "selected_group" field.
I.e., it MUST be a superset of the previous ClientKeyShareOffer.
Paragraph (version B):
Upon re-sending the ClientHello/ClientKeyShare and receiving the
server's ServerHello/ServerKeyShare, the client MUST verify that the
selected ciphersuite and NamedGroup match that supplied in the
HelloRetryRequest.
Paragraph (version A):
This field indicates the signature algorithm that may be used.
The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
RFC3447 and DSA DSS, and ECDSA ECDSA, respectively.  The
"anonymous" value is meaningless in this context but used in
server-key-exchange-message.  It MUST NOT appear in this
extension.
Paragraph (version A):
The semantics of this extension are somewhat complicated because the
cipher suite indicates permissible signature algorithms but not hash
algorithms.  server-certificate and server-key-exchange-message
describe the appropriate rules.
Paragraph (version A):
If the client supports only the default hash and signature algorithms
(listed in this section), it MAY omit the signature_algorithms
extension.  If the client does not support the default algorithms, or
supports other hash and signature algorithms (and it is willing to
use them for verifying messages sent by the server, i.e., server
certificates and server key exchange), it MUST send the
signature_algorithms extension, listing the algorithms it is willing
to accept.
Paragraph (version B):
This field indicates the signature algorithm that may be used.
The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
RFC3447 and DSA DSS, and ECDSA ECDSA, respectively.  The
"anonymous" value is meaningless in this context but used in
server-key-share-message.  It MUST NOT appear in this extension.
Paragraph (version B):
The semantics of this extension are somewhat complicated because the
cipher suite indicates permissible signature algorithms but not hash
algorithms.  server-certificate and server-key-share-message describe
the appropriate rules.
Paragraph (version B):
If the client supports only the default hash and signature algorithms
(listed in this section), it MAY omit the signature_algorithms
extension.  If the client does not support the default algorithms, or
supports other hash and signature algorithms (and it is willing to
use them for verifying messages sent by the server, i.e., server
certificates and server key share), it MUST send the
signature_algorithms extension, listing the algorithms it is willing
to accept.
Paragraph (version B):
When sent by the client, the "supported_groups" extension indicates
the named groups which the client supports, ordered from most
preferred to least preferred.
Paragraph (version B):
Note: In versions of TLS prior to TLS 1.3, this extension was named
"elliptic curves" and only contained elliptic curve groups.  See
RFC4492 and I-D.ietf-tls-negotiated-ff-dhe.
Paragraph (version B):
Items in named_curve_list are ordered according to the client's
preferences (favorite choice first).
Paragraph (version B):
The client MUST supply a "named_groups" extension containing at least
one group for each key exchange algorithm (currently DHE and ECDHE)
for which it offers a cipher suite.  If the client does not supply a
"named_groups" extension with a compatible group, the server MUST NOT
negotiate a cipher suite of the relevant type.  For instance, if a
client supplies only ECDHE groups, the server MUST NOT negotiate
finite field Diffie-Hellman.  If no acceptable group can be selected
across all cipher suites, then the server MUST generate a fatal
"handshake_failure" alert.
Paragraph (version B):
NOTE: A server participating in an ECDHE-ECDSA key exchange may use
different curves for (i) the ECDSA key in its certificate, and (ii)
the ephemeral ECDH key in the ServerKeyExchange message.  The server
must consider the supported groups in both cases.
Paragraph (version B):
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 B):
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 B):
The ECPointFormat name space is maintained by IANA.  See iana-
considerations for information on how new value assignments are
added.
Paragraph (version B):
Items in ec_point_format_list are ordered according to the sender's
preferences (favorite choice first).
Paragraph (version B):
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,
ECDHE_RSA, or ECDH_anon 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 B):
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 B):
An endpoint that receives a ServerHello 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.
Paragraph (version A):
Any data included in EarlyData is not integrated into the handshake
hashes directly.  E.g., if the ClientKeyExchange is included in
EarlyData, then the handshake hashes consist of ClientHello +
ServerHello, etc.  However, because the ClientKeyExchange is in a
ClientHello extension, it is still hashed transitively.  This
procedure guarantees that the Finished message covers these messages
even if they are ultimately ignored by the server (e.g., because it
is sent to a TLS 1.2 server).  TLS 1.3 servers MUST understand
messages sent in EarlyData, and aside from hashing them differently,
MUST treat them as if they had been sent immediately after the
ClientHello.
Paragraph (version B):
Any data included in EarlyData is not integrated into the handshake
hashes directly.  E.g., if the ClientKeyShare is included in
EarlyData, then the handshake hashes consist of ClientHello +
ServerHello, etc.  However, because the ClientKeyShare is in a
ClientHello extension, it is still hashed transitively.  This
procedure guarantees that the Finished message covers these messages
even if they are ultimately ignored by the server (e.g., because it
is sent to a TLS 1.2 server).  TLS 1.3 servers MUST understand
messages sent in EarlyData, and aside from hashing them differently,
MUST treat them as if they had been sent immediately after the
ClientHello.
Paragraph (version A):
Previous versions of TLS before 1.3 allowed the server to specify a
custom DHE group.  This version of TLS requires the use of specific
named groups.  I-D.gillmor-tls-negotiated-dl-dhe describes a
mechanism for negotiating such groups.
Paragraph (version A):
This message will be sent immediately after the ServerHello
message if the client has provided a ClientKeyExchange message
which is compatible with the selected cipher suite and group
parameters.
Paragraph (version B):
This message will be sent immediately after the ServerHello
message if the client has provided a ClientKeyShare message which
is compatible with the selected cipher suite and group parameters.
Paragraph (version B):
The named group for the key share offer.  This identifies the
selected key exchange method from the ClientKeyShare message
(client-key-share-message), identifying which value from the
ClientKeyShareOffer the server has accepted as is responding to.
Paragraph (version A):
If this message is sent, it MUST be sent immediately after the
server's ChangeCipherSpec (and hence as the first handshake
message after the ServerKeyExchange).
Paragraph (version B):
If this message is sent, it MUST be sent immediately after the
server's ChangeCipherSpec (and hence as the first handshake
message after the ServerKeyShare).
Paragraph (version A):
The server MUST send a Certificate message whenever the agreed-
upon key exchange method uses certificates for authentication
(this includes all key exchange methods defined in this document
except DH_anon).  This message will always immediately follow the
ChangeCipherSpec which follows the server's ServerKeyExchange
message.
Paragraph (version B):
The server MUST send a Certificate message whenever the agreed-
upon key exchange method uses certificates for authentication
(this includes all key exchange methods defined in this document
except DH_anon).  This message will always immediately follow the
ChangeCipherSpec which follows the server's ServerKeyShare
message.
Paragraph (version B):
All ECDH calculations (including parameter and key generation as well
as the shared secret calculation) are performed according to [6]
using the ECKAS-DH1 scheme with the identity map as key derivation
function (KDF), so that the premaster secret is the x-coordinate of
the ECDH shared secret elliptic curve point represented as an octet
string.  Note that this octet string (Z in IEEE 1363 terminology) as
output by FE2OSP, the Field Element to Octet String Conversion
Primitive, has constant length for any given field; leading zeros
found in this octet string MUST NOT be truncated.
Paragraph (version B):
This document also uses two registries originally created in RFC4492.
IANA [should update/has updated] it to reference this document.  The
registries and their allocation policies are listed below.
Paragraph (version B):
TLS NamedCurve registry: Future values are allocated via IETF
Consensus RFC2434.
Paragraph (version B):
TLS ECPointFormat Registry: Future values are allocated via IETF
Consensus RFC2434.