On Tuesday, 15 August 2017 17:28:22 CEST Eric Rescorla wrote: > I generally agree with Ilari. To recap what I said on the PR: > I think it would be fine to sharpen the point about padding leaking > information and I'd take a short PR for that.
I've prepared https://github.com/tlswg/tls13-spec/pull/1074 with that in mind. > I don't believe it's > necessary either to require that it be constant time (for the reasons I > indicated on-list and already documented in the spec) or to describe a > specific algorithm, especially at this point on the document life cycle. > > -Ekr > > > > On Tue, Aug 15, 2017 at 6:54 AM, Ilari Liusvaara <ilariliusva...@welho.com> > > 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... API that has had no reason to exist so far, and is > > more complicated to use than current read or zerocopy callback APIs. > > > > 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?) > > > > Oh, and then there are timing leaks when sending data too... > > > > > > -Ilari > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls -- 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
