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:

> The additional authenticated data, which we denote as additional_data, is
> defined as follows:
> 
>        additional_data = seq_num + TLSPlaintext.type +
>                          TLSPlaintext.version + TLSPlaintext.length;
> 
> 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 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.

It goes on to define AEAD-Decrypt this way:

>       TLSPlaintext.fragment = AEAD-Decrypt(write_key, nonce,
>                                            AEADEncrypted,
>                                            additional_data)

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 additional_data, it must be able to derive TLSPlaintext.length
From the above information.

All the AEAD modes i know about have a ciphertext expansion of a
fixed-length tag.  so:

 TLSPlaintext.length = TLSCiphertext.length - 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 TLSPlaintext.length values"), there would be no clear way
to derive additional_data 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
TLSPlaintext.length.  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