Re: [TLS] Reducing record expansion overhead allowance

["StJohns, Michael" <[e-mail]>]

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 <[e-mail]> wrote:

> On Sun, Jul 20, 2014 at 9:08 AM, StJohns, Michael <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>> wrote:
>
>> You mean as part of the plain text?
>
>
> From the perspective of the AEAD algorithm, yes.
>
> -Ekr
>
>
>>
>> On Sunday, July 20, 2014, Eric Rescorla <[e-mail]
>> <javascript:_e(%7B%7D,'cvml','[e-mail]');>> wrote:
>>
>>> On Sun, Jul 20, 2014 at 7:52 AM, StJohns, Michael <
>>> [e-mail]> wrote:
>>>
>>>> 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.
>>>
>>>
>>> I believe the consensus here was to have padding be done separately.
>>>
>>> -Ekr
>>>
>>>
>>>>
>>>> On Saturday, July 19, 2014, Eric Rescorla <[e-mail]> wrote:
>>>>
>>>>>  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
>>>>>
>>>>>
>>>
>