Draft: draft-ietf-tls-tls13

Commentary: This is just a WIP and needs review . PTAL . I know you do n't like the indication from the server but would like your opinion on other aspects . 
 ptal 
 could we change NamedGroup to be called KeyExchangeAlgorithm instead . It seems like that 's what it technically is after this change and will allow us to support other kinds of exchanges in the future like Post quantum algorithms in a more semantically friendly way than calling them a " named group " 
 I changed the server 's indicator to be SignatureAlgorithms . PTAL . 
 P.S. Also removed the server signing with PSK mode . Will move that to a separate PR .
Paragraph (version A):
Which mode is used depends on the negotiated cipher suite.
Conceptually, the handshake establishes three secrets which are used
to derive all the keys.
Paragraph (version A):
In the Key Exchange phase, the client sends the ClientHello (client-
hello) message, which contains a random nonce (ClientHello.random),
its offered protocol version, cipher suite, and extensions, and in
general either one or more Diffie-Hellman key shares (in the
"key_share" extension key-share), one or more pre-shared key labels
(in the "pre_shared_key" extension pre-shared-key-extension), or
both.
Paragraph (version A):
The server processes the ClientHello and determines the appropriate
cryptographic parameters for the connection.  It then responds with
its own ServerHello which indicates the negotiated connection
parameters. [server-hello].  The combination of the ClientHello and
the ServerHello determines the shared keys.  If either a pure (EC)DHE
or (EC)DHE-PSK cipher suite is in use, then the ServerHello will
contain a "key_share" extension with the server's ephemeral Diffie-
Hellman share which MUST be in the same group as one of the client's
shares.  If a pure PSK or an (EC)DHE-PSK cipher suite is negotiated,
then the ServerHello will contain a "pre_shared_key" extension
indicating which of the client's offered PSKs was selected.
Paragraph (version B):
In the Key Exchange phase, the client sends the ClientHello (client-
hello) message, which contains a random nonce (ClientHello.random),
its offered protocol version, a list of symmetric cipher/HKDF hash
pairs, some set of Diffie-Hellman key shares (in the "key_share"
extension key-share), one or more pre-shared key labels (in the
"pre_shared_key" extension pre-shared-key-extension), or both, and
some extensions.
Paragraph (version B):
The server processes the ClientHello and determines the appropriate
cryptographic parameters for the connection.  It then responds with
its own ServerHello which indicates the negotiated connection
parameters. [server-hello].  The combination of the ClientHello and
the ServerHello determines the shared keys.  If (EC)DHE key
establishment is in use, then the ServerHello will contain a
"key_share" extension with the server's ephemeral Diffie-Hellman
share which MUST be in the same group as one of the client's shares.
If PSK key establishment is in use, then the ServerHello will contain
a "pre_shared_key" extension indicating which of the client's offered
PSKs was selected.  Note that implementations can use (EC)DHE and PSK
together, in which case both extensions will be supplied.
Paragraph (version A):
PSK cipher suites can either use PSK in combination with an (EC)DHE
exchange in order to provide forward secrecy in combination with
shared keys, or can use PSKs alone, at the cost of losing forward
secrecy.
Paragraph (version B):
PSKs can be used with (EC)DHE exchange in order to provide forward
secrecy in combination with shared keys, or can be used alone, at the
cost of losing forward secrecy.
Paragraph (version A):
As the server is authenticating via a PSK, it does not send a
Certificate or a CertificateVerify.  When a client offers resumption
via PSK it SHOULD also supply a "key_share" extension to the server
as well to allow the server to decline resumption and fall back to a
full handshake, if needed.  A "key_share" extension MUST also be sent
if the client is attempting to negotiate an (EC)DHE-PSK cipher suite.
Paragraph (version B):
As the server is authenticating via a PSK, it does not send a
Certificate or a CertificateVerify.  When a client offers resumption
via PSK it SHOULD also supply a "key_share" extension to the server
as well to allow the server to decline resumption and fall back to a
full handshake, if needed.  The server responds with a
"pre_shared_key" extension to negotiate use of PSK key establishment
and can (as shown here) respond with a "key_share" extension to do
(EC)DHE key establishment, thus providing forward secrecy.
Paragraph (version B):
TLS cryptographic negotiation proceeds by the client offering the
following four sets of options in its ClientHello.
Paragraph (version B):
A "signature_algorithms" (signature-algorithms) extension which
indicates the signature algorithms which the client can accept.
Paragraph (version B):
A "pre_shared_key" (pre-shared-key-extension) extension which
contains the identities of symmetric keys known to the client and
the key exchange modes which each PSK supports.
Paragraph (version B):
If the server does not select a PSK, then the first three of these
options are entirely orthogonal: the server independently selects a
cipher suite, an (EC)DHE group and key share for key establishment,
and a signature algorithm/certificate pair to authenticate itself to
the client.  If any of these parameters has no overlap between the
client and server parameters, then the handshake will fail.  If there
is overlap in the "supported_group" extension but the client did not
offer a compatible "key_share" extension, then the server will
respond with a HelloRetryRequest (hello-retry-request) message.
Paragraph (version B):
If the server selects a PSK, then the PSK will indicate which key
establishment modes it can be used with (PSK alone or with (EC)DHE)
and which authentication modes it can be used with (PSK alone or PSK
with signatures).  The server can then select those key establishment
and authentication parameters to be consistent both with the PSK and
the other extensions supplied by the client.  Note that if the PSK
can be used without (EC)DHE or without signatures, then non-overlap
in either of these parameters need not be fatal.
Paragraph (version B):
The server indicates its selected parameters in the ServerHello as
follows: If PSK is being used then the server will send a
"pre_shared_key" extension indicating the selected key.  If PSK is
not being used, then (EC)DHE and certificate-based authentication are
always used.  When (EC)DHE is in use, the server will also provide a
"key_share" extension.  When authenticating via a certificate, the
server will send an empty "signature_algorithnms" extension in the
ServerHello and will subsequently send Certificate (certificate) and
CertificateVerify (certificate-verify) messages.
Paragraph (version B):
If the server is unable to negotiate a supported set of parameters,
it MUST return a "handshake_failure" alert and close the connection.
Paragraph (version A):
This is a list of the cryptographic options supported by the
client, with the client's first preference first.  Each cipher
suite defines a key exchange algorithm, a record protection
algorithm (including secret key length) and a hash to be used with
HKDF.  The server will select a cipher suite or, if no acceptable
choices are presented, return a "handshake_failure" alert and
close the connection.  If the list contains cipher suites the
server does not recognize, support, or wish to use, the server
MUST ignore those cipher suites, and process the remaining ones as
usual.  Values are defined in cipher-suites.
Paragraph (version B):
This is a list of the symmetric cipher options supported by the
client, specifically the record protection algorithm (including
secret key length) and a hash to be used with HKDF, in descending
order of client preference.  If the list contains cipher suites
the server does not recognize, support, or wish to use, the server
MUST ignore those cipher suites, and process the remaining ones as
o usual.  Values are defined in cipher-suites.
Paragraph (version B):
The single cipher suite selected by the server from the list in
ClientHello.cipher_suites.
Paragraph (version A):
The server_version, cipher_suite, and extensions fields have the same
meanings as their corresponding values in the ServerHello.  [[NOTE:
cipher_suite may disappear. https://github.com/tlswg/tls13-spec/
issues/528]] The server SHOULD send only the extensions necessary for
the client to generate a correct ClientHello pair (currently no such
extensions exist).  As with ServerHello, a HelloRetryRequest MUST NOT
contain any extensions that were not first offered by the client in
its ClientHello.
Paragraph (version B):
The server_version 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 pair (currently no such extensions exist).  As
with ServerHello, a HelloRetryRequest MUST NOT contain any extensions
that were not first offered by the client in its ClientHello.
Paragraph (version B):
Upon re-sending the ClientHello and receiving the server's
ServerHello/KeyShare, the client MUST verify that the selected
NamedGroup matches that supplied in the HelloRetryRequest and MUST
abort the connection with a fatal "handshake_failure" alert if it
does not.
Paragraph (version A):
The client uses the "signature_algorithms" extension to indicate to
the server which signature algorithms may be used in digital
signatures.
Paragraph (version B):
The client uses the "signature_algorithms" extension to indicate to
the server which signature algorithms may be used in digital
signatures.  Clients which desire the server to authenticate via a
certificate MUST send this extension.  If a server is authenticating
via a certificate and the client has not sent a
"signature_algorithms" extension then the server MUST close the
connection with a fatal "missing_extension" alert (see mti-
extensions).
Paragraph (version B):
Servers which are authenticating via a certificate MUST indicate so
by sending the client an empty "signature_algorithms" extension.
Paragraph (version A):
The semantics of this extension are somewhat complicated because the
cipher suite adds additional constraints on signature algorithms.
server-certificate-selection describes the appropriate rules.
Paragraph (version A):
Clients which offer one or more (EC)DHE cipher suites MUST send at
least one supported NamedGroup value and servers MUST NOT negotiate
any of these cipher suites unless a supported value was provided.  If
this extension is not provided and no alternative cipher suite is
available, the server MUST close the connection with a fatal
"missing_extension" alert.  (see mti-extensions) If the extension is
provided, but no compatible group is offered, 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 A):
The "key_share" extension contains the endpoint's cryptographic
parameters for non-PSK key establishment methods (currently DHE or
ECDHE).
Paragraph (version B):
The "key_share" extension contains the endpoint's cryptographic
parameters.
Paragraph (version A):
A single KeyShareEntry value for the negotiated cipher suite.
Paragraph (version B):
A single KeyShareEntry value that is in the same group as one of
the client's shares.
Paragraph (version A):
Clients offer an arbitrary number of KeyShareEntry values, each
representing a single set of key exchange parameters.  For instance,
a client might offer shares for several elliptic curves or multiple
FFDHE groups.  The key_exchange values for each KeyShareEntry MUST by
generated independently.  Clients MUST NOT offer multiple
KeyShareEntry values for the same group.  Clients MUST NOT offer any
KeyShareEntry values for groups not listed in the client's
"supported_groups" extension.
Paragraph (version A):
Servers offer exactly one KeyShareEntry value, which corresponds to
the key exchange used for the negotiated cipher suite.  Servers MUST
NOT offer a KeyShareEntry value for a group not offered by the client
in its corresponding KeyShare or "supported_groups" extension.
Paragraph (version A):
Implementations MAY check for violations of these rules and and MAY
abort the connection with a fatal "illegal_parameter" alert if one is
violated.
Paragraph (version A):
If the server selects an (EC)DHE cipher suite and no mutually
supported group is available between the two endpoints' KeyShare
offers, yet there is a mutually supported group that can be found via
the "supported_groups" extension, then the server MUST reply with a
HelloRetryRequest.  If there is no mutually supported group at all,
the server MUST NOT negotiate an (EC)DHE cipher suite.
Paragraph (version B):
Clients offer an arbitrary number of KeyShareEntry values, each
representing a single set of key exchange parameters.  For instance,
a client might offer shares for several elliptic curves or multiple
FFDHE groups.  The key_exchange values for each KeyShareEntry MUST by
generated independently.  Clients MUST NOT offer multiple
KeyShareEntry values for the same group.  Clients MUST NOT offer any
KeyShareEntry values for groups not listed in the client's
"supported_groups" extension.  Servers MAY check for violations of
these rules and and MAY abort the connection with a fatal
"illegal_parameter" alert if one is violated.
Paragraph (version B):
If using (EC)DHE key establishment, servers offer exactly one
KeyShareEntry which corresponds to one of the KeyShareEntry values
offered by the client, that the server has selected for the
negotiated key exchange.  Servers MUST NOT send a KeyShareEntry for
any group not indicated in the "supported_groups" extension.
Paragraph (version A):
The "pre_shared_key" extension is used to indicate the identity of
the pre-shared key to be used with a given handshake in association
with a PSK or (EC)DHE-PSK cipher suite (see RFC4279 for background).
Paragraph (version B):
The "pre_shared_key" extension is used to indicate the identity of
the pre-shared key to be used with a given handshake in association
with PSK key establishment (see RFC4279 for background).
Paragraph (version A):
If no suitable identity is provided, the server MUST NOT negotiate a
PSK cipher suite and MAY respond with an "unknown_psk_identity" alert
message.  Sending this alert is OPTIONAL; servers MAY instead choose
to send a "decrypt_error" alert to merely indicate an invalid PSK
identity or instead negotiate use of a non-PSK cipher suite, if
available.
Paragraph (version A):
If the server selects a PSK cipher suite, it MUST send a
"pre_shared_key" extension with the identity that it selected.  The
client MUST verify that the server's selected_identity is within the
range supplied by the client.  If the server supplies an "early_data"
extension, the client MUST verify that the server selected the first
offered identity.  If any other value is returned, the client MUST
generate a fatal "unknown_psk_identity" alert and close the
connection.
Paragraph (version B):
Each PSK offered by the client also indicates the authentication and
key exchange modes with which the server can use it, with each list
being in the order of the client's preference, with most preferred
first.
Paragraph (version B):
PSK-only key establishment.  In this mode, the server MUST not
supply a "key_share" value.
Paragraph (version B):
PSK key establishment with (EC)DHE key establishment.  In this
mode, the client and servers MUST supply "key_share" values as
described in key-share.
Paragraph (version B):
In order to accept PSK key establishment, the server sends a
"pre_shared_key" extension with the selected identity.  Clients MUST
verify that the server's selected_identity is within the range
supplied by the client and that the "key_share" and
"signature_algorithms" extensions are consistent with the indicated
ke_modes and auth_modes values.  If these values are not consistent,
the client MUST generate an "illegal_parameter" alert and close the
connection.
Paragraph (version B):
If the server supplies an "early_data" extension, the client MUST
verify that the server selected the first offered identity.  If any
other value is returned, the client MUST generate a fatal
"unknown_psk_identity" alert and close the connection.
Paragraph (version A):
The TLS version number, symmetric ciphersuite, and the hash for
HKDF.
Paragraph (version B):
The TLS version number, AEAD algorithm, and the hash for HKDF.
Paragraph (version A):
A non-anonymous server can optionally request a certificate from
the client, if appropriate for the selected cipher suite.  This
message, if sent, will follow EncryptedExtensions.
Paragraph (version B):
A server which is authenticating with a certificate can optionally
request a certificate from the client.  This message, if sent,
will follow EncryptedExtensions.
Paragraph (version A):
The certificate MUST be appropriate for the negotiated cipher
suite's authentication algorithm and any negotiated extensions.
Paragraph (version A):
As cipher suites that specify new key exchange methods are specified
for the TLS protocol, they will imply the certificate format and the
required encoded keying information.
Paragraph (version A):
This message is used to provide explicit proof that an endpoint
possesses the private key corresponding to its certificate and
also provides integrity for the handshake up to this point.
Servers MUST send this message when using a cipher suite which is
authenticated via a certificate.  Clients MUST send this message
whenever authenticating via a Certificate (i.e., when the
Certificate message is non-empty).  When sent, this message MUST
appear immediately after the Certificate Message and immediately
prior to the Finished message.
Paragraph (version B):
This message is used to provide explicit proof that an endpoint
possesses the private key corresponding to its certificate and
also provides integrity for the handshake up to this point.
Servers MUST send this message when authenticating via a
certificate.  Clients MUST send this message whenever
authenticating via a Certificate (i.e., when the Certificate
message is non-empty).  When sent, this message MUST appear
immediately after the Certificate Message and immediately prior to
the Finished message.
Paragraph (version A):
If sent by a server, the signature algorithm MUST be one offered in
the client's "signature_algorithms" extension unless no valid
certificate chain can be produced without unsupported algorithms (see
signature-algorithms).  Note that there is a possibility for
inconsistencies here.  For instance, the client might offer an
ECDHE_ECDSA cipher suite but omit any ECDSA and EdDSA values from its
"signature_algorithms" extension.  In order to negotiate correctly,
the server MUST check any candidate cipher suites against the
"signature_algorithms" extension before selecting them.  This is
somewhat inelegant but is a compromise designed to minimize changes
to the original cipher suite design.
Paragraph (version B):
If sent by a server, the signature algorithm MUST be one offered in
the client's "signature_algorithms" extension unless no valid
certificate chain can be produced without unsupported algorithms (see
signature-algorithms).
Paragraph (version A):
The client MAY use this PSK for future handshakes by including the
ticket value in the "pre_shared_key" extension in its ClientHello
(pre-shared-key-extension) and supplying a suitable PSK cipher suite.
Servers may send multiple tickets on a single connection, for
instance after post-handshake authentication.  For handshakes that do
not use a resumption_psk, the resumption_context is a string of
Hash.Length zeroes.
Paragraph (version A):
A 32-bit value indicating the ways in which this ticket may be
used (as a bitwise OR of the flags values).
Paragraph (version B):
Any ticket MUST only be resumed with a cipher suite that is identical
to that negotiated connection where the ticket was established.
Paragraph (version B):
The key exchange modes with which this ticket can be used in
descending order of server preference.
Paragraph (version B):
The authentication modes with which this ticket can be used in
descending order of server preference.
Paragraph (version A):
A randomly generated 32-bit value that is used to obscure the age
of the ticket that the client includes in the "early_data"
extension.  The actual ticket age is added to this value modulo
2^32 to obtain the value that is transmitted by the client.
Paragraph (version A):
A placeholder for extensions in the ticket.  Clients MUST ignore
unrecognized extensions.
Paragraph (version A):
When resuming with this ticket, the client MAY send data in its
first flight (early data) encrypted under a key derived from this
PSK.
Paragraph (version A):
This ticket MAY be used with (EC)DHE-PSK cipher suite.
Paragraph (version A):
This ticket MAY be used with a pure PSK cipher suite.
Paragraph (version A):
In all cases, the PSK or (EC)DHE-PSK cipher suites that the client
offers/uses MUST have the same symmetric parameters (cipher/hash) as
the cipher suite negotiated for this connection.  If no flags are set
that the client recognizes, it MUST ignore the ticket.
Paragraph (version B):
A set of extension values for the ticket.  Clients MUST ignore
unrecognized extensions.
Paragraph (version B):
A randomly generated 32-bit value that is used to obscure the age
of the ticket that the client includes in the "early_data"
extension.  The client-side ticket age is added to this value
modulo 2^32 to obtain the value that is transmitted by the client.
Paragraph (version A):
Sent by servers when a PSK cipher suite is selected but no
acceptable PSK identity is provided by the client.  Sending this
alert is OPTIONAL; servers MAY instead choose to send a
"decrypt_error" alert to merely indicate an invalid PSK identity.
Paragraph (version B):
Sent by servers when PSK key establishment is desired but no
acceptable PSK identity is provided by the client.  Sending this
alert is OPTIONAL; servers MAY instead choose to send a
"decrypt_error" alert to merely indicate an invalid PSK identity.
Paragraph (version A):
In order to begin connection protection, the TLS Record Protocol
requires specification of a suite of algorithms, a master secret, and
the client and server random values.  The authentication, key
exchange, and record protection algorithms are determined by the
cipher_suite selected by the server and revealed in the ServerHello
message.  The random values are exchanged in the hello messages.  All
that remains is to calculate the key schedule.
Paragraph (version B):
In order to begin connection protection, the TLS Record Protocol
requires specification of a suite of algorithms, a master secret, and
the client and server random values.
Paragraph (version A):
These cipher suites MUST support both digital signatures and key
exchange with secp256r1 (NIST P-256) and SHOULD support key exchange
with X25519 RFC7748.
Paragraph (version B):
In the absence of an application profile standard specifying
otherwise, a TLS-compliant application MUST implement the
TLS_AES_128_GCM_SHA256 cipher suite and SHOULD implement the
TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 cipher
suites.
Paragraph (version B):
A TLS-compliant application MUST support digital signatures with
rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
TLS-compliant application MUST support key exchange with secp256r1
(NIST P-256) and SHOULD support key exchange with X25519 RFC7748.