Draft: draft-ietf-tls-tls13

Commentary: This replaces PR and After landed the recent draft 7 overhaul , fixes branch was heavily bitrotted again . I suggested ekr review and merge it recently , but I went over it again earlier and I do n't think that 's viable as - is anymore . I 'm not a git pro , but I think I 've managed to deconflict this again to the point where it 's usable . I squashed a lot of commits on the same days together as this made it much easier for me to resolve the conflicts . ( also got rid of some commits & reversions ) This does n't have ekr 's deconflict commit in there or a deconflict commit from myself for this round , but I do n't think that 's too important . I also fixed a typo in one of the reference links in there somewhere . There 's a lot of little things in here , but there 's also a few important ones ( e.g. first change updates FIPS ref ) , so I think this is important to finally get fixed up and merged . Please review this and make sure all of your stuff made it through to here ok . ( at least the changes that were n't completely superseded by ekr 's big commit ) I think there 's probably a few peers / parties bits that could be /redone , but I do n't think anything major got lost . One important change to review : " supportedgroups " was renamed to " namedgroups " . Did we want to keep the old name or merge this change ? If not , one of us can revert that part . 
 I also managed to fix the author metadata for these commits to actually be for the correct account . All the commits in the old PR & branches had a different email address listed and confused GitHub . ( the old commits had no icons on here ; these amalgamated commits are cited as from Sean 's account properly ) 
 FYI - I m perfectly happy that you tweaked / fixed this  . spt On Jul 08 , 2015 , at 10:18 ,   wrote : 
 This looks good but needs a rebase . Can you do that ? 
  , more rebasing . :p Sure , gimmie a sec and I 'll do that . 
 Rebased . 
 Section E.3 says : It should say : The condition is the wrong way around . When the bytes are _ all 0x03 , that means the client supports TLS , so there must have been a version rollback attack in order for SSL 2.0 to be negotiated . 
 This section was dropped as  is now prohibited entirely , so this issue is no longer applicable and can be closed .
Paragraph (version A):
This document specifies Version 1.3 of the Transport Layer Security
(TLS) protocol.  The TLS protocol provides communications security
over the Internet.  The protocol allows client/server applications to
communicate in a way that is designed to prevent eavesdropping,
tampering, or message forgery.
Paragraph (version B):
This document specifies Version 1.3 of the Transport Layer Security
(TLS) protocol.  The TLS protocol allows client/server applications
to communicate over the Internet in a way that is designed to prevent
eavesdropping, tampering, and message forgery.
Paragraph (version A):
The connection is private.  Symmetric cryptography is used for
data encryption (e.g., AES AES, etc.).  The keys for this
symmetric encryption are generated uniquely for each connection
and are based on a secret negotiated by another protocol (such as
the TLS Handshake Protocol).  The Record Protocol can also be used
without encryption, i.e., in integrity-only modes.
Paragraph (version A):
The Record Protocol can operate in an insecure mode but is
generally only used in this mode while another protocol is using
the Record Protocol as a transport for negotiating security
parameters.
Paragraph (version B):
The connection is private.  Symmetric cryptography is used for
data encryption (e.g., AES AES, etc.).  The keys for this
symmetric encryption are generated uniquely for each connection
and are based on a secret negotiated by another protocol (such as
the TLS Handshake Protocol).
Paragraph (version B):
Note: The TLS Record Protocol can operate in an insecure mode but is
generally only used in this mode while another protocol is using the
TLS Record Protocol as a transport for negotiating security
parameters.
Paragraph (version B):
Remove ChangeCipherSpec.
Paragraph (version B):
Rename {Client,Server}KeyExchange to {Client,Server}KeyShare.
Paragraph (version B):
Add an explicit HelloRetryRequest to reject the client's.
Paragraph (version B):
Removed support for non-AEAD ciphers.
Paragraph (version A):
This document and the TLS protocol itself have evolved from the SSL
between this protocol and previous versions are significant enough
that the various versions of TLS and SSL 3.0 do not interoperate
(although each protocol incorporates a mechanism by which an
implementation can back down to prior versions).  This document is
intended primarily for readers who will be implementing the protocol
and for those doing cryptographic analysis of it.  The specification
has been written with this in mind, and it is intended to reflect the
needs of those two groups.  For that reason, many of the algorithm-
dependent data structures and rules are included in the body of the
text (as opposed to in an appendix), providing easier access to them.
Paragraph (version B):
This document and the TLS protocol itself have evolved from the SSL
between this version and previous versions are significant enough
that the various versions of TLS and SSL 3.0 do not interoperate
(although each protocol incorporates a mechanism by which an
implementation can back down to prior versions).  This document is
intended primarily for readers who will be implementing the protocol
and for those doing cryptographic analysis of it.  The specification
has been written with this in mind, and it is intended to reflect the
needs of those two groups.  For that reason, many of the algorithm-
dependent data structures and rules are included in the body of the
text (as opposed to in an appendix), providing easier access to them.
Paragraph (version A):
The TLS Record Protocol is a layered protocol.  At each layer,
messages may include fields for length, description, and content.
The Record Protocol takes messages to be transmitted, fragments the
data into manageable blocks, protects the records, and transmits the
result.  Received data is decrypted and verified, reassembled, and
then delivered to higher-level clients.
Paragraph (version A):
Three protocols that use the record protocol are described in this
document: the handshake protocol, the alert protocol, and the
application data protocol.  In order to allow extension of the TLS
protocol, additional record content types can be supported by the
record protocol.  New record content type values are assigned by IANA
in the TLS Content Type Registry as described in iana-considerations.
Paragraph (version B):
The TLS Record Protocol is a layered protocol.  At each layer,
messages may include fields for length, description, and content.
The TLS Record Protocol takes messages to be transmitted, fragments
the data into manageable blocks, protects the records, and transmits
the result.  Received data is decrypted and verified, reassembled,
and then delivered to higher-level clients.
Paragraph (version B):
Three protocols that use the TLS Record Protocol are described in
this document: the TLS Handshake Protocol, the Alert Protocol, and
the application data protocol.  In order to allow extension of the
TLS protocol, additional record content types can be supported by the
TLS Record Protocol.  New record content type values are assigned by
IANA in the TLS Content Type Registry as described in iana-
considerations.
Paragraph (version A):
Note in particular that type and length of a record are not protected
by encryption.  If this information is itself sensitive, application
designers may wish to take steps (padding, cover traffic) to minimize
information leakage.
Paragraph (version B):
Note in particular that type and length of a record are not protected
by encryption.  If this information is itself sensitive, application
designers may wish to take steps (e.g., padding, cover traffic) to
minimize information leakage.
Paragraph (version A):
The algorithm to be used for record protection.  This algorithm
must be of the AEAD type and thus provides integrity and
confidentiality as a single primitive.  It is possible to have
AEAD algorithms which do not provide any confidentiality and
record-payload-protection defines a special NULL_NULL AEAD
algorithm for use in the initial handshake).  This specification
includes the key size of this algorithm and of the nonce for the
AEAD algorithm.
Paragraph (version B):
The algorithm to be used for record protection.  This algorithm
must be of the AEAD type and thus provides integrity and
confidentiality as a single primitive.  It is possible to have
AEAD algorithms which do not provide any confidentiality and
record-payload-protection defines a special NULL_NULL AEAD
algorithm for use only in the initial handshake.  This
specification includes the key size of this algorithm and of the
nonce for the AEAD algorithm.
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 the exchange of closing messages.
Paragraph (version B):
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):
Either party MAY initiate a close by sending a "close_notify" alert.
Any data received after a closure alert is ignored.  If a transport-
level close is received prior to a close_notify, the receiver cannot
know that all the data that was sent has been received.
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.  It is not required for
the initiator of the close to wait for the responding "close_notify"
alert before closing the read side of the connection.
Paragraph (version B):
Either party MAY initiate a close by sending a "close_notify" alert.
Any data received after a closure alert is ignored.  If a transport-
level close is received prior to a "close_notify", the receiver
cannot know that all the data that was sent has been received.
Paragraph (version B):
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 A):
Error handling in the TLS Handshake protocol is very simple.  When an
error is detected, the detecting party sends a message to the other
party.  Upon transmission or receipt of a fatal alert message, both
parties immediately close the connection.  Servers and clients MUST
forget any session-identifiers, keys, and secrets associated with a
failed connection.  Thus, any connection terminated with a fatal
alert MUST NOT be resumed.
Paragraph (version B):
Error handling in the TLS Handshake Protocol is very simple.  When an
error is detected, the detecting party sends a message to its peer.
Upon transmission or receipt of a fatal alert message, both parties
immediately close the connection.  Servers and clients MUST forget
any session-identifiers, keys, and secrets associated with a failed
connection.  Thus, any connection terminated with a fatal alert MUST
NOT be resumed.
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 party 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 peer 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
"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 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 message 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 alert was used in some earlier versions of TLS, and may have
permitted certain attacks against the CBC mode CBCATT.  It MUST
NOT be sent by compliant implementations.  This message is always
fatal.
Paragraph (version A):
A TLSCiphertext record was received that had a length more than
2^14+2048 bytes, or a record decrypted to a TLSPlaintext record
with more than 2^14 bytes.  This message 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 alert was used in previous versions of TLS.  TLS 1.3 does not
include compression and TLS 1.3 implementations MUST NOT send this
alert when in TLS 1.3 mode.  This message is always fatal.
Paragraph (version A):
Reception of a "handshake_failure" alert message indicates that
the sender was unable to negotiate an acceptable set of security
parameters given the options available.  This message is always
fatal.
Paragraph (version A):
This alert was used in SSL 3.0 but not any version of TLS.  It
MUST NOT be sent by compliant implementations.  This message is
always fatal.
Paragraph (version B):
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 was used in some earlier versions of TLS, and may have
permitted certain attacks against the CBC mode CBCATT.  It MUST
NOT be sent by compliant implementations.  This alert is always
fatal.
Paragraph (version B):
A TLSCiphertext record was received that had a length more than
2^14+2048 bytes, or a record decrypted to a TLSPlaintext record
with more than 2^14 bytes.  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 was used in previous versions of TLS.  TLS 1.3 does not
include compression and TLS 1.3 implementations MUST NOT send this
alert when in TLS 1.3 mode.  This alert is always fatal.
Paragraph (version B):
Reception of a "handshake_failure" alert message indicates that
the sender was unable to negotiate an acceptable set of security
parameters given the options available.  This alert is always
fatal.
Paragraph (version B):
This alert was used in SSL 3.0 but not any version of TLS.  It
MUST NOT be sent by compliant implementations.  This alert is
always fatal.
Paragraph (version A):
A field in the handshake was out of range or inconsistent with
other fields.  This message is always fatal.
Paragraph (version A):
A valid certificate chain or partial chain was received, but the
certificate was not accepted because the CA certificate could not
be located or couldn't be matched with a known, trusted CA.  This
message is always fatal.
Paragraph (version A):
A valid certificate was received, but when access control was
applied, the sender decided not to proceed with negotiation.  This
message is always fatal.
Paragraph (version A):
A message could not be decoded because some field was out of the
specified range or the length of the message was incorrect.  This
message is always fatal and should never be observed in
communication between proper implementations (except when messages
were corrupted in the network).
Paragraph (version A):
A handshake cryptographic operation failed, including being unable
to correctly verify a signature or validate a Finished message.
This message is always fatal.
Paragraph (version A):
This alert was used in some earlier versions of TLS.  It MUST NOT
be sent by compliant implementations.  This message is always
fatal.
Paragraph (version A):
The protocol version the peer has attempted to negotiate is
recognized but not supported.  (For example, old protocol versions
might be avoided for security reasons.)  This message is always
fatal.
Paragraph (version A):
Returned instead of "handshake_failure" when a negotiation has
failed specifically because the server requires ciphers more
secure than those supported by the client.  This message is always
fatal.
Paragraph (version A):
An internal error unrelated to the peer or the correctness of the
protocol (such as a memory allocation failure) makes it impossible
to continue.  This message is always fatal.
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 message 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
message is always fatal.
Paragraph (version A):
sent by clients that receive an extended ServerHello containing an
extension that they did not put in the corresponding ClientHello.
This message is always fatal.
Paragraph (version B):
A field in the handshake was out of range or inconsistent with
other fields.  This alert is always fatal.
Paragraph (version B):
A valid certificate chain or partial chain was received, but the
certificate was not accepted because the CA certificate could not
be located or couldn't be matched with a known, trusted CA.  This
alert is always fatal.
Paragraph (version B):
A valid certificate was received, but when access control was
applied, the sender decided not to proceed with negotiation.  This
alert is always fatal.
Paragraph (version B):
A message could not be decoded because some field was out of the
specified range or the length of the message was incorrect.  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):
A handshake cryptographic operation failed, including being unable
to correctly verify a signature or validate a Finished message.
This alert is always fatal.
Paragraph (version B):
This alert was used in some earlier versions of TLS.  It MUST NOT
be sent by compliant implementations.  This alert is always fatal.
Paragraph (version B):
The protocol version the peer has attempted to negotiate is
recognized but not supported.  (For example, old protocol versions
might be avoided for security reasons.)  This alert is always
fatal.
Paragraph (version B):
Returned instead of "handshake_failure" when a negotiation has
failed specifically because the server requires ciphers more
secure than those supported by the client.  This alert is always
fatal.
Paragraph (version B):
An internal error unrelated to the peer or the correctness of the
protocol (such as a memory allocation failure) makes it impossible
to continue.  This alert is always fatal.
Paragraph (version B):
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 B):
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):
Sent by clients that receive an extended ServerHello containing an
extension that they did not put in the corresponding ClientHello.
This alert is always fatal.
Paragraph (version A):
If no common cryptographic parameters can be negotiated, the server
will send a fatal alert.
Paragraph (version B):
If no common cryptographic parameters can be negotiated, the server
will send a "handshake_failure" or "insufficient_security" fatal
alert (see alert-protocol).
Paragraph (version A):
The handshake protocol messages are presented below in the order they
MUST be sent; sending handshake messages in an unexpected order
results in a fatal error.  Unneeded handshake messages can be
omitted, however.
Paragraph (version B):
The TLS Handshake Protocol messages are presented below in the order
they MUST be sent; sending handshake messages in an unexpected order
results in an "unexpected_message" fatal error.  Unneeded handshake
messages can be omitted, however.
Paragraph (version A):
32 bytes generated by a secure random number generator.
Paragraph (version B):
32 bytes generated by a secure random number generator.  See
implementation-notes for additional information.
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 groups that are mutually supported, but the client's
ClientKeyShare did not contain an acceptable offer.  If it cannot
find such a match, it will respond with a "handshake_failure"
alert.
Paragraph (version B):
Servers send this message in response to a ClientHello message
when it was able to find an acceptable set of algorithms and
groups that are mutually supported, but the client's
ClientKeyShare did not contain an acceptable offer.  If it cannot
find such a match, it will respond with a "handshake_failure"
alert.
Paragraph (version A):
This field indicates the hash algorithm 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.
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.
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-share.  It MUST NOT appear in this extension.
Paragraph (version B):
This field indicates the signature algorithm that may be used.
The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
RFC3447, DSA DSS, and ECDSA ECDSA, respectively.  The "anonymous"
value is meaningless in this context but used in server-key-share.
It MUST NOT appear in this extension.
Paragraph (version A):
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):
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):
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 A):
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):
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 ServerKeyShare message.  The server
must consider the supported groups in both cases.
Paragraph (version A):
This is a sequence (chain) of certificates.  The sender's
certificate MUST come first in the list.  Each following
certificate MUST directly certify the one preceding it.  Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.
Paragraph (version B):
This is a sequence (chain) of certificates.  The server's
certificate MUST come first in the list.  Each following
certificate MUST directly certify the one preceding it.  Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certification authority (CA) MAY be omitted from the chain, under
the assumption that the client must already possess it in order to
validate it in any case.
Paragraph (version A):
The end entity certificate's public key (and associated
restrictions) MUST be compatible with the selected key exchange
algorithm.
Paragraph (version B):
The server's end-entity certificate's public key (and associated
restrictions) MUST be compatible with the selected key exchange
algorithm.
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 immediately follow the server's Certificate
message).
Paragraph (version B):
A non-anonymous server can optionally request a certificate from
the client, if appropriate for the selected cipher suite.  This
message, if sent, will immediately follow the server's Certificate
message.