On Tuesday, 15 August 2017 15:54:15 CEST Ilari Liusvaara wrote: > On Tue, Aug 15, 2017 at 03:31:56PM +0200, Hubert Kario wrote: > > I've created a Pull Request that introduces requirement for constant time > > processing of padding and an example on how to do it: > > > > https://github.com/tlswg/tls13-spec/pull/1073 > > -1 > > Except doing the depad in constant-time is useless if you just re- > introduce the timing leaks at the next step. Actually not introducing > timing leaks in TLS library requires special API for passing the data > to application...
In C you pass data to application using pointer to memory location and a length variable. Padding influences only the length variable value. How exactly can you do that in _non_ constant time? > API that has had no reason to exist so far, and is > more complicated to use than current read or zerocopy callback APIs. with current read(3), you require the application to provide a buffer the size of the whole padded data, you copy the whole padded data, you return a length that truncates the content type and padding. I fail to see how is that a "special API" > And even if you have such special API, it is extremely doubtful how > many applications could use it correctly. Constant-time processing of > variable-length data is extremely hard (LUCKY13 anyone?) right, so because it is hard, we should just throw our hands in the air and walk away? The point is that, if possible, we shouldn't undermine the work of applications that *do* have constant-time processing of variable-length data. -- 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
