Change:
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. NAME 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 URL 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 cannot 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.
Mozilla is working on measurements.

Discussion:
properties TLS does and does not provide and cannot safely rely on the latter. <del> Note in particular that type and length of a record are not protected by encryption.  If this information is itself sensitive, application </del> <ins> Note in particular that the length of a record is not protected by encryption.  If this information is itself sensitive, application </ins> designers may wish to take steps (e.g., padding, cover traffic) to minimize information leakage.

described in Section 2.1 of RFC5116.  The key is either the client_write_key or the server_write_key. <del> %%% Record Layer struct { ContentType type; ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */ uint16 length; aead- ciphered struct { opaque content[TLSPlaintext.length]; } fragment; } TLSCiphertext; </del> <ins> %%% Record Layer struct { ContentType opaque_type = application_data(23); /* see fragment.type _/ ProtocolVersion record_version = { 3, 1 }; /_ TLS v1.x */ uint16 length; aead- ciphered struct { opaque content[TLSPlaintext.length]; ContentType type; } fragment; } TLSCiphertext; </ins> <del> The type field is identical to TLSPlaintext.type. </del> <ins> 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. </ins> The record_version field is identical to

"record_overflow" alert. <del> The AEAD encrypted form of TLSPlaintext.fragment. </del> <ins> The cleartext of TLSPlaintext.fragment. The actual content type of the record. The AEAD encrypted form of TLSPlaintext.fragment + TLSPlaintext.type, where "+" denotes concatenation. </ins> The length of the per-record nonce (iv_length) is set to max(8 bytes, N_MIN) for the AEAD algorithm (see RFC5116 Section 4).  An AEAD

Note: This is a different construction from that in TLS 1.2, which specified a partially explicit nonce. <del> The plaintext is the TLSPlaintext.fragment. </del> <ins> The plaintext is the concatenation of TLSPlaintext.fragment and TLSPlaintext.type. </ins> The additional authenticated data, which we denote as additional_data, is defined as follows:

length of the data. The AEAD output consists of the ciphertext output by the AEAD <del> 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, </del> <ins> 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, </ins> In order to decrypt and verify, the cipher takes as input the key, nonce, the "additional_data", and the AEADEncrypted value.  The

If the decryption fails, a fatal "bad_record_mac" alert MUST be generated. <del> 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. </del> <ins> 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. </ins> <del> 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. </del> <ins> TODO: explain how TLS_NULL_WITH_NULL_NULL is not actually a cipher at all, and that in that state we should send raw TLSPlaintext instead of sending a phony TLSCiphertext </ins> 6.