Draft: draft-ietf-tls-tls13

Commentary: Per :
Paragraph (version B):
draft-01 - Removed support for compression.
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, optionally compresses the data, applies
a MAC, encrypts, and transmits the result.  Received data is
decrypted, verified, decompressed, 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, applies a MAC, encrypts, and transmits
the result.  Received data is decrypted, 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 a compression algorithm, 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, compression, or MAC will be used.
Paragraph (version B):
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 A):
An algorithm to be used for data compression.  This specification
must include all information the algorithm requires to do
compression.
Paragraph (version A):
The current state of the compression algorithm.
Paragraph (version A):
All records are compressed using the compression algorithm defined in
the current session state.  There is always an active compression
algorithm; however, initially it is defined as
CompressionMethod.null.  The compression algorithm translates a
TLSPlaintext structure into a TLSCompressed structure.  Compression
functions are initialized with default state information whenever a
connection state is made active.  RFC3749 describes compression
algorithms for TLS.
Paragraph (version A):
Compression must be lossless and may not increase the content length
by more than 1024 bytes.  If the decompression function encounters a
TLSCompressed.fragment that would decompress to a length in excess of
2^14 bytes, it MUST report a fatal decompression failure error.
Paragraph (version A):
The length (in bytes) of the following TLSCompressed.fragment.
The length MUST NOT exceed 2^14 + 1024.
Paragraph (version A):
The compressed form of TLSPlaintext.fragment.
Paragraph (version A):
Note: A CompressionMethod.null operation is an identity operation; no
fields are altered.
Paragraph (version A):
Implementation note: Decompression functions are responsible for
ensuring that messages cannot cause internal buffer overflows.
Paragraph (version A):
The encryption and MAC functions translate a TLSCompressed 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 A):
The type field is identical to TLSCompressed.type.
Paragraph (version A):
The version field is identical to TLSCompressed.version.
Paragraph (version A):
The encrypted form of TLSCompressed.fragment, with the MAC.
Paragraph (version A):
Stream ciphers (including BulkCipherAlgorithm.null; see the-security-
parameters) convert TLSCompressed.fragment structures to and from
stream TLSCiphertext.fragment structures.
Paragraph (version B):
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 type field is identical to TLSPlaintext.type.
Paragraph (version B):
The version field is identical to TLSPlaintext.version.
Paragraph (version B):
The encrypted form of TLSPlaintext.fragment, with the MAC.
Paragraph (version B):
Stream ciphers (including BulkCipherAlgorithm.null; see the-security-
parameters) convert TLSPlaintext.fragment structures to and from
stream TLSCiphertext.fragment structures.
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
TLSCompressed.length plus SecurityParameters.mac_length.
Paragraph (version A):
For block ciphers (such as 3DES or AES), the encryption and MAC
functions convert TLSCompressed.fragment structures to and from block
TLSCiphertext.fragment structures.
Paragraph (version B):
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 B):
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 encrypted data length (TLSCiphertext.length) is one more than the
sum of SecurityParameters.block_length, TLSCompressed.length,
SecurityParameters.mac_length, and padding_length.
Paragraph (version A):
Example: If the block length is 8 bytes, the content length
(TLSCompressed.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 B):
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 B):
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):
For AEAD RFC5116 ciphers (such as CCM or GCM), the AEAD function
converts TLSCompressed.fragment structures to and from AEAD
TLSCiphertext.fragment structures.
Paragraph (version B):
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):
The plaintext is the TLSCompressed.fragment.
Paragraph (version B):
The plaintext is the TLSPlaintext.fragment.
Paragraph (version A):
The aead_output consists of the ciphertext output by the AEAD
encryption operation.  The length will generally be larger than
TLSCompressed.length, but by an amount that varies with the AEAD
cipher.  Since the ciphers might incorporate padding, the amount of
overhead could vary with different TLSCompressed.length values.  Each
AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
Symbolically,
Paragraph (version B):
The aead_output consists of the ciphertext output by the AEAD
encryption operation.  The length will generally be larger than
TLSPlaintext.length, but by an amount that varies with the AEAD
cipher.  Since the ciphers might incorporate padding, the amount of
overhead could vary with different TLSPlaintext.length values.  Each
AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
Symbolically,
Paragraph (version A):
The algorithm used to compress data prior to encryption.
Paragraph (version A):
The change cipher spec protocol exists to signal transitions in
ciphering strategies.  The protocol consists of a single message,
which is encrypted and compressed under the current (not the pending)
connection state.  The message consists of a single byte of value 1.
Paragraph (version B):
The change cipher spec protocol exists to signal transitions in
ciphering strategies.  The protocol consists of a single message,
which is encrypted under the current (not the pending) connection
state.  The message consists of a single byte of value 1.
Paragraph (version A):
One of the content types supported by the TLS record layer is the
alert type.  Alert messages convey the severity of the message
(warning or fatal) and a description of the alert.  Alert messages
with a level of fatal result in the immediate termination of the
connection.  In this case, other connections corresponding to the
session may continue, but the session identifier MUST be invalidated,
preventing the failed session from being used to establish new
connections.  Like other messages, alert messages are encrypted and
compressed, as specified by the current connection state.
Paragraph (version B):
One of the content types supported by the TLS record layer is the
alert type.  Alert messages convey the severity of the message
(warning or fatal) and a description of the alert.  Alert messages
with a level of fatal result in the immediate termination of the
connection.  In this case, other connections corresponding to the
session may continue, but the session identifier MUST be invalidated,
preventing the failed session from being used to establish new
connections.  Like other messages, alert messages are encrypted as
specified by the current connection state.
Paragraph (version A):
A TLSCiphertext record was received that had a length more than
2^14+2048 bytes, or a record decrypted to a TLSCompressed record
with more than 2^14+1024 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):
The decompression function received improper input (e.g., data
that would expand to excessive length).  This message is always
fatal and should never be observed in communication between proper
implementations.
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 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 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.
Paragraph (version A):
These goals are achieved by the handshake protocol, which can be
summarized as follows: The client sends a ClientHello message to
which the server must respond with a ServerHello message, or else a
fatal error will occur and the connection will fail.  The ClientHello
and ServerHello are used to establish security enhancement
capabilities between client and server.  The ClientHello and
ServerHello establish the following attributes: Protocol Version,
Session ID, Cipher Suite, and Compression Method.  Additionally, two
random values are generated and exchanged: ClientHello.random and
ServerHello.random.
Paragraph (version B):
These goals are achieved by the handshake protocol, which can be
summarized as follows: The client sends a ClientHello message to
which the server must respond with a ServerHello message, or else a
fatal error will occur and the connection will fail.  The ClientHello
and ServerHello are used to establish security enhancement
capabilities between client and server.  The ClientHello and
ServerHello establish the following attributes: Protocol Version,
Session ID and Cipher Suite.  Additionally, two random values are
generated and exchanged: ClientHello.random and ServerHello.random.
Paragraph (version A):
The hello phase messages are used to exchange security enhancement
capabilities between the client and server.  When a new session
begins, the record layer's connection state encryption, hash, and
compression algorithms are initialized to null.  The current
connection state is used for renegotiation messages.
Paragraph (version B):
The hello phase messages are used to exchange security enhancement
capabilities between the client and server.  When a new session
begins, the record layer's connection state encryption and hash
algorithms are initialized to null.  The current connection state is
used for renegotiation messages.
Paragraph (version A):
The ClientHello includes a list of compression algorithms supported
by the client, ordered according to the client's preference.
Paragraph (version A):
This is a list of the compression methods supported by the client,
sorted by client preference.  If the session_id field is not empty
(implying a session resumption request), it MUST include the
compression_method from that session.  This vector MUST contain,
and all implementations MUST support, CompressionMethod.null.
Thus, a client and server will always be able to agree on a
compression method.
Paragraph (version B):
Previous versions of TLS supported compression and the list of
compression methods was supplied in this field.  For any TLS 1.3
ClientHello, this field MUST contain only the "null" compression
method with the code point of 0.  If a TLS 1.3 ClientHello is
received with any other value in this field, the server MUST
generate a fatal "illegal_parameter" alert.  Note that TLS 1.3
servers may receive TLS 1.2 or prior ClientHellos which contain
other compression methods and MUST follow the procedures for the
appropriate prior version of TLS.
Paragraph (version A):
The presence of extensions can be detected by determining whether
there are bytes following the compression_method field at the end of
the ServerHello.
Paragraph (version B):
The presence of extensions can be detected by determining whether
there are bytes following the cipher_suite field at the end of the
ServerHello.
Paragraph (version A):
The single compression algorithm selected by the server from the
list in ClientHello.compression_methods.  For resumed sessions,
this field is the value from the resumed session state.
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 compression
algorithm is negotiated in the hello messages, and 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, 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 A):
Application data messages are carried by the record layer and are
fragmented, compressed, and encrypted based on the current connection
state.  The messages are treated as transparent data to the record
layer.
Paragraph (version B):
Application data messages are carried by the record layer and are
fragmented and encrypted based on the current connection state.  The
messages are treated as transparent data to the record layer.