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