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

[Nikos Mavrogiannopoulos <[e-mail]>]

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.


>
>
>> 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.

regards,
Nikos