Subject: [TLS] Resolution AEAD Cipher length and padding

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 21 Jul 2014 14:41:09 +0000

At the interim meeting we decided to fix the specification of AEAD to support ciphers that pad and expand the cipher text length.  Please respond to this message by Friday, July 25 if you have an objection. 

Thanks,

Joe
[for the chairs]

---

From: Alfredo Pironti <[email-masked]>
Date: Mon, 21 Jul 2014 16:54:14 +0200

It's not clear to me what this resolution is about; could you please
elaborate (or give pointers)?
Is this about AEAD ciphers built on top of block-encrypt then mac? To some
extent, current GCM and CCM ciphers are already expanding the cipher text
length by the tag length, so I must be missing the point here. Thanks.

Best,
Alfredo

On Mon, Jul 21, 2014 at 4:41 PM, Joseph Salowey (jsalowey) <
[email-masked]> wrote:

> At the interim meeting we decided to fix the specification of AEAD to
> support ciphers that pad and expand the cipher text length.  Please respond
> to this message by Friday, July 25 if you have an objection.
>
> Thanks,
>
> Joe
> [for the chairs]
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 21 Jul 2014 07:59:12 -0700

> length by the tag length, so I must be missing the point here. Thanks.

if you have a cipher mode (as you say, CBC is an example) which expands the
plaintext by a non-deterministic amount (specifically an amount which can't
be determined by the receiver prior to decryption) the  it doesn't work to
have
the length be part of additional data.

See:
https://github.com/tlswg/tls13-spec/issues/67

-Ekr

Best,

---

From: Alfredo Pironti <[email-masked]>
Date: Mon, 21 Jul 2014 17:02:49 +0200

Thanks for the clarification. I'm fine with the proposed change.

On Mon, Jul 21, 2014 at 4:59 PM, Eric Rescorla <[email-masked]> wrote:

>> Is this about AEAD ciphers built on top of block-encrypt then mac? To
>> some extent, current GCM and CCM ciphers are already expanding the cipher
>> text length by the tag length, so I must be missing the point here. Thanks.
>>
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 21 Jul 2014 11:03:10 -0400

> elaborate (or give pointers)?

The most recent discussion of this situation was my re-discovery of the
problem, which was apparently known to several people already:

 https://www.ietf.org/mail-archive/web/tls/current/msg12871.html

	--dkg

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 21 Jul 2014 15:10:58 +0000

On Jul 21, 2014, at 7:54 AM, Alfredo Pironti <[email-masked]<mailto:[email-masked]>> wrote:

It's not clear to me what this resolution is about; could you please elaborate (or give pointers)?
Is this about AEAD ciphers built on top of block-encrypt then mac? To some extent, current GCM and CCM ciphers are already expanding the cipher text length by the tag length, so I must be missing the point here. Thanks.

[Joe] to clarify:  current AEAD cipher modes (GCM, CCM)  do not expand the cipher text through padding, their cipher text length is the same as the clear text length.  With the current construction you cannot support an AEAD mode build out of an AES-CBC cipher because the cipher text length would not be the same as the clear text length.  This resolution would change the construction to support AEAD ciphers that perform padding.

Best,
Alfredo

On Mon, Jul 21, 2014 at 4:41 PM, Joseph Salowey (jsalowey) <[email-masked]<mailto:[email-masked]>> wrote:
At the interim meeting we decided to fix the specification of AEAD to support ciphers that pad and expand the cipher text length.  Please respond to this message by Friday, July 25 if you have an objection.

Thanks,

Joe
[for the chairs]
_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 21 Jul 2014 11:33:52 -0400

Joseph Salowey (jsalowey) <[email-masked]>:
>
>  On Jul 21, 2014, at 7:54 AM, Alfredo Pironti <[email-masked]> wrote:
>
>  [Joe] to clarify:  current AEAD cipher modes (GCM, CCM)  do not expand
> the cipher text through padding, their cipher text length is the same as
> the clear text length.
>

I think the authentication tag (8 octets for these -- RFC 5288 or RFC 6655)
is considered part of the ciphertext for the AEAD interface (RFC 5116) as
used by TLS 1.2 (RFC 5246), so length expansion indeed already takes place.
 So unless I'm missing something, the point actually is that with these the
exact amount of length expansion is implicit (and you can recover
TLSPlaintext.length and thus determine additional_data by subtracting a
constant from the ciphertext length).

Thus, this decision is not about padding per se, but specifically about
*variable* padding, which wouldn't work with the current spec.

Bodo

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 21 Jul 2014 18:02:57 +0000

On Jul 21, 2014, at 8:33 AM, Bodo Moeller <[email-masked]<mailto:[email-masked]>> wrote:

Joseph Salowey (jsalowey) <[email-masked]<mailto:[email-masked]>>:
On Jul 21, 2014, at 7:54 AM, Alfredo Pironti <[email-masked]<mailto:[email-masked]>> wrote:

[Joe] to clarify:  current AEAD cipher modes (GCM, CCM)  do not expand the cipher text through padding, their cipher text length is the same as the clear text length.

I think the authentication tag (8 octets for these -- RFC 5288 or RFC 6655) is considered part of the ciphertext for the AEAD interface (RFC 5116) as used by TLS 1.2 (RFC 5246), so length expansion indeed already takes place.  So unless I'm missing something, the point actually is that with these the exact amount of length expansion is implicit (and you can recover TLSPlaintext.length and thus determine additional_data by subtracting a constant from the ciphertext length).

Thus, this decision is not about padding per se, but specifically about *variable* padding, which wouldn't work with the current spec.

[Joe] Yes, that would be more accurate - variable length padding added as part of the encryption process.

Bodo