On Friday, 11 August 2017 19:04:05 CEST Andrei Popov wrote: > * I don't argue with this but this is not the approach TLS 1.3 took. It > provides a generic padding mechanism to be used across application > protocols. > At some point I thought we said that the TLS 1.3 padding > mechanism was supposed to be application-driven (in the form of > application-provided policy or simply desired pad size), which would mean > that the application has to be involved anyway.
Problem is, that the application doesn't know how much time did processing of the message took (even if it gets the information that the received message was padded, which is not possible with current common library APIs). So even if the application takes exactly as much time to process a long request as it does to process a short request, the length of that processing will leak. -- 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
