Draft: draft-ietf-tls-tls13

Commentary: Per the consensus call closed April 26 , remove all non - AEAD cipher suites and adjust the document around it .
Paragraph (version A):
The connection is private.  Symmetric cryptography is used for
data encryption (e.g., AES AES, RC4 SCH, 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.
Paragraph (version A):
The connection is reliable.  Message transport includes a message
integrity check using a keyed MAC.  Secure hash functions (e.g.,
SHA-1, etc.) are used for MAC computations.  The Record Protocol
can operate without a MAC, 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).  The Record Protocol can also be used
without encryption, i.e., in integrity-only modes.
Paragraph (version B):
The connection is reliable.  Messages include an authentication
tag which protects them against modification.
Paragraph (version B):
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 A):
draft-01 - Removed support for compression.  - Removed support for
static RSA key exchange.
Paragraph (version A):
Extensibility: TLS seeks to provide a framework into which new
public key and bulk encryption methods can be incorporated as
necessary.  This will also accomplish two sub-goals: preventing
the need to create a new protocol (and risking the introduction of
possible new weaknesses) and avoiding the need to implement an
entire new security library.
Paragraph (version B):
Extensibility: TLS seeks to provide a framework into which new
public key and record protection methods can be incorporated as
necessary.  This will also accomplish two sub-goals: preventing
the need to create a new protocol (and risking the introduction of
possible new weaknesses) and avoiding the need to implement an
entire new security library.
Paragraph (version A):
The five cryptographic operations -- digital signing, stream cipher
encryption, block cipher encryption, authenticated encryption with
additional data (AEAD) encryption, and public key encryption -- are
designated digitally-signed, stream-ciphered, block-ciphered, aead-
ciphered, and public-key-encrypted, respectively.  A field's
cryptographic processing is specified by prepending an appropriate
key word designation before the field's type specification.
Cryptographic keys are implied by the current session state (see
connection-states).
Paragraph (version B):
The three cryptographic operations -- digital signing, authenticated
encryption with additional data (AEAD) and public key encryption --
are designated digitally-signed, aead-ciphered, and public-key-
encrypted, respectively.  A field's cryptographic processing is
specified by prepending an appropriate key word designation before
the field's type specification.  Cryptographic keys are implied by
the current session state (see connection-states).
Paragraph (version A):
In stream cipher encryption, the plaintext is exclusive-ORed with an
identical amount of output generated from a cryptographically secure
keyed pseudorandom number generator.
Paragraph (version A):
In block cipher encryption, every block of plaintext encrypts to a
block of ciphertext.  All block cipher encryption is done in CBC
(Cipher Block Chaining) mode, and all items that are block-ciphered
will be an exact multiple of the cipher block length.
Paragraph (version A):
The contents of the inner struct (field3 and field4) are used as
input for the signature/hash algorithm, and then the entire structure
is encrypted with a stream cipher.  The length of this structure, in
bytes, would be equal to two bytes for field1 and field2, plus two
bytes for the signature and hash algorithm, plus two bytes for the
length of the signature, plus the length of the output of the signing
algorithm.  The length of the signature is known because the
algorithm and key used for the signing are known prior to encoding or
decoding this structure.
Paragraph (version B):
The contents of the inner struct (field3 and field4) are used as
input for the signature/hash algorithm.  The length of t structure,
in bytes, would be equal to two bytes for field1 and field2, plus two
bytes for the signature and hash algorithm, plus two bytes for the
length of the signature, plus the length of the output of the signing
algorithm.  The length of the signature is known because the
algorithm and key used for the signing are known prior to encoding or
decoding this structure.
Paragraph (version A):
The TLS record layer uses a keyed Message Authentication Code (MAC)
to protect message integrity.  The cipher suites defined in this
document use a construction known as HMAC, described in RFC2104,
which is based on a hash function.  Other cipher suites MAY define
their own MAC constructions, if needed.
Paragraph (version A):
In addition, a construction is required to do expansion of secrets
into blocks of data for the purposes of key generation or validation.
This pseudorandom function (PRF) takes as input a secret, a seed, and
an identifying label and produces an output of arbitrary length.
Paragraph (version A):
In this section, we define one PRF, based on HMAC.  This PRF with the
SHA-256 hash function is used for all cipher suites defined in this
document and in TLS documents published prior to this document when
TLS 1.2 is negotiated.  New cipher suites MUST explicitly specify a
PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a
stronger standard hash function.
Paragraph (version B):
A construction is required to do expansion of secrets into blocks of
data for the purposes of key generation or validation.  This
pseudorandom function (PRF) takes as input a secret, a seed, and an
identifying label and produces an output of arbitrary length.
Paragraph (version B):
In this section, we define one PRF, based on HMAC RFC2104.  This PRF
with the SHA-256 hash function is used for all cipher suites defined
in this document and in TLS documents published prior to this
document when TLS 1.2 is negotiated.  New cipher suites MUST
explicitly specify a PRF and, in general, SHOULD use the TLS PRF with
SHA-256 or a stronger standard hash function.
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, applies a MAC, encrypts, and transmits
the result.  Received data is decrypted, verified, reassembled, and
then delivered to higher-level clients.
Paragraph (version B):
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):
A TLS connection state is the operating environment of the TLS Record
Protocol.  It specifies an encryption algorithm and a MAC algorithm.
In addition, the parameters for these algorithms are known: the MAC
key and the bulk encryption keys for the connection in both the read
and the write directions.  Logically, there are always four
connection states outstanding: the current read and write states, and
the pending read and write states.  All records are processed under
the current read and write states.  The security parameters for the
pending states can be set by the TLS Handshake Protocol, and the
ChangeCipherSpec can selectively make either of the pending states
current, in which case the appropriate current state is disposed of
and replaced with the pending state; the pending state is then
reinitialized to an empty state.  It is illegal to make a state that
has not been initialized with security parameters a current state.
The initial current state always specifies that no encryption or MAC
will be used.
Paragraph (version B):
A TLS connection state is the operating environment of the TLS Record
Protocol.  It specifies a record protection algorithm and its
parameters as well as the record protection keys and IVs for the
connection in both the read and the write directions.  Logically,
there are always four connection states outstanding: the current read
and write states, and the pending read and write states.  All records
are processed under the current read and write states.  The security
parameters for the pending states can be set by the TLS Handshake
Protocol, and the ChangeCipherSpec can selectively make either of the
pending states current, in which case the appropriate current state
is disposed of and replaced with the pending state; the pending state
is then reinitialized to an empty state.  It is illegal to make a
state that has not been initialized with security parameters a
current state.  The initial current state always specifies that
records are not protected.
Paragraph (version A):
An algorithm to be used for bulk encryption.  This specification
includes the key size of this algorithm, whether it is a block,
stream, or AEAD cipher, the block size of the cipher (if
appropriate), and the lengths of explicit and implicit
initialization vectors (or nonces).
Paragraph (version A):
An algorithm to be used for message authentication.  This
specification includes the size of the value returned by the MAC
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
section 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 the lengths of
explicit and implicit initialization vectors (or nonces).
Paragraph (version A):
The current state of the encryption algorithm.  This will consist
of the scheduled key for that connection.  For stream ciphers,
this will also contain whatever state information is necessary to
allow the stream to continue to encrypt or decrypt data.
Paragraph (version A):
The MAC key for this connection, as generated above.
Paragraph (version B):
The current state of the encryption algorithm.  This will consist
of the scheduled key for that connection.
Paragraph (version A):
The encryption and MAC functions translate a TLSPlaintext structure
into a TLSCiphertext.  The decryption functions reverse the process.
The MAC of the record also includes a sequence number so that
missing, extra, or repeated messages are detectable.
Paragraph (version B):
The record protection functions translate a TLSPlaintext structure
into a TLSCiphertext.  The deprotection functions reverse the
process.  In TLS 1.3 as opposed to previous versions of TLS, all
ciphers are modelled as "Authenticated Encryption with Additional
Data" (AEAD) RFC5116.  AEAD functions provide a unified encryption
and authentication operation which turns plaintext into authenticated
ciphertext and back again.
Paragraph (version B):
AEAD ciphers take as input a single key, a nonce, a plaintext, and
"additional data" to be included in the authentication check, as
described in Section 2.1 of RFC5116.  The key is either the
client_write_key or the server_write_key.
Paragraph (version A):
The encrypted form of TLSPlaintext.fragment, with the MAC.
Paragraph (version A):
Stream ciphers (including BulkCipherAlgorithm.null; see the-security-
parameters) convert TLSPlaintext.fragment structures to and from
stream TLSCiphertext.fragment structures.
Paragraph (version A):
where "+" denotes concatenation.
Paragraph (version A):
The sequence number for this record.
Paragraph (version A):
The MAC algorithm specified by SecurityParameters.mac_algorithm.
Paragraph (version A):
Note that the MAC is computed before encryption.  The stream cipher
encrypts the entire block, including the MAC.  For stream ciphers
that do not use a synchronization vector (such as RC4), the stream
cipher state from the end of one record is simply used on the
subsequent packet.  If the cipher suite is TLS_NULL_WITH_NULL_NULL,
encryption consists of the identity operation (i.e., the data is not
encrypted, and the MAC size is zero, implying that no MAC is used).
For both null and stream ciphers, TLSCiphertext.length is
TLSPlaintext.length plus SecurityParameters.mac_length.
Paragraph (version A):
For block ciphers (such as 3DES or AES), the encryption and MAC
functions convert TLSPlaintext.fragment structures to and from block
TLSCiphertext.fragment structures.
Paragraph (version A):
The MAC is generated as described in null-or-standard-stream-cipher.
Paragraph (version A):
The Initialization Vector (IV) SHOULD be chosen at random, and
MUST be unpredictable.  Note that in versions of TLS prior to 1.1,
there was no IV field, and the last ciphertext block of the
previous record (the "CBC residue") was used as the IV.  This was
changed to prevent the attacks described in CBCATT.  For block
ciphers, the IV length is of length
SecurityParameters.record_iv_length, which is equal to the
SecurityParameters.block_size.
Paragraph (version A):
Padding that is added to force the length of the plaintext to be
an integral multiple of the block cipher's block length.  The
padding MAY be any length up to 255 bytes, as long as it results
in the TLSCiphertext.length being an integral multiple of the
block length.  Lengths longer than necessary might be desirable to
frustrate attacks on a protocol that are based on analysis of the
lengths of exchanged messages.  Each uint8 in the padding data
vector MUST be filled with the padding length value.  The receiver
MUST check this padding and MUST use the bad_record_mac alert to
indicate padding errors.
Paragraph (version A):
The padding length MUST be such that the total size of the
GenericBlockCipher structure is a multiple of the cipher's block
length.  Legal values range from zero to 255, inclusive.  This
length specifies the length of the padding field exclusive of the
padding_length field itself.
Paragraph (version A):
The encrypted data length (TLSCiphertext.length) is one more than the
sum of SecurityParameters.block_length, TLSPlaintext.length,
SecurityParameters.mac_length, and padding_length.
Paragraph (version A):
Example: If the block length is 8 bytes, the content length
(TLSPlaintext.length) is 61 bytes, and the MAC length is 20 bytes,
then the length before padding is 82 bytes (this does not include the
IV.  Thus, the padding length modulo 8 must be equal to 6 in order to
make the total length an even multiple of 8 bytes (the block length).
The padding length can be 6, 14, 22, and so on, through 254.  If the
padding length were the minimum necessary, 6, the padding would be 6
bytes, each containing the value 6.  Thus, the last 8 octets of the
GenericBlockCipher before block encryption would be xx 06 06 06 06 06
06 06, where xx is the last octet of the MAC.
Paragraph (version A):
Note: With block ciphers in CBC mode (Cipher Block Chaining), it is
critical that the entire plaintext of the record be known before any
ciphertext is transmitted.  Otherwise, it is possible for the
attacker to mount the attack described in CBCATT.
Paragraph (version A):
Implementation note: Canvel et al.  CBCTIME have demonstrated a
timing attack on CBC padding based on the time required to compute
the MAC.  In order to defend against this attack, implementations
MUST ensure that record processing time is essentially the same
whether or not the padding is correct.  In general, the best way to
do this is to compute the MAC even if the padding is incorrect, and
only then reject the packet.  For instance, if the pad appears to be
incorrect, the implementation might assume a zero-length pad and then
compute the MAC.  This leaves a small timing channel, since MAC
performance depends to some extent on the size of the data fragment,
but it is not believed to be large enough to be exploitable, due to
the large block size of existing MACs and the small size of the
timing signal.
Paragraph (version A):
For AEAD RFC5116 ciphers (such as CCM or GCM), the AEAD function
converts TLSPlaintext.fragment structures to and from AEAD
TLSCiphertext.fragment structures.
Paragraph (version A):
AEAD ciphers take as input a single key, a nonce, a plaintext, and
"additional data" to be included in the authentication check, as
described in Section 2.1 of RFC5116.  The key is either the
client_write_key or the server_write_key.  No MAC key is used.
Paragraph (version B):
The AEAD encrypted form of TLSPlaintext.fragment.
Paragraph (version A):
The Record Protocol requires an algorithm to generate keys required
by the current connection state (see the-security-parameters) from
the security parameters provided by the handshake protocol.
Paragraph (version A):
The master secret is expanded into a sequence of secure bytes, which
is then split to a client write MAC key, a server write MAC key, a
client write encryption key, and a server write encryption key.  Each
of these is generated from the byte sequence in that order.  Unused
values are empty.  Some AEAD ciphers may additionally require a
client write IV and a server write IV (see aead-ciphers).
Paragraph (version A):
When keys and MAC keys are generated, the master secret is used as an
entropy source.
Paragraph (version B):
As a special case, we define the NULL_NULL AEAD cipher which is
simply the identity operation and thus provides no security.  This
cipher MUST ONLY be used with the initial TLS_NULL_WITH_NULL_NULL
cipher suite.
Paragraph (version B):
The master secret is expanded into a sequence of secure bytes, which
is then split to a client write encryption key and a server write
encryption key.  Each of these is generated from the byte sequence in
that order.  Unused values are empty.  Some ciphers may additionally
require a client write IV and a server write IV.
Paragraph (version B):
When keys are generated, the master secret is used as an entropy
source.
Paragraph (version A):
Implementation note: The currently defined cipher suite which
requires the most material is AES_256_CBC_SHA256.  It requires 2 x 32
byte keys and 2 x 32 byte MAC keys, for a total 128 bytes of key
material.
Paragraph (version A):
This alert is returned if a record is received with an incorrect
MAC.  This alert also MUST be returned if an alert is sent because
a TLSCiphertext decrypted in an invalid way: either it wasn't an
even multiple of the block length, or its padding values, when
checked, weren't correct.  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 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 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):
level of security: if you negotiate AES with a 1024-bit DHE key
exchange with a host whose certificate you have verified, you can
expect to be that secure.
Paragraph (version B):
level of security: if you negotiate AES-GCM GCM with a 1024-bit DHE
key exchange with a host whose certificate you have verified, you can
expect to be that secure.
Paragraph (version A):
The cipher suite list, passed from the client to the server in the
ClientHello message, contains the combinations of cryptographic
algorithms supported by the client in order of the client's
preference (favorite choice first).  Each cipher suite defines a key
exchange algorithm, a bulk encryption algorithm (including secret key
length), a MAC algorithm, and a PRF.  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.
Paragraph (version B):
The cipher suite list, passed from the client to the server in the
ClientHello message, contains the combinations of cryptographic
algorithms supported by the client in order of the client's
preference (favorite choice first).  Each cipher suite defines a key
exchange algorithm, a record encryption algorithm (including secret
key length) and a PRF.  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.
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, encryption,
and MAC 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 master secret.
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.  The authentication, key
agreement, 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 master secret.