Subject: [TLS] Reducing record expansion overhead allowance

From: Eric Rescorla <[email-masked]>
Date: Sat, 19 Jul 2014 11:56:16 -0700

https://github.com/tlswg/tls13-spec/issues/55

In TLS 1.2, we had the following maximum values:

TLSPlaintext: 2^{14}
TLSCompressed: 2^{14} + 1024
TLSCiphertext: 2^{14} + 2048

These overhead values allow for expansion in these transforms
due to potential bad compression overhead or padding, etc.

Wan-Teh Chang points out that we no longer have compression
so there's no need to allow for 1024 bytes of expansion there.

Minimally we should reduce the TLSCiphertext overhead to
2^{14} + 1024. Do people believe that we will have AEAD
ciphers with 1024 bytes of expansion or should we reduce
it further? I'm inclined to not re-judge that and just leave it
at 2^{14} + 1024.

Thoughts?
-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Sat, 19 Jul 2014 19:35:36 -0700

I'd have thought the first 1024 was a no-brainer. As for the aead
expansion, it does seem excessive. Even if we listen to doomsayers and
acknowledge that we might need as much as 8 times the current biggest
algorithm pad from the non-aead suites, that would all allow us to halve it.
On Jul 19, 2014 2:57 PM, "Eric Rescorla" <[email-masked]> wrote:

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

---

From: Fabrice <[email-masked]>
Date: Sat, 19 Jul 2014 21:31:53 -0700

What are the benefits of reducing the allowed overhead?

-- Fabrice

> On Jul 19, 2014, at 11:56, Eric Rescorla <[email-masked]> wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 20 Jul 2014 06:14:18 -0700

> What are the benefits of reducing the allowed overhead?

It's good to have some fixed overhead to make implementation easier.

The benefit to reducing it to 1024 is mostly consistency of assumptions
about the AEAD ciphers.

-Ekr

---

From: "StJohns, Michael" <[email-masked]>
Date: Sun, 20 Jul 2014 10:52:21 -0400

The only other thing that hasn't been mentioned that was discussed at the
interim in Denver is padding for traffic analysis resistance. That could
hit 1k in size.  But since there's no proposal that's just a guess on size.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 20 Jul 2014 08:59:18 -0700

> hit 1k in size.  But since there's no proposal that's just a guess on size.

I believe the consensus here was to have padding be done separately.

-Ekr

---

From: "StJohns, Michael" <[email-masked]>
Date: Sun, 20 Jul 2014 12:08:57 -0400

You mean as part of the plain text?

On Sunday, July 20, 2014, Eric Rescorla <[email-masked]> wrote:

> On Sun, Jul 20, 2014 at 7:52 AM, StJohns, Michael <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> On Saturday, July 19, 2014, Eric Rescorla <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 20 Jul 2014 09:15:24 -0700

>From the perspective of the AEAD algorithm, yes.

-Ekr

>>> The only other thing that hasn't been mentioned that was discussed at
>>> the interim in Denver is padding for traffic analysis resistance. That
>>> could hit 1k in size.  But since there's no proposal that's just a guess on
>>> size.
>>
>>

---

From: "StJohns, Michael" <[email-masked]>
Date: Sun, 20 Jul 2014 12:21:33 -0400

So then not really a TLS issue, but has to be supported by each application
and is transparent to TLS?   Ok - Thanks.

On Sunday, July 20, 2014, Eric Rescorla <[email-masked]> wrote:

> On Sun, Jul 20, 2014 at 9:08 AM, StJohns, Michael <[email-masked]
>> On Sunday, July 20, 2014, Eric Rescorla <[email-masked]
>>> On Sun, Jul 20, 2014 at 7:52 AM, StJohns, Michael <
>>> [email-masked]> wrote:
>>>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 20 Jul 2014 23:12:19 -0400

[reordering for chronological sanity]
On 07/20/2014 12:21 PM, StJohns, Michael wrote:
>> On Sun, Jul 20, 2014 at 9:08 AM, StJohns, Michael <[email-masked] wrote:

No, i don't think that was the intended meaning.  I think padding should
be made available within TLS, but applied directly on the cleartext; the
padded form of the cleartext is what is fed to the cipher.

Unpacking the nuances i recall from Denver:

 * padding is probably most correctly and effectively done at the
application layer, since the application itself has an understanding of
what its common usage patterns are, and how to frame a plausible
anonymity set as a padding target.

 * but in practice, most applications (and most implementations) are
likely to just slap TLS on top of a cleartext protocol "for security",
and not think much more about it.

 * some application layers themselves may not have the means to produce
and consume the padding needed within the application cleartext.

 * some (imperfect) level of resistance to traffic analysis is probably
achievable with a simple policy applied at the TLS layer, without
application layers having to do anything but flip a switch.  This is
much more likely to happen for any given application than detailed analysis.

Given these constraints, TLS is probably the best place to provide the
possibility of padding.

Defining reasonable and comprehensible padding policies/profiles is a
lot more work that will also need to be done, but we should be able to
define the mechanism within TLS without too much complexity.

	--dkg

---

From: Fabrice Gautier <[email-masked]>
Date: Sun, 20 Jul 2014 21:48:59 -0700

> On Jul 20, 2014, at 20:12, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

0
So, if I understand, we would have something like:

TLSPlaintext: what the application sends
TLSPadded: the same with added padding, input of the AEAD engine
TLSCiphertext: output of the AEAD engine, what goes on the wire. 

In that model, TLSPadded basically replace TLSCompressed of TLS 1.2, and, to go back to the original issue, your allowed overhead should probably stay the same.