On Fri 2017-08-11 18:43:15 +0200, Nikos Mavrogiannopoulos 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.
The design approach that TLS 1.3 took was to provide a mechanism for
padding at the TLS layer, not to prescribe padding at the application
layer. You actually probably need both to defend against traffic
analysis in the big picture.
Thoughtful, well-designed application-layer padding is likely to be
better than generic TLS-layer padding. But not all applications can
actually accomodate padding (and it's not clear that folks have done the
thoughtful work even on those applications which *can* accomodate
padding).
TLS offers a generic mechanism to support the cases where the
application can't do padding, or where the implementer has no control
over (or insight into) the application itself. It'll probably leak in
the way you describe, but it'll probably also be better than cleartext.
Furthermore, there are TLS messages that are not application data at
all -- so those parts *have* to be padded at the TLS layer, as the
application cannot directly affect their size.
A robust and safe padding approach needs to take into account all layers
of the stack at once and coordinate between them. Without the padding
mechanism in TLS, it wouldn't be possible to coordinate across the whole
stack.
--dkg
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
