Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

[Eric Rescorla <[e-mail]>]

On Fri, Aug 11, 2017 at 9:47 AM, Nikos Mavrogiannopoulos <[e-mail]>
wrote:

> On Fri, Aug 11, 2017 at 5:57 PM, Eric Rescorla <[e-mail]> wrote:
>
>>
>> On Fri, Aug 11, 2017 at 7:11 AM, Nikos Mavrogiannopoulos <[e-mail]
>> > wrote:
>>
>>> Imagine the following scenario, where the server and client have this
>>> repeated communication N times per day:
>>>
>>> client     server
>>>     --X-->
>>>     <--Y--
>>>
>>>
>>> the client puts in X a message A of 1 byte or B of 1024 bytes, and pads
>>> it to the maximum size of TLS record. The server replies with the
>>> message "ok" (same every time), padded to the maximum size just after
>>> it reads X.
>>>
>>> However, TLS 1.3 detects the message size by iterating through all the
>>> padding bytes, and thus there is a timing leak observed by the time
>>> difference between receiving X and sending Y. Thus as an adversary I
>>> could take enough measurements and be able to distinguish between X
>>> having the value A or B.
>>>
>>> While I'd expect these iterations to be unmeasurable in desktop or
>>> server hardware, I am not sure about the situation in low-end IoT
>>> hardware. Is the design choice for having the padding removal depending
>>> on padding length intentional?
>>
>>
>> Yes, we're aware of this, and it's an intentional design choice. The
>> reasoning
>> was that once you have the padding removed, you'll need to operate on/copy
>> the unpadded content somewhere, and that's timing dependent anyway.
>>
>
> That is certainly an incorrect assumption. gnutls for example provides a
> zero-copy API, and I guess it is not the only implementation to have that.
>

And then the next thing that will happen is that the application will read
the data, which is length-dependent. The problem is that the plaintext is
variable length.


There is mentioning of possible timing channels in:
>>> https://tools.ietf.org/html/draft-ietf-tls-tls13-21#appendix-E.3
>>> However I don't quite understand how is this section intended to be
>>> read. The sentence for example: "Because the padding is encrypted
>>> alongside the actual content, an attacker cannot directly determine the
>>> length of the padding, but may be able to measure it indirectly by the
>>> use of timing channels exposed during record processing", what is its
>>> intention? Is it to acknowledge the above timing leak?
>>>
>>
>> Yes.
>>
>
> I am not sure if that text is sufficient to cover that issue. It seems as
> if the cbc timing attack is re-introduced here and pushing the fix to
> implementers. It may be better no to provide padding functionality with
> this "feature", as unfortunately it will be used by applications.
>

I don't believe that this is analysis is correct. This timing channel only
applies to the data after message integrity has been established (i.e.,
after AEAD processing), which is different from the situation in Lucky 13.
It seems like what leaks here is the length of the plaintext, which is also
what would be leaked if we simply did not have padding.

-Ekr


> regards,
> Nikos
>
>