Subject: [TLS] On the possibility of AEAD modes that require padding

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 20 Jun 2014 14:11:58 -0400

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

---

From: Adam Langley <[email-masked]>
Date: Fri, 20 Jun 2014 11:23:38 -0700

> values are of course identical.

This would mean that padding would, conceptually, be done outside of
the AEAD, right? Otherwise the AEAD interface suffers: the caller
would have to be able to query the "padded length" of a plaintext
length in order to update the AD.

Neither is very attractive. I would suggest that, if a padded AEAD is
added to TLS, then the length bytes in the AD be set to zero. That
seems to be the least bad option to me.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Watson Ladd <[email-masked]>
Date: Fri, 20 Jun 2014 15:23:58 -0300

> before doing the decryption.

This is just a straight-up mistake: AEAD modes already protect the
plaintext length without explicitly supplying it in the form of AAD.
Omitting it solves the problem.

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Jun 2014 11:29:45 -0700

Daniel,

Thanks for your post:

You're right that this is an issue (which has been raised by several people
in the past). The two solutions seem to be:

- As you propose, compute the integrity tag over the padded length.

- Simply remove the length field from the additional_data on the theory
that the AEAD mode itself must verify the length (or as AGL proposed
a few minutes ago, set it to 0 for any modes which pad)

If we decide to take the second direction, we might remove the length
for any AEAD algorithms which take padding in TLS 1.2 and then remove
the length for all AEAD algorithms in TLS 1.3.

I have created a github issue to track this:
https://github.com/tlswg/tls13-spec/issues/47

-Ekr

On Fri, Jun 20, 2014 at 11:11 AM, Daniel Kahn Gillmor <[email-masked]
> wrote:

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 20 Jun 2014 14:56:49 -0400

On Fri 2014-06-20 14:29:45 -0400, Eric Rescorla wrote:
> that the AEAD mode itself must verify the length

Does anyone object to this approach for TLS 1.3?

An AEAD that does not verify the length seems like it would be
problematic in other ways, and this seems like a nice simplifying
approach.

diff --git a/draft-ietf-tls-tls13.md b/draft-ietf-tls-tls13.md
index d9ace55..cda3dbf 100644
--- a/draft-ietf-tls-tls13.md
+++ b/draft-ietf-tls-tls13.md
@@ -1016,7 +1016,7 @@ The additional authenticated data, which we denote as additional_data, is
 defined as follows:
 
        additional_data = seq_num + TLSPlaintext.type +
-                         TLSPlaintext.version + TLSPlaintext.length;
+                         TLSPlaintext.version;

I don't know whether folks think this warrants an entry in the "Major
Differences from TLS 1.2" section.  It's a small change, but it would be
a significant one for implementers who missed it.

I don't know that we even need to bother with it for TLS 1.2, unless
someone wants to add a new padded AEAD mode to TLS 1.2 separately.

        --dkg

---

From: Yoav Nir <[email-masked]>
Date: Fri, 20 Jun 2014 23:25:27 +0300

> chacha20-poly1305 (and other AEAD modes i could find data on) also don't

While this hasn’t been proposed directly to the TLS working group there is the CBC-HMAC AEAD in draft-mcgrew-aead-aes-cbc-hmac-sha2.

That’s CBC so there is padding as described in section 2.1.

Yoav