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

[Hubert Kario <[e-mail]>]

On Tuesday, 15 August 2017 00:55:50 CEST Colm MacCárthaigh wrote:
> 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"

exactly what we though about cbc padding at the time TLS 1.1 was published...

> ... and even today with very low
> latency networks and I/O schedulers it remains very difficult to
> measure that kind of timing difference remotely.

simply not true[1], you can measure the times to arbitrary precision with any 
real world network connection, it will just take more tries, not infinite 
tries

> But per the post, the
> larger point is that it is prudent to be cautious.

exactly, unless you can show that the difference is not measurable, under all 
conditions, you have to assume that it is.

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

sure it is, it also limits available bandwidth and it will always use that 
amount of bandwidth, something which is not always needed

we are not concerned if the issue can be workarouded, we want to be sure that 
the TLS stack does not undermine application stack work towards constant time 
behaviour

 1 - http://www.isg.rhul.ac.uk/tls/TLStiming.pdf

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic