On Tuesday, 15 August 2017 00:55:50 CEST Colm MacCárthaigh wrote: > On Mon, Aug 14, 2017 at 8:16 PM, Hubert Kario <hka...@redhat.com> 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
