Draft: draft-ietf-tls-tls13

Commentary: Note : I rebased for easier processing . 
 editorial ( modulo hash output length question )
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 versions; 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
potentially some other extensions.
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 versions; a list of symmetric cipher/HKDF hash
pairs; some set of Diffie-Hellman key shares (in the "key_share"
extension key-share), a set of pre-shared key labels (in the
"pre_shared_key" extension pre-shared-key-extension) or both; and
potentially some other extensions.
Paragraph (version A):
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):
A "pre_shared_key" (pre-shared-key-extension) extension which
contains a list of symmetric keys known to the client and a
"psk_key_exchange_modes" (pre-shared-key-exchange-modes) extension
which indicates the key exchange modes that may be used with PSKs.
Paragraph (version A):
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 A):
If PSK is being used then the server will send a "pre_shared_key"
extension indicating the selected key.
Paragraph (version B):
If the server selects a PSK, then it MUST only be used with the
establishment modes indicated by "psk_key_exchange_modes" (PSK alone
or with (EC)DHE).  The server can then select the key establishment
and 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 then non-overlap in the "supported_group" parameters
need not be fatal.
Paragraph (version B):
If PSK is being used then the server will send a "pre_shared_key"
extension.
Paragraph (version A):
When authenticating via a certificate, the server will send an
empty "signature_algorithms" extension in the ServerHello and will
subsequently send Certificate (certificate) and CertificateVerify
(certificate-verify) messages.
Paragraph (version B):
When authenticating via a certificate (i.e., when a PSK is not in
use), the server will send Certificate (certificate) and
CertificateVerify (certificate-verify) messages.
Paragraph (version A):
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.  Any PSK MUST only be used with a single HKDF hash algorithm.
This restriction is automatically enforced for PSKs established via
NewSessionTicket (NewSessionTicket) but any externally-established
PSKs MUST also follow this rule.
Paragraph (version B):
A series of HMAC values, one for each PSK offered in the
"pre_shared_keys" extension and in the same order, computed as
described below.
Paragraph (version B):
Each PSK is associated with a single Hash algorithm.  For PSKs
established via the ticket mechanism (NewSessionTicket), this is the
Hash used for the KDF.  For externally established PSKs, the Hash
algorithm MUST be set when the PSK is established.
Paragraph (version B):
Prior to accepting PSK key establishment, the server MUST validate
the corresponding binder value (see psk-binder below) If this value
is not present or does not validate the server MUST abort the
handshake.  Servers SHOULD NOT attempt to validate multiple binders;
rather they SHOULD select a single PSK and validate solely the binder
that corresponds to that PSK.
Paragraph (version B):
In order to accept PSK key establishment, the server sends a
"pre_shared_key" extension indicating the selected identity.
Paragraph (version B):
Clients MUST verify that the server's selected_identity is within the
range supplied by the client, that the same cipher suite was selected
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 abort the handshake
with an "illegal_parameter" alert.
Paragraph (version B):
This extension MUST be the last extension in the ClientHello (this
facilitates implementation as described below).  Servers MUST check
that it is the last extension and otherwise fail the handshake with
an "illegal_parameter" alert.
Paragraph (version B):
If the server supplies an "early_data" extension, the client MUST
verify that the server's selected_identity is 0.  If any other value
is returned, the client MUST abort the handshake with an
"unknown_psk_identity" alert.
Paragraph (version B):
Each entry in the binders list is computed as an HMAC over the
portion of the ClientHello up to and including the
PreSharedKeyExtension.identities field.  That is, it includes all of
the ClientHello but not the binder list itself.  The length fields
for the message (including the overall length, the length of the
extensions block, and the length of the "pre_shared_key" extensio)
are all set as if the binder were present.
Paragraph (version B):
The binding_value is computed in the same way as the Finished message
(finished) but with the BaseKey being the binder_key (see key-
schedule).
Paragraph (version B):
The full ClientHello is included in all other handshake hash
computations.
Paragraph (version B):
In order to use PSKs, clients MUST also send a
"psk_key_exchange_modes" extension.  The semantics of this extension
are that the client only supports the use of PSKs with these modes,
which restricts both the use of PSKs offered in this ClientHello and
those which the server might supply via NewSessionTicket.
Paragraph (version B):
A clients MUST provide a "psk_key_exchange_modes" extension if it
offers a "pre_shared_key" extension.  If clients offer
"pre_shared_key" without a "psk_key_exchange_modes" extension,
servers MUST abort the handshake.  Servers MUST NOT select a key
exchange mode that is not listed by the client.  This extension also
restricts the modes for use with PSK resumption; servers SHOULD NOT
send NewSessionTicket with tickets that are not compatible with the
advertised modes.
Paragraph (version A):
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 abort the handshake with an "illegal_parameter"
alert.
Paragraph (version A):
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 abort the handshake with an
"unknown_psk_identity" alert.
Paragraph (version A):
Note that although 0-RTT data is encrypted with the first PSK
identity, the server MAY fall back to 1-RTT and select a different
PSK identity if multiple identities are offered.
Paragraph (version A):
Clients are permitted to "stream" 0-RTT data until they receive the
server's Finished, only then sending the "end_of_early_data" alert.
In order to avoid deadlock, when accepting "early_data", servers MUST
process the client's Finished and then immediately send the
ServerHello, rather than waiting for the client's "end_of_early_data"
alert.
Paragraph (version B):
Clients are permitted to "stream" 0-RTT data until they receive the
server's Finished, only then sending the "end_of_early_data" alert.
In order to avoid deadlock, when accepting "early_data", servers MUST
process the client's ClientHello and then immediately send the
ServerHello, rather than waiting for the client's "end_of_early_data"
alert.
Paragraph (version A):
A signature over the value Hash(Handshake Context + Certificate) +
Hash(resumption_context) See NewSessionTicket for the definition
of resumption_context.
Paragraph (version A):
A MAC over the value Hash(Handshake Context + Certificate +
CertificateVerify) + Hash(resumption_context) using a MAC key
derived from the base key.
Paragraph (version B):
A MAC over the value Hash(Handshake Context + Certificate +
CertificateVerify) using a MAC key derived from the base key.
Paragraph (version A):
Note: The Handshake Context for the last three rows does not include
any 0-RTT handshake messages, regardless of whether 0-RTT is used.
Paragraph (version A):
The key exchange modes with which this ticket can be used in
descending order of server preference.
Paragraph (version A):
The authentication modes with which this ticket can be used in
descending order of server preference.
Paragraph (version A):
Note that the 0-RTT Finished message is not included in the Derive-
Secret operation.
Paragraph (version A):
If a given secret is not available, then the 0-value consisting of a
string of Hash.length zeroes is used.  Note that this does not mean
skipping rounds, so if PSK is not in use Early Secret will still be
HKDF-Extract(0, 0).
Paragraph (version B):
If a given secret is not available, then the 0-value consisting of a
string of Hash.length zeroes is used.  Note that this does not mean
skipping rounds, so if PSK is not in use Early Secret will still be
HKDF-Extract(0, 0).  For the computation of the binder_secret, the
label is "external psk binder key" for external PSKs and "resumption
psk binder key" for resumption PSKs.  The different labels prevents
the substitution of one type of PSK for the other.
Paragraph (version B):
There are multiple potential Early Secret values depending on which
PSK the server ultimately selects.  The client will need to compute
one for each potential PSK; if no PSK is selected, it will then need
to compute the early secret corresponding to the zero PSK.
Paragraph (version A):
"signature_algorithms" is REQUIRED for certificate authenticated
cipher suites.
Paragraph (version A):
"supported_groups" and "key_share" are REQUIRED for DHE or ECDHE
cipher suites.
Paragraph (version A):
"pre_shared_key" is REQUIRED for PSK cipher suites.
Paragraph (version A):
When negotiating use of applicable cipher suites, endpoints MUST
abort the handshake with a "missing_extension" alert if the required
extension was not provided.  Any endpoint that receives an invalid
combination of cipher suites and extensions MAY abort the connection
with a "missing_extension" alert, regardless of negotiated
parameters.
Paragraph (version B):
"signature_algorithms" is REQUIRED for certificate authentication.
Paragraph (version B):
"supported_groups" and "key_share" are REQUIRED for DHE or ECDHE
key establishment.
Paragraph (version B):
"pre_shared_key" is REQUIRED for PSK key establishment.
Paragraph (version B):
"psk_key_exchange_modes" is required when PSKs are offered.
Paragraph (version B):
"cookie" MUST always be supported if sent by the server.
Paragraph (version B):
If a required extension was not provided, endpoints MUST abort the
handshake with a "missing_extension" alert.  Any endpoint that
receives an invalid combination of cipher suites and extensions MAY
abort the connection with a "missing_extension" alert, regardless of
negotiated parameters.