Draft: draft-ietf-tls-tls13

Commentary: I took this bit out of the 1st paragraph : -If any of these parameters has no overlap between the -client and server parameters , then the handshake -will fail . and moved it to the last para in the section because it does n't say what alert value is to be returned , there 's not something similar in the following paragraph that describes the PSK failure case , and finally the full failure text is included in the final paragraph . Basically , I just move the failure case to the final paragraph . An alternate would be to copy the failure to the PSK paragraph and include the which alert to return in the non - PSK para .
Paragraph (version A):
TLS cryptographic negotiation proceeds by the client offering the
following four sets of options in its ClientHello.
Paragraph (version B):
A list of cipher suites which indicates the AEAD cipher/HKDF hash
pairs which the client supports.
Paragraph (version B):
A "supported_group" (negotiated-groups) extension which indicates
the (EC)DHE groups which the client supports and a "key_share"
(key-share) extension which contains (EC)DHE shares for some or
all of these groups.
Paragraph (version A):
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 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 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 A):
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 A):
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 B):
If PSK is being used then the server will send a "pre_shared_key"
extension indicating the selected key.
Paragraph (version B):
If PSK is not being used, then (EC)DHE and certificate-based
authentication are always used.
Paragraph (version B):
When (EC)DHE is in use, the server will also provide a "key_share"
extension.
Paragraph (version B):
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
(i.e., there is no overlap between the client and server parameters),
it MUST return a "handshake_failure" alert and close the connection.