On Friday, 11 August 2017 20:32:57 CEST Short, Todd wrote: > However, I argue that having TLS do significant padding for a protocol is > bad design for that protocol. It’s one thing if it’s a few padding bytes, > but the example given was 1023 bytes of padding.
the difference in processing that is equal to just few clock cycles is detectable over network[1] > Also as pointed out by Andrei Popov, the application needs to tell TLS how > much padding to apply, so either way, the application has to deal with > determining the padding length. Why not just make it part of the protocol > in the first place? The problem is not when the application adds padding. The problem is when the padding is removed on the receiver side. > But my final point is that we are ignoring the amount of non-TLS processing > that must be done on various message types (before the response is sent), > and THAT might be even more of a giveaway than the minuscule timing > difference due to counting padding in TLS. Sure, it can, and in most cases it will be. We are not talking about this situation. 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. 1 - https://www.imperialviolet.org/2013/02/04/luckythirteen.html (very bottom) -- 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
