Draft: draft-ietf-tls-tls13

Commentary: Rebased  's PR .
Paragraph (version B):
Add initial 0-RTT support.
Paragraph (version B):
Remove resumption and replace with PSK + tickets.
Paragraph (version B):
Move to HKDF.
Paragraph (version A):
Reworked handshake to provide 1-RTT mode.
Paragraph (version A):
Removed support for compression.
Paragraph (version A):
Removed support for static RSA and DH key exchange.
Paragraph (version A):
Removed support for non-AEAD ciphers.
Paragraph (version B):
Rework handshake to provide 1-RTT mode.
Paragraph (version B):
Remove support for compression.
Paragraph (version B):
Remove support for static RSA and DH key exchange.
Paragraph (version B):
Remove support for non-AEAD ciphers.
Paragraph (version A):
The client and the server must share knowledge that the connection is
ending in order to avoid a truncation attack.  Either party may
initiate a close by sending a "close_notify" alert.  Any data
received after a closure is ignored.
Paragraph (version A):
This message notifies the recipient that the sender will not send
any more messages on this connection.  Note that as of TLS 1.1,
failure to properly close a connection no longer requires that a
session not be resumed.  This is a change from TLS 1.0 to conform
with widespread implementation practice.
Paragraph (version A):
Unless some other fatal alert has been transmitted, each party is
required to send a "close_notify" alert before closing the write side
of the connection.  The other party MUST respond with a
"close_notify" alert of its own and close down the connection
immediately, discarding any pending writes.  The initiator of the
close need not wait for the responding "close_notify" alert before
closing the read side of the connection.
Paragraph (version B):
The client and the server must share knowledge that the connection is
ending in order to avoid a truncation attack.  Failure to properly
close a connection does not prohibit a session from being resumed.
Paragraph (version B):
This message notifies the recipient that the sender will not send
any more messages on this connection.  Any data received after a
closure MUST be ignored.
Paragraph (version B):
This message notifies the recipient that the sender is canceling
the handshake for some reason unrelated to a protocol failure.  If
a user cancels an operation after the handshake is complete, just
closing the connection by sending a "close_notify" is more
appropriate.  This alert SHOULD be followed by a "close_notify".
This alert is generally a warning.
Paragraph (version B):
Each party MUST send a "close_notify" alert before closing the write
side of the connection, unless some other fatal alert has been
transmitted.  The other party MUST respond with a "close_notify"
alert of its own and close down the connection immediately,
discarding any pending writes.  The initiator of the close need not
wait for the responding "close_notify" alert before closing the read
side of the connection.
Paragraph (version A):
If an alert with a level of warning is sent and received, generally
the connection can continue normally.  If the receiving party decides
not to proceed with the connection (e.g., after having received a
"no_renegotiation" alert that it is not willing to accept), it SHOULD
send a fatal alert to terminate the connection.  Given this, the
sending peer cannot, in general, know how the receiving party will
behave.  Therefore, warning alerts are not very useful when the
sending party wants to continue the connection, and thus are
sometimes omitted.  For example, if a party decides to accept an
expired certificate (perhaps after confirming this with the user) and
wants to continue the connection, it would not generally send a
"certificate_expired" alert.
Paragraph (version B):
If an alert with a level of warning is sent and received, generally
the connection can continue normally.  If the receiving party decides
not to proceed with the connection (e.g., after having received a
"user_canceled" alert that it is not willing to accept), it SHOULD
send a fatal alert to terminate the connection.  Given this, the
sending peer cannot, in general, know how the receiving party will
behave.  Therefore, warning alerts are not very useful when the
sending party wants to continue the connection, and thus are
sometimes omitted.  For example, if a party decides to accept an
expired certificate (perhaps after confirming this with the user) and
wants to continue the connection, it would not generally send a
"certificate_expired" alert.
Paragraph (version A):
This alert is returned if a record is received which cannot be
deprotected.  Because AEAD algorithms combine decryption and
verification, this message is used for all deprotection failures.
This alert is always fatal and should never be observed in
communication between proper implementations (except when messages
were corrupted in the network).
Paragraph (version B):
This alert is returned if a record is received which cannot be
deprotected.  Because AEAD algorithms combine decryption and
verification, this alert is used for all deprotection failures.
This alert is always fatal and should never be observed in
communication between proper implementations (except when messages
were corrupted in the network).
Paragraph (version A):
This handshake is being canceled for some reason unrelated to a
protocol failure.  If the user cancels an operation after the
handshake is complete, just closing the connection by sending a
"close_notify" is more appropriate.  This alert should be followed
by a "close_notify".  This alert is generally a warning.
Paragraph (version A):
Sent by the client in response to a HelloRequest or by the server
in response to a ClientHello after initial handshaking.  Versions
of TLS prior to TLS 1.3 supported renegotiation of a previously
established connection; TLS 1.3 removes this feature.  This alert
is always fatal.
Paragraph (version B):
This alert was used in previous versions of TLS.  TLS 1.3 does not
include renegotiation and TLS 1.3 implementations MUST NOT send
this alert when in TLS 1.3 mode.  This alert is always fatal.
Paragraph (version A):
PSK ciphersuites 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):
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 A):
When a client first connects to a server, it is required to send
the ClientHello as its first message.  The client will also 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) except including
a new ClientKeyShare.  [[OPEN ISSUE: New random values?  See:
https://github.com/tlswg/tls13-spec/issues/185]] If a server
receives a ClientHello at any other time, it MUST send a fatal
"no_renegotiation" alert.
Paragraph (version B):
When a client first connects to a server, it is required to send
the ClientHello as its first message.  The client will also 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) except including
a new ClientKeyShare.  [[OPEN ISSUE: New random values?  See:
https://github.com/tlswg/tls13-spec/issues/185]] If a server
receives a ClientHello at any other time, it MUST send a fatal
"unexpected_message" alert and close the connection.
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
and the client's ClientKeyShare extension 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
and the client's ClientKeyShare extension was acceptable.  If the
client proposed groups are not acceptable by the server, it will
respond with a "handshake_failure" fatal alert.
Paragraph (version A):
The client uses the "signature_algorithms" extension to indicate to
the server which signature/hash algorithm pairs may be used in
digital signatures.  The "extension_data" field of this extension
contains a "supported_signature_algorithms" value.
Paragraph (version B):
The client uses the "signature_algorithms" extension to indicate to
the server which signature/hash algorithm pairs may be used in
digital signatures.
Paragraph (version A):
This field indicates the hash algorithms which may be used.  The
values indicate support for unhashed data, MD5 RFC1321, SHA-1,
SHA-224, SHA-256, SHA-384, and SHA-512 SHS, respectively.  The
"none" value is provided for future extensibility, in case of a
signature algorithm which does not require hashing before signing.
The usage of MD5 and SHA-224 are deprecated.  The md5_RESERVED and
sha224_RESERVED values MUST NOT be offered or negotiated by any
implementation.
Paragraph (version B):
This field indicates the hash algorithms which may be used.  The
values indicate support for unhashed data, MD5 RFC1321, SHA-1,
SHA-224, SHA-256, SHA-384, and SHA-512 SHS, respectively.  The
"none" value is provided for future extensibility, in case of a
signature algorithm which does not require hashing before signing.
The use of MD5 and SHA-224 are deprecated.  The md5_RESERVED and
sha224_RESERVED values MUST NOT be offered or negotiated by any
implementation.
Paragraph (version A):
When sent by the client, the "named_groups" extension indicates the
named groups which the client supports, ordered from most preferred
to least preferred.
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 A):
Values within "obsolete_RESERVED" ranges were used in previous
versions of TLS and MUST NOT be offered or negotiated by TLS 1.3
implementations.
Paragraph (version A):
Items in named_curve_list are ordered according to the client's
preferences (favorite choice first).
Paragraph (version B):
Values within "obsolete_RESERVED" ranges were used in previous
versions of TLS and MUST NOT be offered or negotiated by TLS 1.3
implementations.  The obsolete curves have various known/theoretical
weaknesses or have had very little usage, in some cases only due to
unintentional server configuration issues.  They are no longer
considered appropriate for general use and should be assumed to be
potentially unsafe.  The set of curves specified here is sufficient
for interoperability with all currently deployed and properly
configured TLS implementations.
Paragraph (version B):
Items in named_curve_list are ordered according to the client's
preferences (most preferred choice first).
Paragraph (version A):
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):
The client MUST supply a "supported_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 "supported_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 A):
If TLS client authentication is being used, then either
"early_handshake" or "early_handshake_and_data" MUST be indicated in
order to send the client authentication data on the first flight.  In
either case, the client Certificate and CertificateVerify (assuming
that the Certificate is non-empty) MUST be sent on the first flight A
server which receives an initial flight with only "early_data" and
which expects certificate-based client authentication MUST not accept
early data.
Paragraph (version B):
If TLS client authentication is being used, then either
"early_handshake" or "early_handshake_and_data" MUST be indicated in
order to send the client authentication data on the first flight.  In
either case, the client Certificate and CertificateVerify (assuming
that the Certificate is non-empty) MUST be sent on the first flight.
A server which receives an initial flight with only "early_data" and
which expects certificate-based client authentication MUST NOT accept
early data.
Paragraph (version B):
What is in the handshake hash (including potentially some
speculative data from the server).
Paragraph (version B):
What is signed in the client's CertificateVerify.
Paragraph (version A):
TLS ExtensionType Registry: Future values are allocated via IETF
Consensus RFC2434.  IANA has updated this registry to include the
signature_algorithms extension and its corresponding value (see
hello-extensions).
Paragraph (version B):
TLS ExtensionType Registry: Future values are allocated via IETF
Consensus RFC2434.  IANA has updated this registry to include the
"signature_algorithms" extension and its corresponding value (see
hello-extensions).