Original text:
The additional authenticated data, which we denote as additional_data, is defined as follows: <del> [[OPEN ISSUE: Fix length which gives us a problem here for algorithms which pad.  See: https://github.com/tlswg/tls13-spec/issues/47]] </del> where "+" denotes concatenation.  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

Reviewer comments:
In order to support aead suites that pad or otherwise modify length, we need to stop using the plaintext length in the aead input. An implied requirement on the cipher is to validate length.
:+1: Also note that I have also opened a documentation errata for TLS 1.2 related to this. (Errata ID: 2390, URL)
It's been observed a number of times that the AEAD cipher suite definitions don't actually accommodate ciphers which pad. See: URL URL URL We should either fix this or remove padding. hi IETF folks-- If an AEAD mode is ever defined that must pad its input to a blocksize before encrypting, the current spec seems like it will break. This is a currently-theoretical concern, since (fixed authentication tag notwithstanding) GCM does not pad its input, and OCB and chacha20-poly1305 (and other AEAD modes i could find data on) also don't pad their input. (note that this question is independent of the various proposals for explicitly introducing padding into TLS, which i don't go into here) The 1.3 draft currently says: It goes on to define AEAD-Decrypt this way: Consider the decryption step. The decryptor knows: the AEAD mode (including the taglength) the nonce the write key the sequence number the record type the TLS version the ciphertext (including its length) To create additionaldata, it must be able to derive URL From the above information. All the AEAD modes i know about have a ciphertext expansion of a fixed-length tag. so: URL = URL - AEADmode.taglength But if an AEAD mode were to additionally pad its input ("Since the ciphers might incorporate padding, the amount of overhead could vary with different URL values"), there would be no clear way to derive additionaldata because the length of the plaintext is unknown before doing the decryption. So i think the fix is to specify that additional_data should be derived From the padded length of the TLSPlaintext.fragment, not from URL For GCM (and other AEAD modes i know of) these values are of course identical. Making this explicit seems like it would require a bit of gymnastics in the spec, all for the sake of holding open the door for future modes with variable-length ciphertext expansion. I can try to make a patch for this change, but i want to know if we think it's necessary. Alternately, we could decide that we won't accept modes that require this kind of padding (maybe stripping out the sentence about "might incorporate padding"). Have i missed an obvious solution or misunderstood the situation? What do people think we should do here? --dkg

Revised text:
The additional authenticated data, which we denote as additional_data, is defined as follows:  where "+" denotes concatenation. <ins> Note: In versions of TLS prior to 1.3, the additional_data included a length field.  This presents a problem for cipher constructions with data-dependent padding (such as CBC).  TLS 1.3 removes the length field and relies on the AEAD cipher to provide integrity for the length of the data. </ins> 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