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

[Colm MacCárthaigh <[e-mail]>]

On Mon, Aug 14, 2017 at 8:16 PM, Hubert Kario <[e-mail]> wrote:
> the difference in processing that is equal to just few clock cycles is
> detectable over network[1]

The post you reference actually says the opposite; "20 CPU cycles is
probably too small to exploit" ... and even today with very low
latency networks and I/O schedulers it remains very difficult to
measure that kind of timing difference remotely. But per the post, the
larger point is that it is prudent to be cautious.

> When you are careful on the application level (which is fairly simple when you
> just are sending acknowledgement message), the timing will still be leaked.

There are application-level and tls-implementation-level approaches
that can prevent the network timing leak. The easiest is to only write
TLS records during fixed period slots.

For example, suppose your process can handle 100 connections
concurrently, then you can divide 1ms into 100 slots of 10
microseconds each. Every 1ms you have a writer thread or process
'visit' each connection (you may use an epoll/kqueue driven I/O loop
or similar for this) during its fixed slot and send its pending
output.

-- 
Colm