Draft: draft-ietf-tls-tls13

Commentary: This pull request has been updated to the current master 
 Consensus at meeting to merge this PR with updates and with the dummy type byte restored . has action item to actually measure whether we can strip off the now fixed type , record.version bytes . 
 I 've updated this with the expected changes : dummy external ContentType octet is restored , and is after fragment.content instead of the other way around ( to make it easier to encrypt without having to shuffle buffers ) . 
 I agree with davegarrett 's suggestion about field naming here , and have supplied a change implementing it . 
 TLSCiphertext.recordversion provides no useful information , encourages implementations to check it unnecessarily , and wastes two bytes per record . It should be removed entirely . This is effectively dependent on PR or similar changes . Filing this as a specific issue rather than just bringing it up in backwards compatibility discussion . Edited to add : Note that this value is called TLSCiphertext.version in TLS 1.2 and TLSCiphertext.recordversion as of TLS 1.3 draft 06 . The TLSPlaintext equivalent of this version field can not be removed as it is required for backwards compatibility , however it 's only used with ClientHello at this point . 
 Defer pending measurements . Note that this fate shares with removing the cleartext content type 
 sgtm Amending issue title . 
  is working on measurements .
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 (e.g., padding, cover traffic) to
minimize information leakage.
Paragraph (version B):
Note in particular that the length of a record is 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 type field is identical to TLSPlaintext.type.
Paragraph (version B):
The outer opaque_type field of a TLSCiphertext record is always
set to the value 23 (application_data) for outward compatibility
with middleboxes used to parsing previous versions of TLS.  The
actual content type of the record is found in fragment.type after
decryption.
Paragraph (version A):
The AEAD encrypted form of TLSPlaintext.fragment.
Paragraph (version B):
The cleartext of TLSPlaintext.fragment.
Paragraph (version B):
The actual content type of the record.
Paragraph (version B):
The AEAD encrypted form of TLSPlaintext.fragment +
TLSPlaintext.type, where "+" denotes concatenation.
Paragraph (version A):
The plaintext is the TLSPlaintext.fragment.
Paragraph (version B):
The plaintext is the concatenation of TLSPlaintext.fragment and
TLSPlaintext.type.
Paragraph (version A):
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.
Symbolically,
Paragraph (version B):
The AEAD output consists of the ciphertext output by the AEAD
encryption operation.  The length of the plaintext is one greater
than TLSPlaintext.length due to the inclusion of TLSPlaintext.type.
The length of aead_output will generally be larger than the
plaintext, 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.  Symbolically,
Paragraph (version A):
An AEAD cipher MUST NOT produce an expansion of greater than 256
bytes.  An endpoint that receives a record that is larger than 2^14 +
256 octets MUST generate a fatal "record_overflow" alert.
Paragraph (version A):
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):
An AEAD cipher MUST NOT produce an expansion of greater than 255
bytes.  An endpoint that receives a record from its peer with
TLSCipherText.length larger than 2^14 + 256 octets MUST generate a
fatal "record_overflow" alert.  This limit is derived from the
maximum TLSPlaintext length of 2^14 octets + 1 octet for ContentType
+ the maximum AEAD expansion of 255 octets.